如果用一個詞來概括對于微服務的需求，那就是——速度。微服務的流行使得開發(fā)人員能夠更高效地開發(fā)更多的功能，同時保證更可靠的性能，這種趨勢已經(jīng)徹底改變了開發(fā)人員創(chuàng)建軟件的方式，而這種變化毫無疑問在軟件管理(包括監(jiān)控系統(tǒng))中造成了漣漪效應。本文將集中討論高效監(jiān)控微服務所需的根本性改變并制定五項指導原則，希望能幫助讀者采取最有效的監(jiān)控方式來適應這種全新的軟件架構(gòu)。

[[174633]]

監(jiān)控是微服務的控制系統(tǒng)的關(guān)鍵部分，系統(tǒng)越復雜，就越難理解各個組件的性能狀態(tài)并解決相應的問題。然而，在傳統(tǒng)架構(gòu)向微服務轉(zhuǎn)變的過程中，鑒于軟件交付的巨大變化，監(jiān)控需要經(jīng)歷大規(guī)模的整頓才能在微服務環(huán)境中維持良好的表現(xiàn)。運用以下五項指導原則將幫助你在使用微服務時建立更有效的監(jiān)控機制，應對與微服務相關(guān)的技術(shù)變化，以及調(diào)整相關(guān)的組織架構(gòu)。

監(jiān)控容器和其內(nèi)部運行的內(nèi)容

容器作為微服務架構(gòu)中的重要組成部分，其意義近來逐漸凸顯起來。

容器的速度，可移植性和隔離性優(yōu)勢讓越來越多的開發(fā)人員能夠輕松擁抱微服務模型。這些優(yōu)勢在許多書中都有所介紹，大家想必都了解一二，在此就不過多贅述了，你懂就好。

容器可以看作是大多數(shù)系統(tǒng)的黑盒子，這一點對于開發(fā)而言非常有用，因為從開發(fā)到生產(chǎn)，從筆記本電腦到云，容器發(fā)揮出了極高的可移植性。但是當涉及到一個服務的操作、監(jiān)控和故障排除時，黑盒子反而讓一些常見的操作更難進行，從而驅(qū)使我們想要了解：容器中到底運行著什么?應用程序/代碼是如何執(zhí)行的?它可以監(jiān)測到重要的自定義指標嗎?從DevOps的角度來看，我們不僅僅需要知道一些容器是存在的，更要深入了解容器內(nèi)部的信息。

在非容器化的環(huán)境中那些儀表化的進程(比如在主機或VM用戶空間中的Agent)，對容器而言很可能無法很好的運行，因為容器更受益于小而獨立的進程，并且需要保持盡可能少的依賴性。

而且，即使是規(guī)模適中的部署，運行數(shù)千個監(jiān)控Agent也會消耗極其昂貴的資源，同時這也是編排的噩夢。容器有兩個潛在的解決方案：1)請求開發(fā)人員直接對代碼進行測試;2)利用通用的內(nèi)核級測試方法來查看主機上的所有應用程序和容器的運行狀態(tài)。針對這兩種方式，我們不會在這里繼續(xù)深入探討，但每種方法都有其優(yōu)缺點，關(guān)鍵需要適合于你的團隊和服務。

利用編排系統(tǒng)提高服務性能

理解容器化環(huán)境中的運營數(shù)據(jù)是一個新的挑戰(zhàn)。

相比所有組成功能或服務的容器所集合起來的信息，單個容器的指標具有更低的邊際值。這類低邊際值的數(shù)據(jù)尤其適用于應用程序級的信息，例如哪些查詢的響應時間最慢，或者哪些URL出現(xiàn)的錯誤最多。同時它們也適用于基礎架構(gòu)級的監(jiān)控，例如哪些服務的容器資源的使用超出了其分配的CPU份額等等。

越來越多的軟件部署需要編排系統(tǒng)將邏輯應用藍圖轉(zhuǎn)換為物理的容器。常見的編排系統(tǒng)包括Kubernetes，MesosphereDC/OS和DockerSwarm。團隊可以使用編排系統(tǒng)來(1)定義您的微服務(2)了解每個服務在部署中的當前狀態(tài)。你可以認為編排系統(tǒng)比容器本身更為重要，因為容器本身的壽命是短暫的(它們只在存在的時間內(nèi)有效)，而你的服務對它們短暫生命周期的使用則至關(guān)重要。

DevOps團隊應該重新去定義警報，從而專注于監(jiān)控與服務體驗相關(guān)的特征，因為這些警報是評估應用程序是否會受到影響的第一道防線。但是設定這些警報是極具挑戰(zhàn)的工作，因為如果你的監(jiān)控系統(tǒng)不是container-native屬性，那就會變得異常困難。

Container-native的方案是利用業(yè)務流程的元數(shù)據(jù)動態(tài)聚合容器和應用的數(shù)據(jù)，并基于每個服務計算監(jiān)控指標。根據(jù)所使用的編排工具，可能需要設計不同的結(jié)構(gòu)層級。例如，在Kubernetes中，通常會有一個Namespace，ReplicaSets，Pods和一些容器。無論組成服務的容器的物理部署如何，在這些不同層級之間進行聚合對于邏輯故障排除而言至關(guān)重要。

為彈性和跨環(huán)境的服務做好準備

彈性服務絕對不是一個新的概念，但是在容器環(huán)境中的變化速度比虛擬化環(huán)境快得多。而這種快速變化的環(huán)境會對脆弱的監(jiān)測系統(tǒng)造成嚴重的破壞。

傳統(tǒng)架構(gòu)需要經(jīng)常性地手動調(diào)整指標，并基于軟件單獨進行部署的檢查。這種調(diào)整可以具體地定義需要監(jiān)控的各個指標，或者基于在特定容器中運行的應用進行配置。雖然小規(guī)模的操作還算是可以接受的(比如幾十個容器)，但這種方式卻無法承擔任何更大規(guī)模的系統(tǒng)。而微服務的監(jiān)控必須要能在彈性服務上進行自動擴容和縮容，而無需他人進行干預。

舉個例子，如果DevOps團隊需要靠手動定義一個容器來監(jiān)控某個服務，那毫無疑問做了一個錯誤的決定，因為Kubernetes或Mesos會在一天內(nèi)定期啟動新容器。同樣，如果在新代碼構(gòu)建并投入生產(chǎn)時需要運維人員安裝自定義的statspoint，這樣在開發(fā)人員從DockerRegistry中pull鏡像的時候很可能會帶來更多的挑戰(zhàn)。

在生產(chǎn)環(huán)境中，實現(xiàn)跨數(shù)據(jù)中心或跨多個云的監(jiān)控需要經(jīng)過復雜的部署。利用單一的監(jiān)控工具無法實現(xiàn)跨環(huán)境的監(jiān)控，因此有必要部署一個監(jiān)控系統(tǒng)來確?？梢员O(jiān)測到不同環(huán)境中的服務，并且能夠運維好動態(tài)的、容器化的IT環(huán)境。

監(jiān)控API

在微服務環(huán)境下，API是一種通用的語言，同時API也是服務中唯一開放給其它團隊的部分。從本質(zhì)上來說，API的響應和一致性可以看作是一種“內(nèi)部SLA”，盡管SLA并沒有一個正規(guī)的定義。

因此，對API的監(jiān)控是非常必要的。API監(jiān)控可以用很多種形式來實現(xiàn)，但很明顯不能僅僅局限于二進制檢測。舉例來說，以時間函數(shù)的方式來分析監(jiān)控過程中頻繁出現(xiàn)的端點就是一種非常有價值的方式，這樣可以幫助團隊在服務的使用過程中檢測到是否有任何明顯的變化，無論是因為設計的變化還是用戶的變化。

與此同時，你還需要關(guān)注服務中那些最慢的端點，因為它們可能會暴露出系統(tǒng)中存在的嚴重問題，或者至少能幫你指出系統(tǒng)中最需要優(yōu)化的地方。

跟蹤系統(tǒng)中服務調(diào)用的能力也是另外一項重要的因素。當用戶使用服務時，在基礎設施的層面分解信息并從應用的角度審視環(huán)境一定可以幫助你形成對用戶體驗更加清晰而全面的認知。

“微服務化”你的組織架構(gòu)

以上的建議都是聚焦于微服務和監(jiān)控上技術(shù)的改變，下面重點說一下另一個重要的因素——人。

想必大家都熟知“康威定律”，它告訴我們團隊的組織架構(gòu)實質(zhì)上決定了最終的系統(tǒng)設計，而正是對創(chuàng)造更快、更敏捷軟件的需求，驅(qū)動著團隊不斷思考如何為了今后系統(tǒng)的發(fā)展去重組團隊架構(gòu)和管理規(guī)則。

[[174634]]

所以，如果公司希望從一個新的軟件架構(gòu)當中獲益，技術(shù)團隊就必須像實現(xiàn)微服務化一樣重建自我，這就意味著原先的團隊要由更精簡的團隊組成并且彼此之間有著更松的耦合度，從而能夠時刻面對相應的需求選擇正確的方向。對于每個團隊而言，他們可以更好地掌控所使用的語言、處理bug的方式、甚至是運維的職責。

基于這樣的團隊架構(gòu)，DevOps團隊可以像這樣打造一個監(jiān)控平臺：允許每個微服務團隊獨立設立和管理警報、指標和儀表盤，從而從全局上監(jiān)控整個系統(tǒng)的運維狀態(tài)。

結(jié)語

是什么促使大家積極地向微服務轉(zhuǎn)型?顯而易見的因素就是——速度。企業(yè)希望用更少的時間為客戶提供更具性能和價值的服務，因此為了保證速度，有必要引入更新的技術(shù)將架構(gòu)向微服務轉(zhuǎn)型并且將底層全面容器化，這也成為目前重要的發(fā)展趨勢。

總而言之，微服務監(jiān)控最基本的原則是需要去適應微服務所帶來的底層技術(shù)和架構(gòu)的改變，而運維團隊需要更清晰地認識到這些變化，從而以更快速更簡單的方式實現(xiàn)有效的微服務監(jiān)控。