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

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

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

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

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

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

在非容器化的環(huán)境中那些儀表化的進(jìn)程(比如在主機(jī)或VM用戶空間中的Agent)，對(duì)容器而言很可能無(wú)法很好的運(yùn)行，因?yàn)槿萜鞲芤嬗谛《?dú)立的進(jìn)程，并且需要保持盡可能少的依賴性。

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

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

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

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

越來(lái)越多的軟件部署需要編排系統(tǒng)將邏輯應(yīng)用藍(lán)圖轉(zhuǎn)換為物理的容器。常見(jiàn)的編排系統(tǒng)包括Kubernetes，MesosphereDC/OS和DockerSwarm。團(tuán)隊(duì)可以使用編排系統(tǒng)來(lái)(1)定義您的微服務(wù)(2)了解每個(gè)服務(wù)在部署中的當(dāng)前狀態(tài)。你可以認(rèn)為編排系統(tǒng)比容器本身更為重要，因?yàn)槿萜鞅旧淼膲勖嵌虝旱?它們只在存在的時(shí)間內(nèi)有效)，而你的服務(wù)對(duì)它們短暫生命周期的使用則至關(guān)重要。

DevOps團(tuán)隊(duì)?wèi)?yīng)該重新去定義警報(bào)，從而專注于監(jiān)控與服務(wù)體驗(yàn)相關(guān)的特征，因?yàn)檫@些警報(bào)是評(píng)估應(yīng)用程序是否會(huì)受到影響的第一道防線。但是設(shè)定這些警報(bào)是極具挑戰(zhàn)的工作，因?yàn)槿绻愕谋O(jiān)控系統(tǒng)不是container-native屬性，那就會(huì)變得異常困難。

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

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

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

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

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

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

監(jiān)控API

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

因此，對(duì)API的監(jiān)控是非常必要的。API監(jiān)控可以用很多種形式來(lái)實(shí)現(xiàn)，但很明顯不能僅僅局限于二進(jìn)制檢測(cè)。舉例來(lái)說(shuō)，以時(shí)間函數(shù)的方式來(lái)分析監(jiān)控過(guò)程中頻繁出現(xiàn)的端點(diǎn)就是一種非常有價(jià)值的方式，這樣可以幫助團(tuán)隊(duì)在服務(wù)的使用過(guò)程中檢測(cè)到是否有任何明顯的變化，無(wú)論是因?yàn)樵O(shè)計(jì)的變化還是用戶的變化。

與此同時(shí)，你還需要關(guān)注服務(wù)中那些最慢的端點(diǎn)，因?yàn)樗鼈兛赡軙?huì)暴露出系統(tǒng)中存在的嚴(yán)重問(wèn)題，或者至少能幫你指出系統(tǒng)中最需要優(yōu)化的地方。

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

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

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

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

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

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

結(jié)語(yǔ)

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

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

【編輯推薦】