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

[[236296]]

做好微服務架構可以讓我們更敏捷

當下來看，產品和服務的“time to market”決定了企業的競爭力，能夠對市場和客戶需求快速反應的公司想不成功都難。微服務架構為軟件敏捷性和整個工作流的“速度”提供了強有力的支持，通過授權不同團隊分別處理應用的不同部分，決策是“去中心化”的。

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

微服務架構不是“免費”的——帶來了新的失敗模式

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

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

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

管理失敗

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

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

Service mesh

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

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

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

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

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

Service Mesh以一種對應用開發人員非常透明的方式添加這些特性。

Service Mesh可以幫助我們更快構建應用嗎?

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

• 服務拓撲結構有多復雜?
• 如何將Service Mesh集成到軟件開發生命周期中?

服務拓撲

如果只是單個微服務，Service Mesh的好處是有限的。增量版本也可以通過現有的基礎設施(如Kubernetes或API網關)來完成。

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

將您的服務網格集成到您的SDLC中

Service Mesh對于服務是同名的，它是一個豐富的7層網絡，微服務不需要任何的代碼修改。

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

將實現故障管理策略作為SDLC的一部分

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

主動測試

微服務應用的測試策略應該盡可能貼近真實情況。考慮到多服務應用的復雜性，當前的測試策略強調在生產中進行測試(或使用生產數據)。

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

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

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

緩解

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

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

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

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

可觀察性

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

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

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

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