在《沉寂多年，無服務器爆發，其硬核是什麼？》一文中，我們就什麼是無服務器技術，它是如何發展的，它的優點、缺點是什麼，對企業的價值在哪裏進行了梳理。本文講講Service Mesh。在架構領域，Service Mesh和Serverless一樣，是非常重要的一個方向。
這麼說吧，掌握了Service Mesh，你就選擇了一條未來技術框架的道路。至於這條道路會怎麼發展，還要再觀察。這篇文章將解釋什麼是Service Mesh，爲什麼需要Service Mesh，以及Service Mesh的現狀如何。
初識Service Mesh
Service Mesh很新，最早在2016年9月29日由開發Linkerd的Buoyant公司提出。
時間回到2016年10月，Alex Leong開始在Buoyant公司的官方博客中連載一系列關於“A Service Mesh for Kubernetes”的文章。
隨着2017年Linkerd加入CNCF，Service Mesh開始大規模出現在各個技術論壇上，Service Mesh在國內被翻譯爲“服務網格” 。
那麼到底什麼是Service Mesh呢？目前比較公認的定義是Buoyant的CEO William Morgan在博客中給出的具體描述，如下：
現在，Service Mesh逐步發展爲一個獨立的基礎設施層。在Cloud Native架構下，單個應用程序可能由數百個服務組成；每個服務可能有數千個實例；並且這些實例中的每一個實例都可能處於不斷變化的狀態，因爲它們是由諸如Kubernetes之類的資源調度系統動態調度的。這個世界中的服務通信不僅非常複雜，而且是運行時的普遍行爲之一，管理它對於確保端到端的性能和可靠性至關重要。
Sidecar的比喻從何而來？
業內也有類似“Sidecar”的說法。這個概念很形象，就是我們以前在戰爭影片中看到的那種挎斗車。
這種模式被命名爲Sidecar，因爲它類似於連接到摩托車的輔助車。在該模式中，輔助車被附加到父應用程序併爲應用程序提供支持功能。輔助車也與父應用程序共享相同的生命週期，與父進程一起被創建和推出。
解釋了這麼多，一句話來說的話，那就是：Service Mesh幫助應用程序在海量服務、複雜的架構和網絡中建立穩定的通信機制，業務所有的流量都轉發到Service Mesh的代理服務中。
不僅如此，Service Mesh還承擔了微服務框架所有的功能，包括服務註冊發現、負載均衡、熔斷限流、認證鑑權、緩存加速等。不同的是，Service Mesh強調的是通過獨立的進程代理的方式，除此之外，還承擔了上報日誌、監控的責任。Service Mesh架構如下。
輕量、自治促進不斷髮展
Service Mesh的出現是由微服務架構推動的，隨着一個應用被拆分爲幾百個甚至幾萬個應用，服務治理面臨巨大的挑戰。這個時候，微服務框架出現，例如，Finagle、Dubbo、SpringCloud、Netflix OSS等。這些框架都是基於客戶端負載均衡直連的方式，此方案的優勢是性能高、應用性好，如Spring Cloud。
歸根結底，在微服務架構中，我們要解決的問題是，讓開發人員感覺不到微服務之間的通信。當服務數量越來越多，升級微服務框架變得越來越複雜的時候，你不可能要求微服務框架一直不變，而且是沒有bug的。在技術更新如此之快的年代，就更不可能了。
因此，微服務框架的部分功能開始逐步向服務端移動，希望客戶端可以儘量“薄”，但是客戶端不可能無限制的“薄”，剩餘部分仍然比較“厚”。
因爲使用客戶端更像一種交付的模式，不容易變更，控制力較差，而Service Mesh則從業務進程集成客戶端的方式演進爲獨立進程的方式，也就是說，原本的客戶端變成了一個獨立進程。對這個獨立進程升級、運維要比綁在一起強得多。
微服務架構更強調去中心化、獨立自治、跨語言，但是通常微服務框架限制了這一點，不可能爲每種語言都實現一種框架，要麼都用一種語言，要麼實現多種語言的框架。而Service Mesh通過獨立進程的方式進行了隔離，可以低成本實現跨語言。
隨着Docker及Kubernetes的崛起，微服務的部署模式開始發生轉變，越來越趨向於輕量級，越來越強調隔離自治。每個服務獨立佔用一個容器，將服務、依賴包、操作系統、監控運維所需的代理打包成一個鏡像。這種模式促成了Service Mesh的發展，讓Service Mesh實現起來更容易。否則開發人員需要額外維護Service Mesh進程，就非常麻煩了。
主流框架的弊病和優勢
目前Service Mesh的框架如雨後春筍般快速涌現，以下幾個框架是目前爲止被提到次數最多的。
先驅者如Linkerd，被譽爲業界第一個Service Mesh項目，但由於很多功能被後續框架所取代，發展有限。現在最流行的是Envoy，它在性能和資源消耗上表現得非常出色，被Istio收編之後， 專注於數據平面。最值得注意的是Istio，因爲它的背後是Google和IBM。從0.3版本開始支持非Kubernetes平臺，並可以獨立運行。
當然業內還有其他一些框架，由於暫時沒有投入到生產環境，進展有限，可以關注一下，比如Conduit 、nginMesh等。
就拿Istio來說，雖然它的架構思想被很多人認同，功能也很多，但是Istio的問題仍然較多，可用性較差，幾乎沒有生產級的案例。有點像當初Kubernetes剛剛研發出來的感覺，也許隨着技術的不斷髮展會成爲Service Mesh的未來，畢竟當前很多公司都在跟隨這個框架。
先謹慎觀察 未來可期
實際上，如果在一個小公司，Service Mesh的優勢並不是十分明顯。例如小公司很少會考慮採用多語言，因爲多一種語言就意味着要花費額外的精力進行維護，所以到目前爲止，大多數公司在後端只使用一兩種語言。
另外，微服務框架相對來說比較穩定，就如同Spring Framework一樣，不會輕易進行不兼容的升級，只要保持好節奏，問題不會太多。因此，像Netflix這樣的公司，基本上還是沿用類似Spring Cloud模式的。
Service Mesh對業務開發人員友好，但是基礎設施層的研發會更復雜，需要依賴更多的服務、組件，否則將帶來極大的架構、運維複雜度。對於很多公司來說，門檻稍高，且需要投入成本。
百度內部業務也很早就開始了基於Service Mesh思想的微服務實踐，並自研了BMesh框架，大大降低了Service Mesh的實施和維護成本，並解決其自身的性能問題。基於這些內部實踐，百度智能雲CNAP產品目前已經邀測推出了非侵入式微服務解決方案，爲客戶提供可商用的基於Service Mesh的微服務監控、追蹤和治理平臺。目前來看，在沒有成熟起來以前，Service Mesh並不具備壓倒性的優勢。但未來隨着微服務的進一步快速普及，Service Mesh作爲重要的架構演進方向值得關注。
本文參考資料
百度智能雲官網：
https://cloud.baidu.com/product/cnap.html
CNCF官網：
《雲原生基礎架構》，機械工業出版社，2018年9月第一版
《持續演進的Cloud Native 雲原生架構下微服務最佳實踐》，電子工業出版社，2018年10月第一版
本文轉載自公衆號AIOps智能運維（ID：AI_Ops）。
原文鏈接：