隨著越來越多企業(yè)開始落地微服務(wù)架構(gòu)，Service Mesh和相關(guān)的解決方案在社區(qū)內(nèi)的討論熱度開始逐漸上漲。Service Mesh所提倡的“全棧可觀察性”、透明安全性、系統(tǒng)彈性等特性令人著迷，但它真的是云原生應(yīng)用的絕配嗎?本文將對Service Mesh何時make sense、何時不那么make sense作出一些思考。

[[236296]]

做好微服務(wù)架構(gòu)可以讓我們更敏捷

當下來看，產(chǎn)品和服務(wù)的“time to market”決定了企業(yè)的競爭力，能夠?qū)κ袌龊涂蛻粜枨罂焖俜磻?yīng)的公司想不成功都難。微服務(wù)架構(gòu)為軟件敏捷性和整個工作流的“速度”提供了強有力的支持，通過授權(quán)不同團隊分別處理應(yīng)用的不同部分，決策是“去中心化”的。

“去中心化”的決策帶來了兩個關(guān)鍵結(jié)果。首先，軟件團隊可以在架構(gòu)、發(fā)布、測試等方面作出“本地化”的***決策，不需要依賴全局標準。舉個例子，每個團隊都有自己的發(fā)布工具，而不是單一的標準化應(yīng)用發(fā)布。第二，團隊可以更快進行決策，傳統(tǒng)模式下韻味、架構(gòu)等等集中功能之上的阻礙減少了。

微服務(wù)架構(gòu)不是“免費”的——帶來了新的失敗模式

采用微服務(wù)對您的組織、流程和體系結(jié)構(gòu)具有深遠的影響。微服務(wù)架構(gòu)本身是一個分布式系統(tǒng)，在基于微服務(wù)架構(gòu)的應(yīng)用中，業(yè)務(wù)邏輯分布在通過網(wǎng)絡(luò)相互通信的多個服務(wù)之間，而分布式系統(tǒng)有更多的故障模式(failure mode)。

考慮到這些失敗模式，有一個體系結(jié)構(gòu)和過程來防止小的失敗變成大的失敗是非常重要的。當我們很“快”的時候，失敗是不可避免的，例如服務(wù)更新時引入了錯誤，服務(wù)在負載下崩潰等等。

隨著應(yīng)用變得越來越復(fù)雜，對于失敗管理的需求也越來越迫切。當應(yīng)用由少量微服務(wù)組城市，故障還比較容易隔離和排除，但想象數(shù)十個、上百個微服務(wù)，以及分布在各地的團隊，我們的失敗管理體系需要與應(yīng)用一起“伸縮”。

管理失敗

我們一般會采取三種失敗管理策略：主動測試(proactive testing)、緩解(mitigation)、快速想用(rapid response)。

1. 主動測試：利用流程和系統(tǒng)來測試應(yīng)用或服務(wù)，以便盡早發(fā)現(xiàn)故障。QA通常包含在這一方法中，雖然傳統(tǒng)測試團隊專注于預(yù)發(fā)布測試，但現(xiàn)在經(jīng)常擴展到生產(chǎn)測試。
2. 緩解：實施特定策略以便在特定故障發(fā)生時減少影響和損失。例如，取保服務(wù)多個實例間的負載均衡，當單個實例失敗，整個服務(wù)仍然可以相應(yīng)
3. 快速反應(yīng)：通過流程和系統(tǒng)快速識別和處理特定故障

Service mesh

當服務(wù)失敗時，會對其上游和下游服務(wù)產(chǎn)生影響。通過正確管理服務(wù)之間的通信，可以極大地減輕失敗服務(wù)的影響。這就是Service Mesh的用武之地。

Service Mesh管理服務(wù)級別(例如7層代理)通信，提供了強大的原語，可用于所有三種失敗管理策略：

動態(tài)路由，可用于不同的發(fā)布和測試策略，如金絲雀路由、流量陰影或藍綠部署

彈性，通過諸如斷路和速率限制等策略來減輕故障的影響

可觀察性，通過收集度量標準，為服務(wù)間通信添加context(例如跟蹤數(shù)據(jù))來提高響應(yīng)時間

Service Mesh以一種對應(yīng)用開發(fā)人員非常透明的方式添加這些特性。

Service Mesh可以幫助我們更快構(gòu)建應(yīng)用嗎?

決定Service Mesh對于我們的企業(yè)是否有益，首先要思考兩個關(guān)鍵問題：

• 服務(wù)拓撲結(jié)構(gòu)有多復(fù)雜?
• 如何將Service Mesh集成到軟件開發(fā)生命周期中?

服務(wù)拓撲

如果只是單個微服務(wù)，Service Mesh的好處是有限的。增量版本也可以通過現(xiàn)有的基礎(chǔ)設(shè)施(如Kubernetes或API網(wǎng)關(guān))來完成。

然而隨著服務(wù)拓撲結(jié)構(gòu)越來越復(fù)雜，Service Mesh將發(fā)揮巨大威力。需要考慮的關(guān)鍵約束是服務(wù)調(diào)用鏈的深度。如果您有一個淺層的拓撲結(jié)構(gòu)，您的monolith直接調(diào)用了十幾種微服務(wù)，那么Service Mesh的好處仍然是有限的。當您引入更多的服務(wù)到服務(wù)的通信時，服務(wù)A調(diào)用服務(wù)B調(diào)用服務(wù)C，Service Mesh就變得十分重要了。

將您的服務(wù)網(wǎng)格集成到您的SDLC中

Service Mesh對于服務(wù)是同名的，它是一個豐富的7層網(wǎng)絡(luò)，微服務(wù)不需要任何的代碼修改。

然而部署Service Mesh并不會自動加速應(yīng)用的速率和敏捷性。我們需要將Service Mesh集成到開發(fā)過程中。

將實現(xiàn)故障管理策略作為SDLC的一部分

Service Mesh為故障管理提供了強大的原語，接下來我們將討論各個失敗管理策略以及如何應(yīng)用到SDLC中。

主動測試

微服務(wù)應(yīng)用的測試策略應(yīng)該盡可能貼近真實情況。考慮到多服務(wù)應(yīng)用的復(fù)雜性，當前的測試策略強調(diào)在生產(chǎn)中進行測試(或使用生產(chǎn)數(shù)據(jù))。

Service Mesh通過控制L7傳輸?shù)椒?wù)的流量來在生產(chǎn)環(huán)境中進行測試。例如，服務(wù)網(wǎng)格可以將1%的流量路由到服務(wù)的v1.1版本, 99%的流量路由到v1.0(金絲雀部署)。這些功能通過聲明式路由規(guī)則(例如linkerd dtab或Istio路由規(guī)則)公開。

Service Mesh不是主動測試的唯一方法。其他補充策略包括使用容器調(diào)度器(如Kubernetes)進行滾動更新、可以進行金絲雀部署的API網(wǎng)關(guān)或chaos engineering。

有了所有這些策略，誰管理測試工作流的問題就變得很明顯了。在Service Mesh中，路由規(guī)則可以由管理網(wǎng)格的同一團隊集中管理。

緩解

由于各種原因，服務(wù)可能會失敗：代碼錯誤、資源不足、硬件故障。限制失敗服務(wù)的爆炸半徑對于整個應(yīng)用程序繼續(xù)運行(盡管處于降級狀態(tài))非常重要。

Service Mesh通過負載平衡、斷路器和服務(wù)到服務(wù)通信的速率限制等彈性模式來減輕故障的影響。例如在重載下的服務(wù)可以限制速率，以便仍然處理某些響應(yīng)，而不會導致整個服務(wù)在負載下崩潰。

減輕失敗的其他策略包括使用智能RPC庫(例如Hystrix)或依賴容器調(diào)度程序。像Kubernetes這樣的容器調(diào)度器支持健康檢查、自動擴展和對不響應(yīng)健康檢查的服務(wù)的動態(tài)路由。

當為給定的服務(wù)適當?shù)嘏渲眠@些緩解策略時，它們是最有效的。例如，不同的服務(wù)可以處理不同數(shù)量的請求，需要不同的速率限制。如何制定利率限制等政策?Netflix已經(jīng)實現(xiàn)了一些自動配置算法來設(shè)置這些值。其他方法是將這些功能公開給服務(wù)作者，他們可以正確配置服務(wù)。

可觀察性

失敗是不可避免的。實現(xiàn)可觀察性——跨越監(jiān)控、警報/可視化、分布式跟蹤和日志記錄——對于將響應(yīng)時間最小化到給定的故障是非常重要的。

Service Mesh自動收集關(guān)于服務(wù)到服務(wù)通信的詳細指標，包括吞吐量、延遲和可用性的數(shù)據(jù)。此外，服務(wù)網(wǎng)格可以注入必要的headers來支持分布式跟蹤。注意，這些headers仍然需要由服務(wù)本身傳播。

收集類似度量的其他方法包括使用監(jiān)視代理、通過statsd收集度量以及通過庫實現(xiàn)跟蹤(例如，Jaeger工具庫)。

可觀察性的一個重要組成部分是向服務(wù)作者公開警報和可視化。收集度量只是***步，考慮您的服務(wù)作者如何創(chuàng)建適合于給定服務(wù)的警報和可視化對于關(guān)閉可觀察性循環(huán)非常重要。