一、背景
容器和微服務的出現並得到大量應用，從根本上改變了應用系統的組成和運行方式。而隨着開發人員開始利用編排系統來管理和部署容器，規則進一步發生了變化。以往主機上的一個簡單應用，現在已成爲一個複雜的、動態編排的、多容器的體系架構，這同時也對應用的監測提出了全新的挑戰。
Sysdig，是專注於系統故障排查和監控工具的公司，其產品Sysdig Cloud是定位於容器系統故障排查和監控的平臺。在今年召開的JFrog SwampUp用戶大會上，Sysdig公司提出監測容器及構建在其上的微服務的五大關鍵原則。這些原則充分考慮了容器和微服務與傳統架構在運維方式上的差異。
本文即是根據Sysdig公司在本次大會上的演講視頻整理而成的。
二、微服務是什麼
要正確地監測微服務，首先要正確地理解什麼是微服務。
演講首先引用了Martin Fowler關於微服務的定義（Martin Fowler是國際著名的面向對象分析設計、UML、模式等方面的專家，敏捷開發的創始人之一，現爲ThoughtWorks公司的首席科學家。很多人瞭解微服務架構都是從Martin Fowler的這篇文章開始的），即“微服務架構”描述了一種將軟件應用程序設計爲一組可獨立部署的服務的特定方式。其中，“圍繞業務能力的特性”，也就是說，微服務的劃分不是依據程序的大小，而是以業務能力的拆分爲基準的。這種業務細分後的服務，以及自動化部署、端點智能、去中心化控制這四大概念，是設計如何監測微服務時需要時刻考慮的。
傳統架構下，應用的所有功能都實現在同一進程下，應用的擴展就是在多個服務器上覆制整體的進程。而在微服務架構下，應用功能被拆分成了粒度更小、相互獨立的服務，而這些服務都能夠被獨立地管理和部署。這樣，應用的擴展和修改都可以按需只針對部分服務進行，而不會影響其他正在運行的服務。
微服務並不是SOA（Service-Oriented Architecture，面向服務架構）， 微服務相比SOA裏的服務而言具有更小的關注點。這種全新的架構理念也帶動了基礎架構等多個領域的創新，其中就包括了針對應用的監測。
三、容器是什麼
當前很多微服務都是運行在容器的基礎之上的，那麼設計針對微服務的監測同樣要考慮容器的特性。
首先需要強調的是，容器（Container）並不是輕量級的虛機，它不像虛機一樣擁有獨立的虛擬化的操作系統，而是直接構建和運行在主機的操作系統之上。
容器除了鏡像（image），也就是我們分層構建出來的目標應用之外，還包括了主機操作系統提供的進程沙盒（sandbox）。進程沙盒保證了容器之間的隔離，使得每個容器都像是運行在一臺獨立的虛機之上。
進程沙盒包括以下幾個部分：
• 控制組（Cgroups）：規定了可以使用的資源的數量，如CPU、內存、網絡等；
• 命名空間（namespaces）：規定了可以使用哪些控制組提供的資源；
• 安全模塊（Seurity Modules）實現了容器之間的隔離。
在實際應用的過程中，容器的開發者和使用者都關注在鏡像上，感覺不到進程沙盒的存在。進程沙盒的這些部分是由容器的運行態程序自動和鏡像加載在一起的。
四、微服務與容器
從以上針對微服務和容器概念的回顧和分析來看，二者的特性是非常匹配的。利用容器的各種特點能夠便捷地實現微服務架構的各種設計需要。
因此，雖然微服務架構剛剛出現時也是運行在虛機之上的，但目前大多數的微服務都是基於容器來實現的。那麼設計針對微服務的監測也同樣要考慮到容器的特性。
在我們的設計和印象當中，微服務應該是按照上圖這樣清晰的架構運轉的。然而實際情況並非如此。隨着微服務和容器規模的擴大，我們真正面對的是如下圖一樣的場景。顯然，在這樣的場景下，要全面、準確、有效地實現對微服務的監測，是一個巨大的挑戰。
五、監測微服務的五大關鍵原則
微服務和容器的出現和大量應用，帶動了架構、開發、部署、運維等多個領域的創新，也對應用的監測提出了新的要求。在傳統架構中，監測關注的是虛機或主機上運行的單體應用。而在微服務+容器的架構下，應用已經分解爲更細粒度、相互隔離、獨立運行的進程。那麼針對微服務的監測也就需要轉向針對這些進程的關注。
Sysdig在此次大會上介紹了監測微服務應用需要遵循的五大關鍵原則：
1、監測容器，同時也要監測容器內運行的應用
針對於容器內運行的進程，監測要格外關注針對其使用資源的限制，以防止單個容器佔用和消耗主機的所有資源，從而影響到主機上其他容器的運行。同樣，針對編排器同樣要監測和限制對主機資源的佔用，尤其是在應用規模自動調整的時候，要保證合理地使用主機資源。
同時，我們不能把容器當成黑盒，必須監測到容器內運行的各種應用，如各種服務進程、數據庫等。監測要收集這些應用運行的各種度量指標，如JVM的各種參數等。當然，監測也應該收集那些開發者自己定義的，針對容器內應用運行的各種度量指標。
2、監測業務自身的性能，而不是容器的性能
在實際運行當中，每一個容器的生命週期通常都不會特別的長。容器的編排系統會隨時關注容器的運行狀態，當發生異常時，編排系統會自動的進行調整，如刪除有問題的容器，重新部署一個同樣的容器加以代替；或者根據容器運行的狀態自動地進行規模上的調整等 。而開發者和運維者應該集中關注容器內業務應用的運行狀態。
3、監測具有彈性，以及多地部署的服務
微服務的部署特性驅使我們在設計的階段就要考慮到規模性的問題。當服務的規模從10擴展成20，擴展成50，甚至於擴展成100的時候，針對服務的監測要如何自動調整去覆蓋和適應這些自動擴展的規模。同樣，針對多地部署的服務，我們又該如何根據不同的組織和分類，如站點、位置、區域等，來匯聚和統計服務的整體性能。這些都是在設計監測方案之初就要重點考慮的。
4、監測API
在微服務的架構當中，原有的單體應用被拆解成爲多個層面、更小粒度、獨立運行的服務。而API是這些服務暴露給其他服務的唯一組件。同時，API也是訪問微服務的首要通訊方式。
對API的運行、響應狀態的有效監測，對微服務的整體監測是十分重要的：
• 能夠捕獲特定方法、功能或端點的運行瓶頸；
• 能夠監測各個方法、功能或端點的調用頻率；
• 能夠跟蹤用戶業務在多個系統之間的交互行爲。
5、微服務的監測體系要匹配組織架構
提到架構，我們就不得不關注康威定律，即任意一個軟件都反映出製造它的團隊的組織結構，如下圖所示：
康威定律同樣適用於微服務的監測體系。要允許團隊根據自己的設計和理解來定義自身提供服務的監測指標、報警原則，以及監測數據的展示方式，畢竟他們是對這些服務最瞭解的人，也是最終爲服務的質量負責、解決服務問題的人。
五、總結
微服務架構的出現，以及結合容器技術的廣泛使用，改變了應用的開發、部署、運維的原有模式，同時也對監測應用提出了更高的要求。Sysdig帶來的五大關鍵原則能夠幫助我們針對微服務和容器的特性，設計更爲全面、更有針對性的監測體系。
當然，隨着微服務架構和容器技術的不斷進化，監測的體系和原則也是要隨之不斷調整的。越早認識到這樣的轉變，就能更早更容易地適應架構和技術的更新。
參考文獻
• Principles of monitoring microservices
https://www.youtube.com/watch?v=tVdp5355xbA&index=50&list=PLY0Zjn5rFo4OuGDcUEgb48JcObItA4TLW
• The Five Principles of Monitoring Microservices
https://thenewstack.io/five-principles-monitoring-microservices