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

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

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

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

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

容器可以看作是大多數系統的黑盒子，這一點對於開發而言非常有用，因為從開發到生產，從膝上型電腦到雲，容器發揮出了極高的可移植性。但是當涉及到一個服務的操作、監控和故障排除時，黑盒子反而讓一些常見的操作更難進行，從而驅使我們想要了解：容器中到底執行著什麼？應用程式/程式碼是如何執行的？它可以監測到重要的自定義指標嗎？從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監控可以用很多種形式來實現，但很明顯不能僅僅侷限於二進位制檢測。舉例來說，以時間函式的方式來分析監控過程中頻繁出現的端點就是一種非常有價值的方式，這樣可以幫助團隊在服務的使用過程中檢測到是否有任何明顯的變化，無論是因為設計的變化還是使用者的變化。

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

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

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

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

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

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

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

結語

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

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

文章出處：靈雀雲（訂閱號ID：AlaudaCloud）