譯者 | 陳峻

策劃 | 云昭

最近一段時(shí)間，服務(wù)網(wǎng)格和可觀測(cè)性已是微服務(wù)社區(qū)中的熱門話題。在此，我們將詳細(xì)地探討服務(wù)網(wǎng)格以及可觀測(cè)性技術(shù)棧，如何協(xié)助我們克服在使用微服務(wù)過(guò)程中的各種挑戰(zhàn)。

常見(jiàn)的微服務(wù)挑戰(zhàn) 

通常，微服務(wù)會(huì)給應(yīng)用上線的運(yùn)維工作引入大量的開(kāi)銷。我們?cè)谡{(diào)試和確保其持續(xù)運(yùn)行的過(guò)程中，往往會(huì)面臨如下方面的挑戰(zhàn)：

難以在分布式系統(tǒng)中調(diào)試錯(cuò)誤

在單體應(yīng)用（monolith）時(shí)代中，我們只需查看日志和進(jìn)行棧跟蹤，即可確定錯(cuò)誤的根本原因。而在微服務(wù)中，由于其本身的分布式特性，在出現(xiàn)錯(cuò)誤時(shí)，挖掘微服務(wù)的日志可能仍無(wú)法直接獲悉確切的問(wèn)題。相反，它只能簡(jiǎn)短地報(bào)告那些從具有依賴性的微服務(wù)處，收到的請(qǐng)求和/或響應(yīng)中存在的錯(cuò)誤。換句話說(shuō)，我們必須跟蹤整個(gè)網(wǎng)絡(luò)，以確定哪個(gè)微服務(wù)是導(dǎo)致問(wèn)題的根本原因。而且，這是一個(gè)非常耗時(shí)的過(guò)程。

難以識(shí)別系統(tǒng)中的瓶頸

在單體應(yīng)用中，識(shí)別性能瓶頸就像分析應(yīng)用本身一樣容易。通過(guò)基本分析，我們往往能夠準(zhǔn)確定位到代碼庫(kù)中，哪些方法最為耗時(shí)，以便將后續(xù)的優(yōu)化工作集中在這一小段代碼上。不過(guò)，定位導(dǎo)致整個(gè)系統(tǒng)變慢的微服務(wù)則是一項(xiàng)極具挑戰(zhàn)的工作。盡管在各項(xiàng)單獨(dú)的測(cè)試中，每個(gè)微服務(wù)似乎都能表現(xiàn)出色。但在現(xiàn)實(shí)的應(yīng)用場(chǎng)景中，每項(xiàng)服務(wù)所面對(duì)的負(fù)載可能存在著巨大的差異。畢竟其中的一些可能會(huì)成為其他微服務(wù)所依賴的核心微服務(wù)。這是在孤立的測(cè)試環(huán)境中很難復(fù)現(xiàn)的狀況。

難以維護(hù)微服務(wù)的依賴樹(shù)（Dependency Tree）

微服務(wù)的主要優(yōu)勢(shì)在于我們可以敏捷地發(fā)布新的軟件與服務(wù)。不過(guò)，在真實(shí)場(chǎng)景中，我們往往會(huì)因?yàn)槿缦率录斐尚掳l(fā)布的微服務(wù)會(huì)對(duì)其下游功能性產(chǎn)生多種影響：

• 在上游的依賴性的基礎(chǔ)上，發(fā)布新的具有依賴性的微服務(wù)
• 刪除了某個(gè)老舊系統(tǒng)里的仍然存在著依賴性、但已棄用的API
• 發(fā)布了一個(gè)會(huì)破壞現(xiàn)有API兼容性的微服務(wù)

當(dāng)微服務(wù)之間沒(méi)有明確的“依賴樹(shù)”時(shí)，上述情況會(huì)變得難以避免。而依賴樹(shù)則可以將各個(gè)組件之間的關(guān)系，更便捷地通知給適當(dāng)?shù)膱F(tuán)隊(duì)，以指定更好的發(fā)布計(jì)劃。

微服務(wù)的可觀測(cè)性

其實(shí)，上面提到的各種問(wèn)題都可以由可觀測(cè)性來(lái)解決。此處的可觀測(cè)性是一種根據(jù)系統(tǒng)生成的指標(biāo)和日志，來(lái)捕獲系統(tǒng)當(dāng)前狀態(tài)的做法。作為一個(gè)系統(tǒng)，它可以幫助我們監(jiān)控應(yīng)用程序的健康狀況，生成故障警報(bào)，并在問(wèn)題發(fā)生時(shí)，捕獲足夠的信息，以便后續(xù)的問(wèn)題調(diào)試。

圖 1：具有開(kāi)源示例的可觀測(cè)性技術(shù)棧組件

如上圖所示，可觀測(cè)性技術(shù)棧通常包含如下組件：

• 指標(biāo)/日志源——用來(lái)生成數(shù)據(jù)的代理或庫(kù)
• 指標(biāo)/日志搬運(yùn)器——將數(shù)據(jù)傳輸?shù)酱鎯?chǔ)引擎的代理，通常被嵌入在指標(biāo)源中
• 收集器/存儲(chǔ)——負(fù)責(zé)存儲(chǔ)已生成數(shù)據(jù)的有狀態(tài)服務(wù)
• 儀表板——通過(guò)全面的圖表，滿足數(shù)據(jù)的解釋和摘要
• 警報(bào)管理器——負(fù)責(zé)觸發(fā)通知的服務(wù)

我們可以通過(guò)各種強(qiáng)大的開(kāi)源工具，來(lái)簡(jiǎn)化設(shè)置整個(gè)可觀測(cè)性技術(shù)棧的過(guò)程。?

服務(wù)網(wǎng)格（Service Meshes）介紹

從原理上說(shuō)，可觀測(cè)性主要是通過(guò)捕獲網(wǎng)絡(luò)中的遙測(cè)數(shù)據(jù)（telemetry），運(yùn)用良好的網(wǎng)絡(luò)洞察力，來(lái)協(xié)助開(kāi)發(fā)者解決前文提到的各種問(wèn)題。當(dāng)然，生成遙測(cè)數(shù)據(jù)的任務(wù)是一個(gè)極其繁瑣且易錯(cuò)的過(guò)程。開(kāi)發(fā)人員不但要保證在功能上的安全實(shí)現(xiàn)，而且要讓數(shù)據(jù)通信能夠抵御可能發(fā)生的故障。為此，我們可以通過(guò)諸如：Istio、Linkerd或Consul Connect之類的服務(wù)網(wǎng)格，以解耦的方式，將微服務(wù)網(wǎng)絡(luò)的復(fù)雜性下放到底層平臺(tái)。下面，讓我們以Istio為例，來(lái)了解一下服務(wù)網(wǎng)格是工作原理。

?圖 2：典型的服務(wù)網(wǎng)格架構(gòu)圖片來(lái)源--https://istio.io/latest/docs/ops/deployment/architecture

如上圖所示，服務(wù)網(wǎng)格有兩個(gè)主要組件：數(shù)據(jù)平面（data plane）和控制平面（control plane）。其中，數(shù)據(jù)平面負(fù)責(zé)管理由微服務(wù)產(chǎn)生的所有網(wǎng)絡(luò)流量。為此，服務(wù)網(wǎng)格會(huì)在每個(gè)微服務(wù)旁注入一個(gè)sidecar代理。我們可以采用Envoy作為sidecar，負(fù)責(zé)透明地?cái)r截流過(guò)服務(wù)的所有流量。而控制平面僅負(fù)責(zé)配置代理。也就是說(shuō)，沒(méi)有任何應(yīng)用流量會(huì)到達(dá)控制平面。

如圖 2 所示，服務(wù)網(wǎng)格架構(gòu)可協(xié)助我們抽象出所有的復(fù)雜性，且無(wú)需編寫(xiě)任何代碼。同時(shí)，服務(wù)網(wǎng)格可以運(yùn)用如下三大優(yōu)勢(shì)，幫助我們管理基于微服務(wù)的應(yīng)用架構(gòu)的各個(gè)方面：

• 全面了解流量是如何流動(dòng)的
• 控制網(wǎng)絡(luò)流量
• 保護(hù)微服務(wù)通信

全面了解流量是如何流動(dòng)的

在下面的圖 3 中，應(yīng)用A正在向應(yīng)用B發(fā)出請(qǐng)求。由于位于每個(gè)應(yīng)用旁邊的Envoy代理正在攔截請(qǐng)求，因此它們對(duì)于流經(jīng)這兩個(gè)微服務(wù)的流量具有完全的可見(jiàn)性。例如，Envoy代理可以通過(guò)檢查流量，以收集到諸如：發(fā)出的請(qǐng)求數(shù)和每個(gè)請(qǐng)求的響應(yīng)狀態(tài)代碼等信息。具體而言，服務(wù)網(wǎng)格可以幫助我們回答以下問(wèn)題：

• 哪兩個(gè)服務(wù)正在通信？
• 被每個(gè)微服務(wù)觀察到的請(qǐng)求的吞吐量有多少？
• 每個(gè)API的錯(cuò)誤率是多少？

圖 3：服務(wù)網(wǎng)格可以協(xié)助收集指標(biāo)

控制網(wǎng)絡(luò)流量

服務(wù)網(wǎng)格并非在一旁作壁上觀，它會(huì)積極地參與塑造所有網(wǎng)絡(luò)流量的工作。例如，被用作sidecar的Envoy代理不但具有HTTP感知能力，并且可以被配置為實(shí)現(xiàn)如下功能：

• 自動(dòng)嘗試——在遇到網(wǎng)絡(luò)錯(cuò)誤時(shí)重放某個(gè)請(qǐng)求
• 斷路——將已停止響應(yīng)的上游微服務(wù)的副本列入黑名單
• 請(qǐng)求重寫(xiě)——在滿足某些條件時(shí)，設(shè)置標(biāo)頭或修改請(qǐng)求的URL

圖 4：服務(wù)網(wǎng)格可以控制網(wǎng)絡(luò)流量

此外，代理還可以根據(jù)一定的權(quán)重去分割流量。例如，我們可以通過(guò)支持金絲雀（Canary）部署等高級(jí)方式，將代理配置為將95%的傳入流量，發(fā)送到服務(wù)的穩(wěn)定版本；而將其余的流浪重定向到金絲雀版本處，以簡(jiǎn)化發(fā)布管理的流程。

保護(hù)微服務(wù)通信

使用服務(wù)網(wǎng)格的另一個(gè)優(yōu)勢(shì)便是安全性。我們的sidecar代理可以被配置為使用雙向TLS，以確保所有的網(wǎng)絡(luò)流量在傳輸過(guò)程中，都得到自動(dòng)加密。其中，mTLS所需的證書(shū)管理和置換任務(wù)，都可以由服務(wù)網(wǎng)格的控制平面來(lái)自動(dòng)化實(shí)現(xiàn)。

服務(wù)網(wǎng)格還可以通過(guò)選擇性地允許哪些服務(wù)相互進(jìn)行通信，來(lái)協(xié)助訪問(wèn)控制。據(jù)此，我們可以有效地消除諸如中間人（man-in-the-middle）攻擊等安全漏洞。

圖 5：服務(wù)網(wǎng)格可以保護(hù)網(wǎng)絡(luò)流量

?服務(wù)網(wǎng)格如何協(xié)助提高可觀測(cè)性？

下面，讓我們繼續(xù)深入了解由服務(wù)網(wǎng)格捕獲的遙測(cè)數(shù)據(jù)可以支持哪些用例。

分布式跟蹤

針對(duì)上文提到的有關(guān)調(diào)試微服務(wù)的挑戰(zhàn)，我們可以通過(guò)分布式跟蹤，來(lái)捕獲請(qǐng)求的生命周期全過(guò)程。據(jù)此，我們可以僅通過(guò)一張圖表，就能夠輕松地找出問(wèn)題的根本原因。

通常，大多數(shù)服務(wù)網(wǎng)格都會(huì)自動(dòng)收集網(wǎng)絡(luò)行蹤，并發(fā)送到Jaeger等工具處。因此，只需要在應(yīng)用程序的代碼中，轉(zhuǎn)發(fā)相關(guān)的HTTP標(biāo)頭即可。

流量指標(biāo)

服務(wù)網(wǎng)格也可以幫助我們收集如下值得關(guān)注的三大“黃金監(jiān)控信號(hào)”，以確定服務(wù)的健康狀況：

• 請(qǐng)求吞吐量——被某個(gè)微服務(wù)正在服務(wù)的請(qǐng)求數(shù)。
• 響應(yīng)錯(cuò)誤率——失敗請(qǐng)求的百分比。
• 響應(yīng)延遲——微服務(wù)響應(yīng)所需的時(shí)間。它往往是一個(gè)直方圖，可以從中提取n個(gè)百分位的延遲。

當(dāng)然，服務(wù)網(wǎng)格還能收集到許多其他類型的指標(biāo)。這些指標(biāo)可用于支持各種豐富的用例。例如：

• 根據(jù)請(qǐng)求的吞吐量等高級(jí)參數(shù)啟用擴(kuò)展
• 啟用諸如：速率限制和斷路等高級(jí)流量控制功能
• 執(zhí)行自動(dòng)化的金絲雀部署和A/B測(cè)試

網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)

服務(wù)網(wǎng)格也可以通過(guò)將跟蹤數(shù)據(jù)與流量指標(biāo)相結(jié)合，來(lái)協(xié)助我們構(gòu)建自動(dòng)化的網(wǎng)絡(luò)拓?fù)洹Ｍㄟ^(guò)網(wǎng)絡(luò)拓?fù)洌覀儽憧梢砸荒苛巳坏乜梢暬麄€(gè)微服務(wù)的依賴樹(shù)。此外，服務(wù)網(wǎng)格還可以突出顯示集群的網(wǎng)絡(luò)健康狀況，以幫助我們有效地識(shí)別應(yīng)用程序中的瓶頸。

?總結(jié)

綜上所述，服務(wù)網(wǎng)格主要能夠在如下方面提高微服務(wù)的可觀測(cè)性：

• 通過(guò)生成分布式的跟蹤數(shù)據(jù)，來(lái)簡(jiǎn)化調(diào)試
• 通過(guò)捕獲微服務(wù)的黃金監(jiān)控信號(hào)，來(lái)?yè)?dān)任關(guān)鍵指標(biāo)的來(lái)源
• 生成網(wǎng)絡(luò)拓?fù)?/span>

可見(jiàn)，服務(wù)網(wǎng)格非常實(shí)用，而且無(wú)需編寫(xiě)任何代碼。如果您對(duì)其感興趣的話目前，還可以通過(guò)如下指南與鏈接，去深入了解服務(wù)網(wǎng)格在微服務(wù)可觀測(cè)性方面已經(jīng)有了不少的各種實(shí)踐，相關(guān)Istio、LinkerD、Kuma、Prometheus、Grafana的應(yīng)用細(xì)節(jié)和案例都可以從官網(wǎng)上得到，不失為一種可觀測(cè)性利器。

譯者介紹

陳峻 （Julian Chen），51CTO社區(qū)編輯，具有十多年的IT項(xiàng)目實(shí)施經(jīng)驗(yàn)，善于對(duì)內(nèi)外部資源與風(fēng)險(xiǎn)實(shí)施管控，專注傳播網(wǎng)絡(luò)與信息安全知識(shí)與經(jīng)驗(yàn)；持續(xù)以博文、專題和譯文等形式，分享前沿技術(shù)與新知；經(jīng)常以線上、線下等方式，開(kāi)展信息安全類培訓(xùn)與授課。

原文鏈接：

https://dzone.com/articles/how-a-service-mesh-simplifies-microservice-observa