微服務(wù)架構(gòu)已經(jīng)是時下后端應(yīng)用開發(fā)的主流架構(gòu)之一芥颈。微服務(wù)的整個生命周期包括微服務(wù)拆分和定義（產(chǎn)品規(guī)劃）、微服務(wù)研發(fā)双藕、微服務(wù)構(gòu)建與部署止状、監(jiān)控與運維幾個階段烹棉。
對于一般企業(yè)的微服務(wù)改造而言，極少部分企業(yè)認(rèn)為用上微服務(wù)概念 + Spring cloud套件就是整活微服務(wù)架構(gòu)了怯疤；一部分企業(yè)還能認(rèn)識到針對微服務(wù)構(gòu)建和部署所必需的DevOps流水線或平臺浆洗；接著，越來越多的企業(yè)開始接受支持微服務(wù)拆分和設(shè)計思想的Domain Driven Design集峦；在完成前三步的基礎(chǔ)上伏社，最終還有少部分企業(yè)意識到線上分布式系統(tǒng)帶來的復(fù)雜性，需要進(jìn)行微服務(wù)線上治理——分層次的監(jiān)控塔淤、診斷及最終的治理方案摘昌。
這里就主要從可觀測性、層次性高蜂、時效性上聪黎，聊聊微服務(wù)線上治理中的監(jiān)控。
系統(tǒng)運行時的可觀測性
微服務(wù)線上治理的前提——采集線上運行時數(shù)據(jù)备恤，讓系統(tǒng)狀態(tài)與流程可被實時度量和監(jiān)控稿饰。
管理學(xué)之?德魯克曾經(jīng)說過:“如果你無法度量它，就無法改進(jìn)它露泊『砹”
然而對于今天——在各系統(tǒng)存在各種五花八門、各式各樣惭笑、大量指標(biāo)數(shù)據(jù)的當(dāng)下梧喷，如何整合這些指標(biāo)，在度量的同時脖咐，提升整個系統(tǒng)運行時的可觀測性铺敌，以達(dá)到及時地發(fā)現(xiàn)問題、定位問題的目的屁擅，才是微服務(wù)線上治理的基礎(chǔ)偿凭。
理論上，問題越早發(fā)現(xiàn)派歌、越早修復(fù)弯囊，可以越節(jié)省研發(fā)成本。一些微服務(wù)的問題胶果，在規(guī)劃匾嘱、研發(fā)、構(gòu)建等階段早抠，可以通過線下微服務(wù)治理的方式提前解決掉霎烙。
然而，對于微服務(wù)能力不同蕊连、或者理解不同的各企業(yè)和團(tuán)隊來說悬垃，部分團(tuán)隊需要等到系統(tǒng)被部署到線上運行時才能真正發(fā)現(xiàn)和正視問題。
當(dāng)你面臨的團(tuán)隊甘苍，不追求clean architecture尝蠕、不寫測試、不堅持重構(gòu)载庭、沒有性能測試和聯(lián)調(diào)測試看彼、甚至沒有太多有經(jīng)驗的開發(fā)，這時候囚聚，線上系統(tǒng)監(jiān)控將成為最后的反饋堡壘靖榕。
因此，帶有觀測性的線上監(jiān)控能力是各個微服務(wù)團(tuán)隊必不可少的“看家”工具之一靡挥。
業(yè)內(nèi)能做到線上監(jiān)控的開源產(chǎn)品和商業(yè)產(chǎn)品不一而足序矩。大家可能見過下面這樣的（監(jiān)控微服務(wù)狀態(tài)、微服務(wù)之間調(diào)用等）：
或者是跋破，監(jiān)控 服務(wù)對資源CPU簸淀、內(nèi)存、磁盤等利用率趨勢：
也有API調(diào)用量毒返、失敗率租幕、延時時長的TopN統(tǒng)計：
或者，是基于動態(tài)鏈路技術(shù)實現(xiàn)的鏈路圖：
監(jiān)控需要分層次
看過上面四種監(jiān)控示例圖拧簸，相信有不少做過線上問題診斷的同事會認(rèn)為：不少指標(biāo)過于細(xì)劲绪，或者過于底層，對于發(fā)現(xiàn)實際問題和定位問題毫無幫助。
當(dāng)經(jīng)過詳細(xì)調(diào)研分析和使用之后贾富，本人發(fā)現(xiàn)這些監(jiān)控模型是應(yīng)該分層次來理解和使用的歉眷。
一共分為基礎(chǔ)狀態(tài)層、資源占用層颤枪、API層汗捡、鏈路層。
- 基礎(chǔ)狀態(tài)層：各微服務(wù)和基礎(chǔ)設(shè)施服務(wù)（比如數(shù)據(jù)庫）的生效配置及實時狀態(tài)畏纲，如健康度扇住、熔斷器狀態(tài)、限流閥狀態(tài)盗胀、灰度狀態(tài)等等艘蹋。（如示例圖1）
- 資源占用層：各微服務(wù)和基礎(chǔ)設(shè)施服務(wù)對資源的占用，比如微服務(wù)對系統(tǒng)CPU票灰、內(nèi)存女阀、磁盤等的占用率，微服務(wù)內(nèi)部堆棧對內(nèi)存的利用率等等米间。（如示例圖2）
- API層：各微服務(wù)的API性能强品，API方式包括且不限于http restful API、messageQueue consumer等等屈糊；同時的榛，基礎(chǔ)設(shè)施服務(wù)，比如數(shù)據(jù)庫逻锐，SQL本身可以理解為一種特殊的API夫晌，因此慢SQL統(tǒng)計和監(jiān)控，也可以算入API層昧诱。（如示例圖3）
- 鏈路層：統(tǒng)計和追蹤由服務(wù)請求發(fā)起的整個系統(tǒng)內(nèi)部鏈路的流轉(zhuǎn)晓淀，包括微服務(wù)之間、微服務(wù)與基礎(chǔ)設(shè)施服務(wù)之間的鏈路盏档。微服務(wù)之間的調(diào)用方式包括且不限于http restful凶掰、messageQueue等等。（如示例圖4）
越靠近技術(shù)底層蜈亩，指標(biāo)越孤立懦窘，對服務(wù)的影響面越廣，越難直接定位問題稚配；
越靠近應(yīng)用層畅涂，指標(biāo)越具象，影響面越小道川，越容易定位問題午衰。
當(dāng)然也有人會認(rèn)為立宜，在這種分層結(jié)構(gòu)中，應(yīng)該將基礎(chǔ)設(shè)施服務(wù)單獨拎出來作為一個單獨分類 —— 的確也是無不可臊岸，除了鏈路層以外橙数，基礎(chǔ)設(shè)施服務(wù)可以獨立完成另外三層的縱向切片。
監(jiān)控需要時效性
在搭建監(jiān)控工具 或者 接入監(jiān)控平臺時扇单，面對于采集日志商模、指標(biāo)的實時運算方式，大多數(shù)情況都默認(rèn)監(jiān)控是實時的 —— 這樣能及時發(fā)現(xiàn)和響應(yīng)問題蜘澜。
并且大部分監(jiān)控工具，做到了監(jiān)控自動化响疚，進(jìn)行實時預(yù)警鄙信，及時通知到相關(guān)人員處理問題；或者忿晕，有部分DevOps監(jiān)控平臺甚至可以做到自動化AI管控装诡，針對基礎(chǔ)狀態(tài)層、資源占用層出現(xiàn)的問題践盼，使用資源臨時擴容鸦采、資源切換/重啟等策略進(jìn)行線上自動恢復(fù)。
然而隨著Q/TPS咕幻、數(shù)據(jù)量的增長渔伯，監(jiān)控服務(wù)資源升級的滯后 或 架構(gòu)的不合理，監(jiān)控延時的誤差會越來越大肄程。
當(dāng)監(jiān)控的時效性越來越偏離實時锣吼，團(tuán)隊對于系統(tǒng)運行時快速發(fā)現(xiàn)和響應(yīng)問題的效率將大打折扣。
