1.5 服務網格（Serüice Mesh）新時期

1.5.1 多語言的困難

分布式關系日益復雜還不僅體現在調用關系上，隨著多語言、前后端分離等思想的發展，在架構中呈現編程語言多元化的趨勢，例如NodeJS、Golang（近期非常熱的配置中心etcd就是用其編寫的）、Scala（大名鼎鼎的Kafka就是用其編寫的）等。

本來僅維護調用關系就已經讓工程師們焦頭爛額了，現在還需要對多語言進行支持（熟練掌握一門語言及其生態還是需要一些時間的），并且不同的語言還有不同的編程風格，所以多語言支持真的不容易。再者，由于多語言客戶需要侵入上層業務代碼，開發人員就不得不在學習（至少了解）整個服務架構后，才能較正確地做出是否能夠接入那些客戶端的判斷。

1.5.2 指數級增加的系統復雜度

業務需求不斷升級會導致系統復雜度呈指數級增長，工程師們經常遇到這樣的現象：同一段時間內，一個產品可能有好幾個需求在并行開發，而開發環境卻有限；某些應用包含敏感數據，并不希望將接口完全公開；隔三岔五的產品活動，對系統穩定性有很高的要求，測試希望能將壓測常態化，最好還不影響線上應用。整體系統復雜度并不像最初預估的那樣呈線性增長，其往往呈指數級增長。這一點，從圖1.9中每年雙十一的銷售額就可以看出來。

所以這時“多版本、多權限、動態限流降級”等一系列針對鏈路的高級功能需求被陸續提了出來。為了滿足上述要求，工程師們不得不編寫更多的系統，有針對“分布式鎖”的，有針對“分布式鑒權”的，有針對“多版本”的，等等。這使得分布式系統本身愈加復雜與笨重。事實上，僅搭建與維護一套分布式架構至少都需要一個專業的團隊支持（通常這個團隊叫“平臺架構”或者“中間件”團隊），每個產品至少需要半個專業的工程師來維護，理解這些概念對于非專業的業務工程師來說負擔可就更重了。

“微服務”雖然強調輕量化框架，但仍然無法避免系統愈加繁多的問題，服務細化得越厲害，只能讓邏輯越輕量并解耦；但服務分得越細，數量就越多，維護成本自然就越高，這并不能解決維護成本問題。

1.5.3 Linkerd誕生

到了2015年，一家名為Buoyant的公司向外界公布了一種架構空前的產品，其為每個服務分配了一個專用的稱為“邊車網關（Sidecar）”的系統，并將其與“服務發現”的公共服務相連，服務地址及控制信息便通過“服務治理系統”統一下發，其系統概念如圖1.10所示：

如此一來，隨著接入應用的添加，網關之間便形成了一個特殊的大網（如圖1.11所示），其承載著鏈路請求的路由、治理及其他任何與鏈路相關的工作。由于網關獨立于業務應用而存在，因此其與業務邏輯是完全解耦的，并且開發人員是無感知的。Linkerd巧妙地向上層應用統一屏蔽了分布式架構，讓業務開發變得更簡單、純粹了。

可是Linkerd在2015年推出后并沒有受到業界的關注，主要原因是Linkerd為每個服務部署一個網關的想法在傳統運維體系中實在是太難實現了——部署、維護工作幾乎多了一倍。

1.5.4 第一代服務網格架構

但是到了2017年，隨著“微服務”與“容器化”技術的迅速發展，以上問題就非常簡單了，只需要將網關程序打包到基礎鏡像（Image）即可解決。隨后Linkerd的想法迅速走紅，受到越來越多工程師的青睞。不久后William Morgan（Buoyant co-founder and CEO）在Linkerd官方博客上撰寫了一篇名為What's a service mesh?And why do I need one的文章，將Linkerd的構想定義為“服務網格（Service Mesh）”，并做了比較嚴謹的定義。

Service Mesh是一個“基礎設施”層，用于處理服務間通信。云原生應用有著復雜的服務拓撲，Service Mesh保證請求可以在這些“拓撲”中“可靠”地穿梭。在實際應用當中，Service Mesh通常是由一系列輕量級的“網絡代理”組成的，它們與應用程序部署在一起，但應用程序“不需要知道”它們的存在。

這里有幾個關鍵點，要強調一下。

○基礎設施：Service Mesh是未來云計算中不可或缺的基礎框架，就像TPC/IP協議棧一樣，雖然開發人員不需要感知，但其中服務路由與治理的基礎，為云計算提供服務通道與保障。

○拓撲：Service Mesh所提供的網關組成一個龐大的網格，由此網格統一為應用提供服務，其是對物理網的一層分布式抽象。

○可靠：由于其組成的網格為上層服務提供一層統一的代理，其作為基礎設施需要高度可靠，否則上層業務會非常頭痛。

○網絡代理：其是對所有服務設計的一層透明代理，可以跨言語。

○不需要知道：其是一層服務棧，擁有對上層支撐的全套功能且對業務無侵入，在層次上定義了其存在位置。

從上可以看出，第一代架構是從數據邏輯層面上解決了微服務關系混亂的問題，但它并沒有實現控制。Sidecar將各服務連接了起來，并做到請求接管，但是沒有一個有效的系統或者設計來管理這些Sidecar的配置。

1.5.5 第二代服務網格架構

這之后Linkerd被Google收編到了CNCF基金中，現在已經作為一個開源軟件在發展，但是由于其是使用Scala編寫的，在性能上表現不佳（Scala需要JVM作為運行環境，通常在啟動的時候就至少占200MB內存），再加上后來Google為了推進Kubernetes在云上的發展，自己另起爐灶發布了Istio，使用的網關是Envoy, Linkerd可以說前途昏暗。

也許是Buoyant自己也感覺到把Linkerd交給社區之后使其思考及發展都受到了嚴格的限制（在社區由于需要公共參與，每個決定都需要經過較長的時間）,2017年又用Rust研發了Conduit。Conduit號稱是一個非常輕量級的Service Mesh方案，不過由于Rust是一種非常小眾的語言，再加上這個時候Google的Istio勢如破竹般地發展，Conduit現在在業界的接受度也是非常低的，更不要談大規模實際生產了。

第二代服務網格典型的特點便是同時擁有了數據接管與集中控制能力，Google分別將兩個能力對應的系統定義為“數據平面（Data Plane）”及“控制平面（Control Plane）”。

1.5.6 生產應用情況

由于Istio是Google巨人主導的，很有說服力，所以各大廠商愿意跟進研究并投入試用，本書中所講解的Service Mesh大部分內容也都基于Istio。其實除了國外研發的開源產品，國內很多團隊也已經在著手研究了，這些團隊主要分為四類體系。

○以螞蟻金服為首的開源系：螞蟻金服自研的SOFA（Scalable Open Financial Architecture）Mesh在開始的時候走的就是開源路線，他們參考了Istio及Envoy的設計思想，重新實現了自己的Service Mesh系統，旁路網關（Sidecar）基于Go語言，該系統的前身是已經開源的SOFA RPC框架。螞蟻金服于2018年7月正式將其開源，正式的可以用于生產的框架可能還需要一些時間。

○以華為為代表的自研系：華為可能在Service Mesh概念出來前就已經有類似的想法了，只是沒有抽取出一個公共的概念。無論是華為早期的HSA還是之后出現的CSE Mesher，都是對Service Mesh的探索。CSE Mesher的整個架構都是基于華為自身微服務架構經驗研發的，其Sidecar也是用Go語言編寫的。如其官方文檔所述，其資源占用非常小，常規狀態下僅為30MB。

○以騰訊為代表的拿來主義系：騰訊的Tencent Service Mesh對開源的產品（如Istio）進行定制，強化吸收后再加入自身特殊的業務邏輯。騰訊選擇的Sidecar是Envoy，使用C++編寫，比較符合騰訊的技術棧。其公開的技術并不多，仍然以內部小范圍使用為主。

○以UCloud為代表的適配系：主要也是依賴開源方案，但不是完全將其產品引入，只是對其中幾個關鍵部分添加適配器，以適應企業現有產品，以最小的變更成本引入Service Mesh體系。

能夠看出，服務網格概念雖然火，但并不是像Spring Cloud及Dubbo那樣經過實戰考驗的、成熟的框架——企業要想擁抱服務網格，通常情況下只能自行研發或改造。雖然Google已經在試圖通過Istio來為業界設立一個通用標準，但從現狀來看，還有比較長遠的路要走。

可以說現在Istio已經獨領風騷，在服務網格這個領域確立了堅實的根基，特別是其在2018年8月發布1.0正式版本之后，基本上就已成為唯一一個可以實際用于生產環境的開源框架。

服務網格是一個全新的概念，各大公司在爭相研究與實踐，我相信服務網格將來必然是云服務的重要根基之一。