[[179290]]

我們對(duì)微服務(wù)的需求可以歸納為一個(gè)詞：速度。這種更快提供功能完善且可靠的軟件的需求，徹底改變了軟件開(kāi)發(fā)模式。毫無(wú)疑問(wèn)，這個(gè)改變對(duì)軟件管理，包括系統(tǒng)監(jiān)控的方式，都產(chǎn)生了影響。在這篇文章里，我們將重點(diǎn)關(guān)注放在有效地監(jiān)控產(chǎn)品環(huán)境中的微服務(wù)所需做出的主要改變。我們將為這一新的軟件架構(gòu)擬定 5 條指導(dǎo)性原則來(lái)調(diào)整你的監(jiān)控方法。

監(jiān)控是微服務(wù)控制系統(tǒng)的關(guān)鍵部分，你的軟件越復(fù)雜，那么你就越難了解其性能及問(wèn)題排障。鑒于軟件交付發(fā)生的巨大改變，監(jiān)控系統(tǒng)同樣需要進(jìn)行徹底的改造，以便在微服務(wù)環(huán)境下表現(xiàn)更好。下面我們將介紹監(jiān)控微服務(wù)的 5 條原則，如下：

1. 監(jiān)控容器及其里面的東西。
2. 在服務(wù)性能上做監(jiān)控，而不是容器性能。
3. 監(jiān)控彈性和多地部署的服務(wù)。
4. 監(jiān)控 API。
5. 將您的監(jiān)控映射到您的組織結(jié)構(gòu)。

利用這 5 條原則，你可以在向微服務(wù)前進(jìn)的道路上，建立更有效的對(duì)微服務(wù)的監(jiān)控。這些原則，可以讓你應(yīng)對(duì)隨著微服務(wù)而來(lái)的技術(shù)變化和組織變化。

微服務(wù)監(jiān)控的原則

1、監(jiān)控容器及其里面的東西

容器因構(gòu)建微服務(wù)而凸顯其重要性，容器的速度、可移植性和隔離特性讓開(kāi)發(fā)者很容易就愛(ài)上了微服務(wù)模型。容器的好處已經(jīng)寫的夠多了，毋庸贅述。

容器對(duì)于其外圍的系統(tǒng)來(lái)說(shuō)就像是黑盒子。這對(duì)于開(kāi)發(fā)來(lái)說(shuō)大有裨益，從開(kāi)發(fā)環(huán)境到生產(chǎn)環(huán)境，甚至從開(kāi)發(fā)者的筆記本到云端，為它們帶來(lái)高度的可移植性。但是當(dāng)運(yùn)行起來(lái)后，監(jiān)控和解決服務(wù)問(wèn)題時(shí)，這個(gè)黑盒子讓常規(guī)的方法難以奏效了，我們會(huì)想：容器里到底在運(yùn)行著什么?程序和代碼運(yùn)行性能如何?它有什么重要的輸出指標(biāo)嗎?從 DevOps 的視角，你需要對(duì)容器有更深的了解而不是僅僅知道有一些容器的存在。

非容器環(huán)境下衡量的典型做法，是讓一個(gè)代理程序運(yùn)行在主機(jī)或者虛機(jī)上的用戶空間里，但這并不適用于容器。因?yàn)槿萜鞯膬?yōu)點(diǎn)是小，將各種進(jìn)程分離開(kāi)來(lái)，并盡可能的減少依賴關(guān)系。

而且，從規(guī)模上看，成千上萬(wàn)的監(jiān)測(cè)代理，對(duì)即使是一個(gè)中等大小的部署都是一個(gè)昂貴的資源浪費(fèi)和管理的噩夢(mèng)。對(duì)于容器有兩個(gè)潛在的解決方案：1)要求你的開(kāi)發(fā)人員直接監(jiān)控他們的代碼，或者2)利用一個(gè)通用的內(nèi)核級(jí)的檢測(cè)方法來(lái)查看主機(jī)上的所有應(yīng)用程序和容器活動(dòng)。這里我們不會(huì)深入說(shuō)明，但每一種方法都有其優(yōu)點(diǎn)和缺點(diǎn)。

2、 利用業(yè)務(wù)流程系統(tǒng)提醒服務(wù)性能

理解容器容器中的運(yùn)行數(shù)據(jù)并不容易，一個(gè)單一容器相比組成一個(gè)功能或服務(wù)的容器聚合，測(cè)量復(fù)雜度要低得多。

這特別適用于應(yīng)用程序級(jí)別的信息，比如哪個(gè)請(qǐng)求擁有最短響應(yīng)時(shí)間，或者哪些 URL 遇到最多的錯(cuò)誤，但它同樣也適用于架構(gòu)級(jí)別的監(jiān)測(cè)，比如哪個(gè)服務(wù)的容器使用 CPU 資源超過(guò)了事先分配的資源數(shù)。

越來(lái)越多的軟件部署需要一個(gè)編排系統(tǒng)orchestration system，將應(yīng)用程序的邏輯規(guī)劃轉(zhuǎn)化到物理的容器中。常見(jiàn)的編排系統(tǒng)包括 Kubernetes、Mesosphere DC/OS 和 Docker Swarm。團(tuán)隊(duì)可以用一個(gè)編排系統(tǒng)來(lái)(1)定義微服務(wù)(2)理解部署的每個(gè)服務(wù)的當(dāng)前狀態(tài)。你可以認(rèn)為編排系統(tǒng)甚至比容器還重要。容器是短暫的，只有滿足你的服務(wù)需求才會(huì)存在。

DevOps 團(tuán)隊(duì)?wèi)?yīng)該將告警重點(diǎn)放到運(yùn)行特征上，以盡可能貼近監(jiān)控服務(wù)的體驗(yàn)。如果應(yīng)用受到了影響，這些告警是評(píng)估事態(tài)的第一道防線。但是獲得這些告警并不容易，除非你的監(jiān)控系統(tǒng)是基于原生于容器的。

原生容器Container-native解決方案利用編排元數(shù)據(jù)orchestration metadata來(lái)動(dòng)態(tài)聚合容器和應(yīng)用程序數(shù)據(jù)，并按每個(gè)服務(wù)計(jì)算監(jiān)控度量。根據(jù)您的編排工具，您可能想在不同層次進(jìn)行深入檢測(cè)。比如，在 Kubernetes 里，你通常有 Namespace、ReplicaSet、Pod 和一些其他容器。聚合這些不同的層，對(duì)排除邏輯故障是很有必要的，與構(gòu)成服務(wù)的容器的物理部署無(wú)關(guān)。

3、 監(jiān)控彈性Elastic和多地部署Multi-Location的服務(wù)

彈性服務(wù)不是一個(gè)新概念，但是它在原生容器環(huán)境中的變化速度比在虛擬環(huán)境中快的多。迅速的變化會(huì)嚴(yán)重影響檢測(cè)系統(tǒng)的正常運(yùn)行。

監(jiān)測(cè)傳統(tǒng)的系統(tǒng)經(jīng)常需要根據(jù)軟件部署，手動(dòng)調(diào)整檢查指標(biāo)。這種調(diào)整可以是具體的，如定義要捕獲的單個(gè)指標(biāo)，或基于應(yīng)用程序在一個(gè)特定的容器中的操作配置要收集的數(shù)據(jù)。在小規(guī)模上(比如幾十個(gè)容器)我們可以接受，但是再大規(guī)模就難以承受了。微服務(wù)的集中監(jiān)控必須能夠自由的隨彈性服務(wù)而增長(zhǎng)和縮減，無(wú)需人工干預(yù)。

比如，如果 DevOps 團(tuán)隊(duì)必須手動(dòng)定義容器包含哪個(gè)服務(wù)需要監(jiān)控，他們毫無(wú)疑問(wèn)會(huì)失手，因?yàn)?Kubernetes 或者 Mesos 每天都會(huì)定期創(chuàng)建新的容器。同樣，如果代碼發(fā)布并置于生產(chǎn)環(huán)境時(shí)要求運(yùn)維團(tuán)隊(duì)安裝一個(gè)定制的狀態(tài)端點(diǎn)custom stats endpoint，也給開(kāi)發(fā)者從 Docker 倉(cāng)庫(kù)獲取基礎(chǔ)鏡像帶來(lái)更多的挑戰(zhàn)。

在生產(chǎn)環(huán)境中，建立面向跨越多個(gè)數(shù)據(jù)中心或多個(gè)云的復(fù)雜部署的監(jiān)控，比如，如果你的服務(wù)跨越私有數(shù)據(jù)中心和 AWS，那么亞馬遜的 AWS CloudWatch 就很難做到這一點(diǎn)。這就要求我們建立一個(gè)跨不同地域的監(jiān)控系統(tǒng)，并可在動(dòng)態(tài)的原生容器環(huán)境下運(yùn)行。

4、 監(jiān)控 API

在微服務(wù)環(huán)境中，API 接口是通用的。本質(zhì)上，它們是將服務(wù)暴露給其它團(tuán)隊(duì)的唯一組件。事實(shí)上，API 的響應(yīng)和一致性可以看作是“內(nèi)部 SLA”，即使還沒(méi)有定義一個(gè)正式的 SLA(服務(wù)等級(jí)協(xié)議)。

因此，API 接口的監(jiān)控也是必要的。API 監(jiān)控可以有不同的形式，但是很顯然它絕對(duì)不是簡(jiǎn)單的二進(jìn)制上下檢查。例如，了解像時(shí)間函數(shù)這樣的最常使用的端點(diǎn)endpoint是有價(jià)值的。這使得團(tuán)隊(duì)可以看到服務(wù)使用的變化，無(wú)論是由于設(shè)計(jì)變更或用戶的改變。

你也可以記錄服務(wù)最緩慢的端點(diǎn)，這些可能揭示出重大的問(wèn)題，或者至少指向需要在系統(tǒng)中做優(yōu)化的區(qū)域。

最后，跟蹤系統(tǒng)服務(wù)響應(yīng)的能力是另一個(gè)很重要的能力，它主要是開(kāi)發(fā)者使用，也能幫助你了解整體用戶體驗(yàn)，同時(shí)將信息基于底層和應(yīng)用程序視角分成兩大部分。

5、 將您的監(jiān)控映射到您的組織結(jié)構(gòu)

這篇文章著重在微服務(wù)和監(jiān)控上，像其他科技文章一樣，這是因?yàn)楹芏嗳硕缄P(guān)注此層面。

對(duì)于那些熟悉康威定律Conway’s law的人來(lái)說(shuō)，系統(tǒng)的設(shè)計(jì)是基于開(kāi)發(fā)團(tuán)隊(duì)的組織結(jié)構(gòu)。創(chuàng)造更快，更敏捷的軟件的壓力推動(dòng)了團(tuán)隊(duì)去思考重新調(diào)整他們的開(kāi)發(fā)組織和管理它的規(guī)則。

[[179291]]

所以，如果他們想從這個(gè)新的軟件架構(gòu)(微服務(wù))上獲益，他們的團(tuán)隊(duì)必須將微服務(wù)映射到團(tuán)隊(duì)自身中。也就是說(shuō)，他們需要更小的更松散耦合的團(tuán)隊(duì)，可以選擇自己的方向只要能夠滿足整個(gè)需求即可。在每一個(gè)團(tuán)隊(duì)中，對(duì)于開(kāi)發(fā)語(yǔ)言的使用，bug 的提交甚至工作職責(zé)都會(huì)有更大的控制能力。

DevOps 團(tuán)隊(duì)對(duì)此可以啟用一個(gè)監(jiān)控平臺(tái)：讓每一個(gè)微服務(wù)團(tuán)隊(duì)可以有自己的警報(bào)，度量指標(biāo)，和控制面板，同時(shí)也要給出整體系統(tǒng)的視圖。

總結(jié)

讓微服務(wù)流行起來(lái)的是快捷。開(kāi)發(fā)組織要想更快的為客戶提供更多的功能，然后微服務(wù)技術(shù)就來(lái)了，架構(gòu)轉(zhuǎn)向微服務(wù)并且容器的流行讓快捷開(kāi)發(fā)成為可能，所有相關(guān)的進(jìn)程理所當(dāng)然的搭上了這輛火車。

最后，基本的監(jiān)控原則需要適應(yīng)伴隨微服務(wù)而來(lái)的技術(shù)和結(jié)構(gòu)。越早認(rèn)識(shí)到這種轉(zhuǎn)變的開(kāi)發(fā)團(tuán)隊(duì)，能更早更容易的適應(yīng)微服務(wù)這一新的架構(gòu)。