Service Mesh真的是云原生應(yīng)用的絕配嗎
隨著越來越多企業(yè)開始落地微服務(wù)架構(gòu)，Service Mesh和相關(guān)的解決方案在社區(qū)內(nèi)的討論熱度開始逐漸上漲。Service Mesh所提倡的“全棧可觀察性”、透明安全性、系統(tǒng)彈性等特性令人著迷，但它真的是云原生應(yīng)用的絕配嗎?本文將對(duì)Service Mesh何時(shí)make sense、何時(shí)不那么make sense作出一些思考。
做好微服務(wù)架構(gòu)可以讓我們更敏捷
當(dāng)下來看，產(chǎn)品和服務(wù)的“time to market”決定了企業(yè)的競(jìng)爭(zhēng)力，能夠?qū)κ袌?chǎng)和客戶需求快速反應(yīng)的公司想不成功都難。微服務(wù)架構(gòu)為軟件敏捷性和整個(gè)工作流的“速度”提供了強(qiáng)有力的支持，通過授權(quán)不同團(tuán)隊(duì)分別處理應(yīng)用的不同部分，決策是“去中心化”的。
“去中心化”的決策帶來了兩個(gè)關(guān)鍵結(jié)果。首先，軟件團(tuán)隊(duì)可以在架構(gòu)、發(fā)布、測(cè)試等方面作出“本地化”的***決策，不需要依賴全局標(biāo)準(zhǔn)。舉個(gè)例子，每個(gè)團(tuán)隊(duì)都有自己的發(fā)布工具，而不是單一的標(biāo)準(zhǔn)化應(yīng)用發(fā)布。第二，團(tuán)隊(duì)可以更快進(jìn)行決策，傳統(tǒng)模式下韻味、架構(gòu)等等集中功能之上的阻礙減少了。
微服務(wù)架構(gòu)不是“免費(fèi)”的——帶來了新的失敗模式
采用微服務(wù)對(duì)您的組織、流程和體系結(jié)構(gòu)具有深遠(yuǎn)的影響。微服務(wù)架構(gòu)本身是一個(gè)分布式系統(tǒng)，在基于微服務(wù)架構(gòu)的應(yīng)用中，業(yè)務(wù)邏輯分布在通過網(wǎng)絡(luò)相互通信的多個(gè)服務(wù)之間，而分布式系統(tǒng)有更多的故障模式(failure mode)。
考慮到這些失敗模式，有一個(gè)體系結(jié)構(gòu)和過程來防止小的失敗變成大的失敗是非常重要的。當(dāng)我們很“快”的時(shí)候，失敗是不可避免的，例如服務(wù)更新時(shí)引入了錯(cuò)誤，服務(wù)在負(fù)載下崩潰等等。
隨著應(yīng)用變得越來越復(fù)雜，對(duì)于失敗管理的需求也越來越迫切。當(dāng)應(yīng)用由少量微服務(wù)組城市，故障還比較容易隔離和排除，但想象數(shù)十個(gè)、上百個(gè)微服務(wù)，以及分布在各地的團(tuán)隊(duì)，我們的失敗管理體系需要與應(yīng)用一起“伸縮”。
管理失敗
我們一般會(huì)采取三種失敗管理策略：主動(dòng)測(cè)試(proactive testing)、緩解(mitigation)、快速想用(rapid response)。
- 主動(dòng)測(cè)試：利用流程和系統(tǒng)來測(cè)試應(yīng)用或服務(wù)，以便盡早發(fā)現(xiàn)故障。QA通常包含在這一方法中，雖然傳統(tǒng)測(cè)試團(tuán)隊(duì)專注于預(yù)發(fā)布測(cè)試，但現(xiàn)在經(jīng)常擴(kuò)展到生產(chǎn)測(cè)試。
- 緩解：實(shí)施特定策略以便在特定故障發(fā)生時(shí)減少影響和損失。例如，取保服務(wù)多個(gè)實(shí)例間的負(fù)載均衡，當(dāng)單個(gè)實(shí)例失敗，整個(gè)服務(wù)仍然可以相應(yīng)
- 快速反應(yīng)：通過流程和系統(tǒng)快速識(shí)別和處理特定故障
Service mesh
當(dāng)服務(wù)失敗時(shí)，會(huì)對(duì)其上游和下游服務(wù)產(chǎn)生影響。通過正確管理服務(wù)之間的通信，可以極大地減輕失敗服務(wù)的影響。這就是Service Mesh的用武之地。
Service Mesh管理服務(wù)級(jí)別(例如7層代理)通信，提供了強(qiáng)大的原語，可用于所有三種失敗管理策略：
動(dòng)態(tài)路由，可用于不同的發(fā)布和測(cè)試策略，如金絲雀路由、流量陰影或藍(lán)綠部署
彈性，通過諸如斷路和速率限制等策略來減輕故障的影響
可觀察性，通過收集度量標(biāo)準(zhǔn)，為服務(wù)間通信添加context(例如跟蹤數(shù)據(jù))來提高響應(yīng)時(shí)間
Service Mesh以一種對(duì)應(yīng)用開發(fā)人員非常透明的方式添加這些特性。
Service Mesh可以幫助我們更快構(gòu)建應(yīng)用嗎?
決定Service Mesh對(duì)于我們的企業(yè)是否有益，首先要思考兩個(gè)關(guān)鍵問題：
- 服務(wù)拓?fù)浣Y(jié)構(gòu)有多復(fù)雜?
- 如何將Service Mesh集成到軟件開發(fā)生命周期中?
服務(wù)拓?fù)?/strong>
如果只是單個(gè)微服務(wù)，Service Mesh的好處是有限的。增量版本也可以通過現(xiàn)有的基礎(chǔ)設(shè)施(如Kubernetes或API網(wǎng)關(guān))來完成。
然而隨著服務(wù)拓?fù)浣Y(jié)構(gòu)越來越復(fù)雜，Service Mesh將發(fā)揮巨大威力。需要考慮的關(guān)鍵約束是服務(wù)調(diào)用鏈的深度。如果您有一個(gè)淺層的拓?fù)浣Y(jié)構(gòu)，您的monolith直接調(diào)用了十幾種微服務(wù)，那么Service Mesh的好處仍然是有限的。當(dāng)您引入更多的服務(wù)到服務(wù)的通信時(shí)，服務(wù)A調(diào)用服務(wù)B調(diào)用服務(wù)C，Service Mesh就變得十分重要了。
將您的服務(wù)網(wǎng)格集成到您的SDLC中
Service Mesh對(duì)于服務(wù)是同名的，它是一個(gè)豐富的7層網(wǎng)絡(luò)，微服務(wù)不需要任何的代碼修改。
然而部署Service Mesh并不會(huì)自動(dòng)加速應(yīng)用的速率和敏捷性。我們需要將Service Mesh集成到開發(fā)過程中。
將實(shí)現(xiàn)故障管理策略作為SDLC的一部分
Service Mesh為故障管理提供了強(qiáng)大的原語，接下來我們將討論各個(gè)失敗管理策略以及如何應(yīng)用到SDLC中。
主動(dòng)測(cè)試
微服務(wù)應(yīng)用的測(cè)試策略應(yīng)該盡可能貼近真實(shí)情況?？紤]到多服務(wù)應(yīng)用的復(fù)雜性，當(dāng)前的測(cè)試策略強(qiáng)調(diào)在生產(chǎn)中進(jìn)行測(cè)試(或使用生產(chǎn)數(shù)據(jù))。
Service Mesh通過控制L7傳輸?shù)椒?wù)的流量來在生產(chǎn)環(huán)境中進(jìn)行測(cè)試。例如，服務(wù)網(wǎng)格可以將1%的流量路由到服務(wù)的v1.1版本, 99%的流量路由到v1.0(金絲雀部署)。這些功能通過聲明式路由規(guī)則(例如linkerd dtab或Istio路由規(guī)則)公開。
Service Mesh不是主動(dòng)測(cè)試的唯一方法。其他補(bǔ)充策略包括使用容器調(diào)度器(如Kubernetes)進(jìn)行滾動(dòng)更新、可以進(jìn)行金絲雀部署的API網(wǎng)關(guān)或chaos engineering。
有了所有這些策略，誰管理測(cè)試工作流的問題就變得很明顯了。在Service Mesh中，路由規(guī)則可以由管理網(wǎng)格的同一團(tuán)隊(duì)集中管理。
緩解
由于各種原因，服務(wù)可能會(huì)失?。捍a錯(cuò)誤、資源不足、硬件故障。限制失敗服務(wù)的爆炸半徑對(duì)于整個(gè)應(yīng)用程序繼續(xù)運(yùn)行(盡管處于降級(jí)狀態(tài))非常重要。
Service Mesh通過負(fù)載平衡、斷路器和服務(wù)到服務(wù)通信的速率限制等彈性模式來減輕故障的影響。例如在重載下的服務(wù)可以限制速率，以便仍然處理某些響應(yīng)，而不會(huì)導(dǎo)致整個(gè)服務(wù)在負(fù)載下崩潰。
減輕失敗的其他策略包括使用智能RPC庫(kù)(例如Hystrix)或依賴容器調(diào)度程序。像Kubernetes這樣的容器調(diào)度器支持健康檢查、自動(dòng)擴(kuò)展和對(duì)不響應(yīng)健康檢查的服務(wù)的動(dòng)態(tài)路由。
當(dāng)為給定的服務(wù)適當(dāng)?shù)嘏渲眠@些緩解策略時(shí)，它們是最有效的。例如，不同的服務(wù)可以處理不同數(shù)量的請(qǐng)求，需要不同的速率限制。如何制定利率限制等政策?Netflix已經(jīng)實(shí)現(xiàn)了一些自動(dòng)配置算法來設(shè)置這些值。其他方法是將這些功能公開給服務(wù)作者，他們可以正確配置服務(wù)。
可觀察性
失敗是不可避免的。實(shí)現(xiàn)可觀察性——跨越監(jiān)控、警報(bào)/可視化、分布式跟蹤和日志記錄——對(duì)于將響應(yīng)時(shí)間最小化到給定的故障是非常重要的。
Service Mesh自動(dòng)收集關(guān)于服務(wù)到服務(wù)通信的詳細(xì)指標(biāo)，包括吞吐量、延遲和可用性的數(shù)據(jù)。此外，服務(wù)網(wǎng)格可以注入必要的headers來支持分布式跟蹤。注意，這些headers仍然需要由服務(wù)本身傳播。
收集類似度量的其他方法包括使用監(jiān)視代理、通過statsd收集度量以及通過庫(kù)實(shí)現(xiàn)跟蹤(例如，Jaeger工具庫(kù))。
可觀察性的一個(gè)重要組成部分是向服務(wù)作者公開警報(bào)和可視化。收集度量只是***步，考慮您的服務(wù)作者如何創(chuàng)建適合于給定服務(wù)的警報(bào)和可視化對(duì)于關(guān)閉可觀察性循環(huán)非常重要。
