微服務架構給IT系統和團隊帶來了什麼顯著的變化

微服務自己並無一個嚴格的定義，不過從不少人的反饋來看，你們都達成了這樣一個共識：微服務是一種簡單的應用，大概有10到100行代碼。我知道使用代碼行數來比較實現其實很不靠譜，所以你能理解這個意思就行，沒必要過度拘泥於細節。不過有一點須要注意，那就是微服務一般都是很小的，甚至是微型的。這意味着你不會在大型框架上看到不少小服務，這是不切實際的。簡單與輕量級是當今的主流。諸如Sinatra、Webbit、Finagle與Connect等小型框架在將你的代碼包裝到一個薄薄的通訊層這方面作得剛恰好。

微服務架構帶來的變化

微服務架構給IT系統和團隊帶來了如下顯著的變化：

• 基礎設施的升級，須要引入虛擬化(如Docker)，現存基礎設施也須要與之進行適配;
• 系統架構的升級，須要引入服務註冊(如Consul)，服務間的交互方式也須要與之進行適配;
• 運維平臺的升級，建議引入日誌收集(如Fluentd)，分佈式跟蹤(如Zipkin)和儀表盤(如Vizceral/Grafana)等;
• 運維效率和自動化水平的提高也迫在眉睫，不然沒法應對實例數量，變動頻率，系統複雜度的快速增加;
• 觀念的轉變，基礎設施，系統架構和運維平臺等的大幅升級，猶如小米加步槍換成飛機大炮，相應的戰略戰術也須要與之相適配才行。

微服務架構下用戶面臨的監控問題

在轉型到微服務架構之後，用戶在監控方面主要會面臨如下問題。

首先，監控配置的維護成本增長。某個在線系統大概有106個模塊，每一個模塊都須要添加端口監控，進程監控，日誌監控和自定義監控;不一樣服務的監控指標，聚合指標，報警閾值，報警依賴，報警接收人，策略級別，處理預案和備註說明也不徹底相同;如此多的內容，如何確保是否有效，是否生效，是否完整無遺漏。

當前針對維護成本，業界經常使用的幾種方法有：

• 經過變量的方式儘可能減小人工輸入
• 經過監控配置文件解析作一些可標準化的校驗
• 經過故障演練驗證報警是否符合預期

其次，第三方依賴愈來愈多。例如Docker的可靠性很大程度上取決於宿主機，若是所在的宿主機發生資源爭用，網絡異常，硬件故障，修改內核參數，操做系統補丁升級等，均可能會讓Docker莫名其妙地中招。

第三，服務故障的定位成本增長。假設故障是由於特定服務處理耗時增大致使的，那麼如何快速從106個服務以及衆多的第三方依賴中把它找出來，進一步，又如何確認是這個服務的單個實例仍是部分實例的異常，這些都讓故障定位變得更復雜。

在微服務架構下，提升故障定位效率的經常使用方法有：基於各種日誌分析，經過儀表盤展現核心指標：數據流，異常的監控策略，變動內容，線上登陸和操做記錄，文件修改等內容。

微服務監控的難點及解決思路

在微服務架構下，監控系統在報警時效性不可改變的前提下，採集的指標數量是傳統監控的三倍以上，若是是萬臺以上的規模，監控系統總體都面臨很是大的壓力，在監控方面的挑戰主要來源於：

首先，存儲功能的寫入壓力和可用性都面臨巨大挑戰。每秒寫入幾十萬採集項而且須要保證99.99%的可用性，對於任何存儲軟件來說，都不是一件輕鬆的事情。

對於寫入和可用性的壓力，業界常見的解決思路主要是基於以下方式的組合：

• 集羣基於各類維度進行拆分(如地域維度、功能維度和產品維度等);
• 增長緩存服務來下降Hbase的讀寫壓力;
• 調整使用頻率較低指標的採集週期;
• 經過批量寫入下降Hbase的寫入壓力;
• 經過寫入兩套Hbase避免數據丟失並作到故障後快速切換。

其次，監控的生效速度也面臨巨大挑戰。微服務架構下，基於彈性伸縮的加持，從服務擴容或者遷移完畢到接入流量的耗時下降到1Min左右，且每時每刻都在不斷髮生着。對於複雜監控系統來說，支持這樣的變動頻率絕非易事，並且實例變動如此頻繁，對監控系統自身來說，也會面臨可用性的風險。

常見的提升監控生效速度的思路主要有以下的幾種方式：

• 實時熱加載服務註冊信息;
• 對監控配置的合規性進行強校驗;
• 增長實例數量的閾值保護;
• 支持配置的快速回滾。

第三，基礎設施的故障可能致使報警風暴的發生。基礎設施如IDC故障，可能會在瞬時產生海量報警，進而致使短信網關擁塞較長時間。

解決這類問題的思路主要是以下方式：

• 基於報警接收人經過延時發送進行合併;
• 報警策略添加依賴關係;
• 優先發送嚴重故障的報警短信;
• 增長多種報警通知方式如電話、IM等。

微服務監控原則

對於採用微服務的團隊，建議在作監控時能夠參考Google SRE的理論，結合長期的運維實踐經驗，咱們總結了幾點能夠參考的原則：

• 首先，全部系統和第三方依賴的核心功能必須添加黑盒監控;
• 第二，全部模塊必須添加白盒監控的四個黃金指標(飽和度，錯誤，流量和延時);
• 第三，全部的變動都須要進行採集，包括但不限於程序，配置，數據，網絡，硬件，操做系統以及各種基礎設施。

另外，咱們也給你們提供了一些黑盒監控的實施經驗：

首先，應該監控哪些功能?建議將系統接入層的訪問日誌，TOP-10的URL添加黑盒監控。那TOP-9的URL是否必定須要監控?TOP-11的URL是否必定不須要監控?這取決於其訪問量是否和前面的URL在一個數量級以及人工評估其接口的重要性程度，這裏提供的更可能是一個思路，而非可量化的方法。

第二，應該使用多少個樣本/節點對一個功能進行黑盒監控?建議樣本應該覆蓋到對應模塊的全部實例，這樣也能發現由少數實例致使的小規模故障。

微服務架構下的理想監控系統

從用戶的角度看，Prometheus的總體架構設計參考了Google BorgMon，系統具備高度的靈活性，圍繞其開放性如今也慢慢造成了一個生態系統。具體來講，Prometheus 使用的是 Pull 模型，Prometheus Server 經過 HTTP 的 Pull 方式到各個目標拉取監控數據。HTTP協議的支持可以更加方便的進行定製化開發，服務註冊、信息採集和數據展現均支持多種形式/開源軟件。

結合目前國內正在興起的智能運維，也許不久的未來，上面提到的監控的各類問題也就迎刃而解了。監控策略不在須要人工定義，轉由機器學習負責，諸如策略添加，閾值設定，異常檢測，故障定位，自動止損等逐步由系統負責，運維人員再也不是「救火隊長」。

京東雲監控響應實踐

京東雲運維平臺爲數萬臺機器提供監控，部署，機器管理，權限管理，安全管理，審計和運營分析等功能，爲京東雲全部的業務在各種異構網絡環境下提供標準和統一的運維支撐能力。

基於產品所處的發展階段，用戶規模的不一樣，報警頻率也不盡相同。理想狀況下，報警頻率應該等同於故障頻率，這裏面體現了報警的準確度和召回率兩個指標，若是每一個報警都對應一個服務故障，則準確度爲100%，同理，若是每次服務故障均有報警產生，則召回率爲100%。你們能夠基於上述兩個指標，來衡量本身團隊的現狀，並針對性的制定提高計劃便可。

對於響應流程，京東雲有幾個作的好的地方能夠給你們參考：

首先，全部核心報警均有可靠的應對預案和處理機制，並經過按期的破壞演練持續進行完善。

其次，公司的監控中心會7x24值守，他們也會和業務線運維同窗同樣，接收全部影響核心系統穩定性的報警，收到報警後會進行通報，確保核心報警在發生後第一時間內有人處理並在規定的時間內處理完畢。若是未在規定的時間內處理完畢，監控中心會進行報警升級，通報該系統的管理人員，從而確保該報警能夠獲得更高的重視度和支持力度。

總結

對於監控系統的將來發展，長期來看，依託於Kubernetes的發展，在基礎設施的各個領域，都會從百花齊放到幾家獨大，從而將標準化落地到基礎設施的各個領域，進而促進整個生態的繁榮。

在監控方向，Prometheus在將來一段時間後，也許會是一個很好的選擇。在Prometheus等工具解決了通用的監控場景並標準化以後，在其上的各種應用場景，如容量規劃，流量監控，故障定位以及各類基於大數據和人工智能場景的落地等，就會出現百花齊放之勢。

 感謝您耐心看完的文章，順便給你們推薦一個Java技術交流羣：710373545裏面會分享一些資深架構師錄製的視頻資料：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化、分佈式架構等這些成爲架構師必備的知識體系。還能領取免費的學習資源，目前受益良多！