服務(wù)網(wǎng)格技術(shù)淺析

作者：張征峰

隨著互聯(lián)網(wǎng)產(chǎn)業(yè)的飛速發(fā)展，技術(shù)架構(gòu)需要通過不斷更新迭代以適應(yīng)越來越復(fù)雜的業(yè)務(wù)需求。在過去的幾十年中，服務(wù)從單體應(yīng)用程序到SOA架構(gòu)再到微服務(wù)架構(gòu)，比如大家都熟悉的Spring Cloud。雖然微服務(wù)架構(gòu)將服務(wù)按業(yè)務(wù)拆分較小的應(yīng)用，有利于復(fù)雜的大型項目的構(gòu)建，但是服務(wù)間的復(fù)雜的通信和治理漸漸成為新的難題。為此而產(chǎn)生了服務(wù)網(wǎng)格（Service Mesh）技術(shù)，本文將對其架構(gòu)思想和最主流的實現(xiàn)方案Istio做一個簡單的介紹。

Part 01●??要解決的問題?●

微服務(wù)自在2012年提出的概念以來，出現(xiàn)了Spring Could、Dubbo，Spring Cloud Alibaba等成熟穩(wěn)定的實現(xiàn)方案，并在實際生產(chǎn)中受到廣泛應(yīng)用。其根本思想是通過拆分原則，希望一個服務(wù)只負(fù)責(zé)業(yè)務(wù)中一個獨立的功能，這樣任何一個需求不會因為發(fā)布或者維護(hù)而影響到不相關(guān)的服務(wù)，然而隨著業(yè)務(wù)越來越大，拆分的服務(wù)實例越來越多，各個服務(wù)之間的依賴調(diào)用就變成了非常復(fù)雜的網(wǎng)絡(luò)拓?fù)?/a>結(jié)構(gòu)，類似于圖1所示，就會面臨著以下問題。

對于稍具規(guī)模的團(tuán)隊，多語言的技術(shù)棧和跨語言調(diào)用是常態(tài)，然而目前開源社區(qū)上并沒有一套統(tǒng)一的跨語言的微服務(wù)技術(shù)[1]，那些沒有框架支持的語言編寫的服務(wù)很難融入面向微服務(wù)的已有架構(gòu)體系中，想因地制宜的用多種語言實現(xiàn)架構(gòu)體系中的不同模塊在現(xiàn)實開發(fā)中很難做到。

? 代碼侵入性強(qiáng)?

主流的微服務(wù)實現(xiàn)框架或多或少都對業(yè)務(wù)代碼有一定的侵入性，比如Spring Cloud框架中幾乎每個微服務(wù)都需要集成Eureka、Feign等組件,這些組件框架替換成本高，復(fù)雜項目依賴時的庫版本兼容問題也非常棘手，同時，框架庫的升級也無法對服務(wù)透明，服務(wù)會因為和業(yè)務(wù)無關(guān)的依賴庫升級而被迫升級，我們希望的是盡量將負(fù)責(zé)服務(wù)間通信的這種非業(yè)務(wù)代碼從業(yè)務(wù)功能代碼中剝離出來。

Part 02●??Service Mesh架構(gòu)思想?●

為解決上述微服務(wù)存在的問題，Service Mesh（服務(wù)網(wǎng)格）應(yīng)運而生，它主要作為處理服務(wù)間通信的基礎(chǔ)設(shè)施層，獨立于具體的服務(wù)而存在，目的是從根本上解決了多語言支持不足以及代碼侵入性的問題，并且憑借服務(wù)網(wǎng)格的獨立性，使得業(yè)務(wù)團(tuán)隊不再需要關(guān)心復(fù)雜的服務(wù)治理工作，可以全權(quán)交給服務(wù)網(wǎng)格處理。

核心思想

服務(wù)網(wǎng)格的核心思想為Sidecar模式（邊車模式），即將每個服務(wù)的負(fù)載、限流和服務(wù)發(fā)現(xiàn)等等通信功能和應(yīng)用業(yè)務(wù)本身功能進(jìn)行解耦分離，其負(fù)責(zé)服務(wù)間通信的部分稱之為Sidecar代理，業(yè)務(wù)功能代碼只和同機(jī)器下的不同進(jìn)程的代理通信。如圖2所示。

名稱由來

由于每一個服務(wù)實例都會有一個Sidecar代理與之配對，服務(wù)之間的通信都是通Sidecar進(jìn)行，在部署圖表示為代理的交叉連接形成了一種網(wǎng)絡(luò)網(wǎng)格，故稱之為“服務(wù)網(wǎng)格”。目前所說的Service Mesh在若干服務(wù)的Sidercar代理基礎(chǔ)上提供了統(tǒng)一集中式管理的運維入口即控制面平面， SideCar代理也稱為數(shù)據(jù)平面 ，因此我們通常說Service Mesh由數(shù)據(jù)平臺和控制平面組成，其結(jié)構(gòu)如圖3所示。

Part 03●??Istio簡介?●

- Istio是什么？

Service Mesh(服務(wù)網(wǎng)格）只是一種架構(gòu)思想，主流的實現(xiàn)方案有Istio、Linkerd、Linkerd2、Consoul等等。其中Istio是目前最受歡迎且在實際生產(chǎn)中應(yīng)用最為廣泛的服務(wù)網(wǎng)格，它是由Google，IBM和Lyft這三家互聯(lián)網(wǎng)巨頭聯(lián)合開發(fā)的一個基于服務(wù)網(wǎng)格的開源項目，功能豐富，成熟度高。下面將簡單介紹Istio的框架及功能。

- Istio架構(gòu)

Istio架構(gòu)如下圖所示，在邏輯上與Service Mesh框架思想保持一致，分為數(shù)據(jù)平面和控制平面兩大部分，整體架構(gòu)如圖4所示。

①數(shù)據(jù)平面

數(shù)據(jù)平面由一組以Sidecar方式部署的Envoy代理組成，所有進(jìn)入和流出服務(wù)的流量都會被Envoy攔截，并與控制平面進(jìn)行交互，根據(jù)配置執(zhí)行相應(yīng)的通信功能。

Envoy是用C++開發(fā)的高性能代理，Envoy代理作為唯一與數(shù)據(jù)平面流量交互的 Istio組件，相對于其他服務(wù)網(wǎng)格實現(xiàn)方案代理來說有著更豐富的治理能力和靈活的配置方式，并且支持各種插件可用于擴(kuò)展流量治理能力，可生成遙測數(shù)據(jù)[2]。

Envoy和Istio并不是強(qiáng)綁定關(guān)系，Envoy可以在其他框架中使用，Istio也可以采用其他代理。Envoy本身的內(nèi)置功能有：負(fù)載均衡、TLS 終止、動態(tài)服務(wù)發(fā)現(xiàn)、HTTP/2&gRPC 代理，熔斷器，健康檢查，基于百分比流量拆分的分段推出，故障注入等。Envoy允許在不需要重新設(shè)計架構(gòu)或重寫代碼條件下，啟用或執(zhí)行的一些Istio的功能和任務(wù)，比如：流量控制功能、網(wǎng)絡(luò)彈性特性、安全性和身份認(rèn)證特性基于WebAssembly的可插拔擴(kuò)展模型等。

②控制平面

Istio的控制平面提供服務(wù)發(fā)現(xiàn)、配置和證書管理。由Pilot、Citadel、Galley三個組件整合成了一個單進(jìn)程、多模塊的istiod，極大的降低了部署的復(fù)雜度。在整個運行流程中，需要這些組件協(xié)同工作。

Pilot組件是控制面最重要的組件，負(fù)責(zé)提供服務(wù)發(fā)現(xiàn)、流量路由及服務(wù)治理功能，其架構(gòu)如圖5所示。

服務(wù)發(fā)現(xiàn)：Pilot通過插件的形式可以支持多種服務(wù)注冊平臺（K8s、Mesos等），通過平臺適配器（Platform Adapter）將服務(wù)注冊平臺的服務(wù)數(shù)據(jù)填充為標(biāo)準(zhǔn)服務(wù)模型（Abstract Model），例如Pilot通過K8s適配器，將K8s中的Service及Pod實例等服務(wù)信息，轉(zhuǎn)換為標(biāo)準(zhǔn)模型供Pilot使用。Pilot在得到統(tǒng)一的服務(wù)信息后，將服務(wù)信息通過Envoy API下發(fā)到數(shù)據(jù)面Envoy代理，實現(xiàn)服務(wù)發(fā)現(xiàn)功能[3]。

流量路由及服務(wù)治理：運維人員可以通過Rules API指定各種高級流量管理規(guī)則（Gateway、VirtualService等），這些規(guī)則將被轉(zhuǎn)換為數(shù)據(jù)面Envoy可以識別的格式，通過Envoy API下發(fā)給Envoy，Envoy在得到這些規(guī)則后，按照規(guī)則進(jìn)行流量轉(zhuǎn)發(fā)及安全認(rèn)證[3]。

Gally是負(fù)責(zé)配置的驗證和處理的組件，從底層平臺獲取配置，驗證配置信息的格式和內(nèi)容的正確性，并將這些配置信息提供給Pilot使用。

Citadel 是與安全相關(guān)的組件，主要負(fù)責(zé)密鑰和證書的管理，可以實現(xiàn)強(qiáng)大的授權(quán)和認(rèn)證等功能。

Part 04●??總結(jié)?●

本文從傳統(tǒng)微服務(wù)在具體實施中存在的問題出發(fā)，簡述了為解決這些問題而產(chǎn)生的服務(wù)網(wǎng)格架構(gòu)思想，最后對這種架構(gòu)思想一種最受歡迎的實現(xiàn)方案Istio和核心組件進(jìn)行了的簡單介紹。但是任何一種方案都很難做到一勞永逸，Istio只是把原來分散在應(yīng)用內(nèi)部的復(fù)雜性統(tǒng)一抽象出來放到了統(tǒng)一的地方，且Istio的架構(gòu)相對復(fù)雜，在具體生產(chǎn)中，必須做好清楚的規(guī)劃，權(quán)衡它帶來的好處是否遠(yuǎn)大于額外維護(hù)它的花費，選擇合適的架構(gòu)方案。

參考文獻(xiàn)

[1] 陶志,向忠清.微服務(wù)架構(gòu)Service Mesh的設(shè)計與應(yīng)用[J].計算機(jī)應(yīng)用，2020，39（1）:39-53.

[2]Istio官網(wǎng)資料[EB/OL].[2023-04-19].https://istio.io/latest/about/service-mesh/.

[3]淺析Istio系列[EB/OL].[2023-04-20]https://zhuanlan.zhihu.com/p/504313570.