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

[[174633]]

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

監控容器和其內部運行的內容

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

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

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

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

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

利用編排系統提高服務性能

理解容器化環境中的運營數據是一個新的挑戰。

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

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

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

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

為彈性和跨環境的服務做好準備

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

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

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

在生產環境中，實現跨數據中心或跨多個云的監控需要經過復雜的部署。利用單一的監控工具無法實現跨環境的監控，因此有必要部署一個監控系統來確保可以監測到不同環境中的服務，并且能夠運維好動態的、容器化的IT環境。

監控API

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

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

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

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

“微服務化”你的組織架構

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

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

[[174634]]

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

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

結語

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

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