譯者 | 陳峻

策劃 | 云昭

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

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

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

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

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

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

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

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

微服務(wù)的主要優(yōu)勢在于我們可以敏捷地發(fā)布新的軟件與服務(wù)。不過，在真實場景中，我們往往會因為如下事件，造成新發(fā)布的微服務(wù)會對其下游功能性產(chǎn)生多種影響：

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

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

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

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

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

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

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

我們可以通過各種強大的開源工具，來簡化設(shè)置整個可觀測性技術(shù)棧的過程。?

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

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

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

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

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

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

全面了解流量是如何流動的

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

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

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

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

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

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

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

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

保護微服務(wù)通信

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

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

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

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

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

分布式跟蹤

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

通常，大多數(shù)服務(wù)網(wǎ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)控信號”，以確定服務(wù)的健康狀況：

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

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

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

網(wǎng)絡(luò)拓撲結(jié)構(gòu)

服務(wù)網(wǎng)格也可以通過將跟蹤數(shù)據(jù)與流量指標(biāo)相結(jié)合，來協(xié)助我們構(gòu)建自動化的網(wǎng)絡(luò)拓撲。通過網(wǎng)絡(luò)拓撲，我們便可以一目了然地可視化整個微服務(wù)的依賴樹。此外，服務(wù)網(wǎng)格還可以突出顯示集群的網(wǎng)絡(luò)健康狀況，以幫助我們有效地識別應(yīng)用程序中的瓶頸。

?總結(jié)

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

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

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

譯者介紹

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

原文鏈接：

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