微服務監測的五大原則

1、背景

====

容器和微服務的出現並獲得大量應用，從根本上改變了應用系統的組成和運行方式。而隨着開發人員開始利用編排系統來管理和部署容器，規則進一步發生了變化。以往主機上的一個簡單應用，如今已成爲一個複雜的、動態編排的、多容器的體系架構，這同時也對應用的監測提出了全新的挑戰。

Sysdig，是專一於系統故障排查和監控工具的公司，其產品Sysdig Cloud是定位於容器系統故障排查和監控的平臺。在今年召開的JFrog SwampUp用戶大會上，Sysdig公司提出監測容器及構建在其上的微服務的五大關鍵原則。這些原則充分考慮了容器和微服務與傳統架構在運維方式上的差別。

本文便是根據Sysdig公司在本次大會上的演講視頻整理而成的。

2、微服務是什麼

=========

要正確地監測微服務，首先要正確地理解什麼是微服務。

演講首先引用了Martin Fowler關於微服務的定義（Martin Fowler是國際著名的面向對象分析設計、UML、模式等方面的專家，敏捷開發的創始人之一，現爲ThoughtWorks公司的首席科學家。不少人瞭解微服務架構都是從Martin Fowler的這篇文章開始的），即「微服務架構」描述了一種將軟件應用程序設計爲一組可獨立部署的服務的特定方式。其中，「圍繞業務能力的特性」，也就是說，微服務的劃分不是依據程序的大小，而是以業務能力的拆分爲基準的。這種業務細分後的服務，以及自動化部署、端點智能、去中心化控制這四大概念，是設計如何監測微服務時須要時刻考慮的。

傳統架構下，應用的全部功能都實如今同一進程下，應用的擴展就是在多個服務器上覆制總體的進程。而在微服務架構下，應用功能被拆分紅了粒度更小、相互獨立的服務，而這些服務都可以被獨立地管理和部署。這樣，應用的擴展和修改均可以按需只針對部分服務進行，而不會影響其餘正在運行的服務。

微服務並非SOA（Service-Oriented Architecture，面向服務架構）， 微服務相比SOA裏的服務而言具備更小的關注點。這種全新的架構理念也帶動了基礎架構等多個領域的創新，其中就包括了針對應用的監測。

3、容器是什麼

=======

當前不少微服務都是運行在容器的基礎之上的，那麼設計針對微服務的監測一樣要考慮容器的特性。

首先須要強調的是，容器（Container）並非輕量級的虛機，它不像虛機同樣擁有獨立的虛擬化的操做系統，而是直接構建和運行在主機的操做系統之上。

容器除了鏡像（image），也就是咱們分層構建出來的目標應用以外，還包括了主機操做系統提供的進程沙盒（sandbox）。進程沙盒保證了容器之間的隔離，使得每一個容器都像是運行在一臺獨立的虛機之上。

進程沙盒包括如下幾個部分：

· 控制組（Cgroups）：規定了可使用的資源的數量，如CPU、內存、網絡等；

· 命名空間（namespaces）：規定了可使用哪些控制組提供的資源；

· 安全模塊（Seurity Modules）實現了容器之間的隔離。

在實際應用的過程當中，容器的開發者和使用者都關注在鏡像上，感受不到進程沙盒的存在。進程沙盒的這些部分是由容器的運行態程序自動和鏡像加載在一塊兒的。

4、微服務與容器

從以上針對微服務和容器概念的回顧和分析來看，兩者的特性是很是匹配的。利用容器的各類特色可以便捷地實現微服務架構的各類設計須要。

所以，雖然微服務架構剛剛出現時也是運行在虛機之上的，但目前大多數的微服務都是基於容器來實現的。那麼設計針對微服務的監測也一樣要考慮到容器的特性。

在咱們的設計和印象當中，微服務應該是按照上圖這樣清晰的架構運轉的。然而實際狀況並不是如此。隨着微服務和容器規模的擴大，咱們真正面對的是以下圖同樣的場景。顯然，在這樣的場景下，要全面、準確、有效地實現對微服務的監測，是一個巨大的挑戰。

5、監測微服務的五大關鍵原則

微服務和容器的出現和大量應用，帶動了架構、開發、部署、運維等多個領域的創新，也對應用的監測提出了新的要求。在傳統架構中，監測關注的是虛機或主機上運行的單體應用。而在微服務+容器的架構下，應用已經分解爲更細粒度、相互隔離、獨立運行的進程。那麼針對微服務的監測也就須要轉向針對這些進程的關注。

Sysdig在這次大會上介紹了監測微服務應用須要遵循的五大關鍵原則：

一、監測容器，同時也要監測容器內運行的應用

針對於容器內運行的進程，監測要格外關注針對其使用資源的限制，以防止單個容器佔用和消耗主機的全部資源，從而影響到主機上其餘容器的運行。一樣，針對編排器一樣要監測和限制對主機資源的佔用，尤爲是在應用規模自動調整的時候，要保證合理地使用主機資源。

同時，咱們不能把容器當成黑盒，必須監測到容器內運行的各類應用，如各類服務進程、數據庫等。監測要收集這些應用運行的各類度量指標，如JVM的各類參數等。固然，監測也應該收集那些開發者本身定義的，針對容器內應用運行的各類度量指標。

二、監測業務自身的性能，而不是容器的性能

在實際運行當中，每個容器的生命週期一般都不會特別的長。容器的編排系統會隨時關注容器的運行狀態，當發生異常時，編排系統會自動的進行調整，如刪除有問題的容器，從新部署一個一樣的容器加以代替；或者根據容器運行的狀態自動地進行規模上的調整等 。而開發者和運維者應該集中關注容器內業務應用的運行狀態。

三、監測具備彈性，以及多地部署的服務

微服務的部署特性驅使咱們在設計的階段就要考慮到規模性的問題。當服務的規模從10擴展成20，擴展成50，甚至於擴展成100的時候，針對服務的監測要如何自動調整去覆蓋和適應這些自動擴展的規模。一樣，針對多地部署的服務，咱們又該如何根據不一樣的組織和分類，如站點、位置、區域等，來匯聚和統計服務的總體性能。這些都是在設計監測方案之初就要重點考慮的。

四、監測API

在微服務的架構當中，原有的單體應用被拆解成爲多個層面、更小粒度、獨立運行的服務。而API是這些服務暴露給其餘服務的惟一組件。同時，API也是訪問微服務的首要通信方式。

對API的運行、響應狀態的有效監測，對微服務的總體監測是十分重要的：

· 可以捕獲特定方法、功能或端點的運行瓶頸；

· 可以監測各個方法、功能或端點的調用頻率；

· 可以跟蹤用戶業務在多個系統之間的交互行爲。

五、微服務的監測體系要匹配組織架構

提到架構，咱們就不得不關注康威定律，即任意一個軟件都反映出製造它的團隊的組織結構，以下圖所示：

康威定律一樣適用於微服務的監測體系。要容許團隊根據本身的設計和理解來定義自身提供服務的監測指標、報警原則，以及監測數據的展現方式，畢竟他們是對這些服務最瞭解的人，也是最終爲服務的質量負責、解決服務問題的人。

6、總結

微服務架構的出現，以及結合容器技術的普遍使用，改變了應用的開發、部署、運維的原有模式，同時也對監測應用提出了更高的要求。Sysdig帶來的五大關鍵原則可以幫助咱們針對微服務和容器的特性，設計更爲全面、更有針對性的監測體系。

固然，隨着微服務架構和容器技術的不斷進化，監測的體系和原則也是要隨之不斷調整的。越早認識到這樣的轉變，就能更早更容易地適應架構和技術的更新。

參考文獻

· Principles of monitoring microservices

https://www.youtube.com/watch...

· The Five Principles of Monitoring Microservices

https://thenewstack.io/five-principles-monitoring-microservices

---

**歡迎觀看JFrog傑蛙每週二在線課堂，點擊報名：

https://www.bagevent.com/even...**