Service Mesh真的是雲原生應用的絕配嗎

Richard Li

隨着愈來愈多企業開始落地微服務架構，Service Mesh和相關的解決方案在社區內的討論熱度開始逐漸上漲。Service Mesh所提倡的「全棧可觀察性」、透明安全性、系統彈性等特性使人着迷，但它真的是雲原生應用的絕配嗎？本文將對Service Mesh什麼時候make sense、什麼時候不那麼make sense做出一些思考。

作好微服務架構可讓咱們更敏捷

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

「去中心化」的決策帶來了兩個關鍵結果。首先，軟件團隊能夠在架構、發佈、測試等方面做出「本地化」的最優決策，不須要依賴全局標準。舉個例子，每一個團隊都有本身的發佈工具，而不是單一的標準化應用發佈。第二，團隊能夠更快進行決策，傳統模式下韻味、架構等等集中功能之上的阻礙減小了。

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

採用微服務對您的組織、流程和體系結構具備深遠的影響。微服務架構自己是一個分佈式系統，在基於微服務架構的應用中，業務邏輯分佈在經過網絡相互通訊的多個服務之間，而分佈式系統有更多的故障模式（failure mode）。

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

隨着應用變得愈來愈複雜，對於失敗管理的需求也愈來愈迫切。當應用由少許微服務組城市，故障還比較容易隔離和排除，但想象數十個、上百個微服務，以及分佈在各地的團隊，咱們的失敗管理體系須要與應用一塊兒「伸縮」。

管理失敗

咱們通常會採起三種失敗管理策略：主動測試（proactive testing）、緩解（mitigation）、快速想用（rapid response）。

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

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工具庫)。

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

---

開源PaaS Rainbond在v3.6.0版本中加入了Service Mesh開箱即用的特性，主要特色包括業務代碼無入侵、跨語言&跨協議、支持主流微服務架構、經過插件式擴展來實現治理功能等。

• 開源PaaS Rainbond v3.6.0正式發佈，Service Mesh開箱即用
• 解讀Rainbond ServiceMesh微服務架構
• Rainbond插件體系設計簡介