1.5 服務網(wǎng)格（Serüice Mesh）新時期

1.5.1 多語言的困難

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

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

1.5.2 指數(shù)級增加的系統(tǒng)復雜度

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

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

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

1.5.3 Linkerd誕生

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

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

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

1.5.4 第一代服務網(wǎng)格架構(gòu)

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

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

這里有幾個關(guān)鍵點，要強調(diào)一下。

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

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

○可靠：由于其組成的網(wǎng)格為上層服務提供一層統(tǒng)一的代理，其作為基礎(chǔ)設(shè)施需要高度可靠，否則上層業(yè)務會非常頭痛。

○網(wǎng)絡(luò)代理：其是對所有服務設(shè)計的一層透明代理，可以跨言語。

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

從上可以看出，第一代架構(gòu)是從數(shù)據(jù)邏輯層面上解決了微服務關(guān)系混亂的問題，但它并沒有實現(xiàn)控制。Sidecar將各服務連接了起來，并做到請求接管，但是沒有一個有效的系統(tǒng)或者設(shè)計來管理這些Sidecar的配置。

1.5.5 第二代服務網(wǎng)格架構(gòu)

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

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

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

1.5.6 生產(chǎn)應用情況

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

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

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

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

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

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

可以說現(xiàn)在Istio已經(jīng)獨領(lǐng)風騷，在服務網(wǎng)格這個領(lǐng)域確立了堅實的根基，特別是其在2018年8月發(fā)布1.0正式版本之后，基本上就已成為唯一一個可以實際用于生產(chǎn)環(huán)境的開源框架。

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