芯耀
1083
作者：張征峰
隨著互聯(lián)網產業(yè)的飛速發(fā)展，技術架構需要通過不斷更新迭代以適應越來越復雜的業(yè)務需求。在過去的幾十年中，服務從單體應用程序到SOA架構再到微服務架構，比如大家都熟悉的Spring Cloud。雖然微服務架構將服務按業(yè)務拆分較小的應用，有利于復雜的大型項目的構建，但是服務間的復雜的通信和治理漸漸成為新的難題。為此而產生了服務網格（Service Mesh）技術，本文將對其架構思想和最主流的實現(xiàn)方案Istio做一個簡單的介紹。
Part 01●??要解決的問題?●
微服務自在2012年提出的概念以來，出現(xiàn)了Spring Could、Dubbo，Spring Cloud Alibaba等成熟穩(wěn)定的實現(xiàn)方案，并在實際生產中受到廣泛應用。其根本思想是通過拆分原則，希望一個服務只負責業(yè)務中一個獨立的功能，這樣任何一個需求不會因為發(fā)布或者維護而影響到不相關的服務，然而隨著業(yè)務越來越大，拆分的服務實例越來越多，各個服務之間的依賴調用就變成了非常復雜的網絡拓撲結構，類似于圖1所示，就會面臨著以下問題。
? 治理難度大、技術門檻高
隨著微服務實施水平的不斷深化，除了基礎的服務發(fā)現(xiàn)，配置中心和授權管理之外，在實施的過程中不可避免的需要在服務治理層面面臨著各種新的挑戰(zhàn)如分布式跟蹤，熔斷降級，灰度發(fā)布，故障切換等等治理需求。這些眾多的非業(yè)務性需求，涉及到運維、運營管理層面，這使得整個項目在組織、分工、權責上變得交叉模糊，同時對相關人員提出了非常高的技術要求，然而我們開發(fā)的是業(yè)務程序，它的核心價值是業(yè)務邏輯的處理和實現(xiàn)，將越來越多的時間和精力花費在這些非業(yè)務功能上是非常不合理的。
? 多語言支持不足?
對于稍具規(guī)模的團隊，多語言的技術棧和跨語言調用是常態(tài)，然而目前開源社區(qū)上并沒有一套統(tǒng)一的跨語言的微服務技術[1]，那些沒有框架支持的語言編寫的服務很難融入面向微服務的已有架構體系中，想因地制宜的用多種語言實現(xiàn)架構體系中的不同模塊在現(xiàn)實開發(fā)中很難做到。
? 代碼侵入性強?
主流的微服務實現(xiàn)框架或多或少都對業(yè)務代碼有一定的侵入性，比如Spring Cloud框架中幾乎每個微服務都需要集成Eureka、Feign等組件,這些組件框架替換成本高，復雜項目依賴時的庫版本兼容問題也非常棘手，同時，框架庫的升級也無法對服務透明，服務會因為和業(yè)務無關的依賴庫升級而被迫升級，我們希望的是盡量將負責服務間通信的這種非業(yè)務代碼從業(yè)務功能代碼中剝離出來。
Part 02●??Service Mesh架構思想?●
為解決上述微服務存在的問題，Service Mesh（服務網格）應運而生，它主要作為處理服務間通信的基礎設施層，獨立于具體的服務而存在，目的是從根本上解決了多語言支持不足以及代碼侵入性的問題，并且憑借服務網格的獨立性，使得業(yè)務團隊不再需要關心復雜的服務治理工作，可以全權交給服務網格處理。
核心思想
服務網格的核心思想為Sidecar模式（邊車模式），即將每個服務的負載、限流和服務發(fā)現(xiàn)等等通信功能和應用業(yè)務本身功能進行解耦分離，其負責服務間通信的部分稱之為Sidecar代理，業(yè)務功能代碼只和同機器下的不同進程的代理通信。如圖2所示。
名稱由來
由于每一個服務實例都會有一個Sidecar代理與之配對，服務之間的通信都是通Sidecar進行，在部署圖表示為代理的交叉連接形成了一種網絡網格，故稱之為“服務網格”。目前所說的Service Mesh在若干服務的Sidercar代理基礎上提供了統(tǒng)一集中式管理的運維入口即控制面平面， SideCar代理也稱為數(shù)據(jù)平面 ，因此我們通常說Service Mesh由數(shù)據(jù)平臺和控制平面組成，其結構如圖3所示。
Part 03●??Istio簡介?●
- Istio是什么？
Service Mesh(服務網格）只是一種架構思想，主流的實現(xiàn)方案有Istio、Linkerd、Linkerd2、Consoul等等。其中Istio是目前最受歡迎且在實際生產中應用最為廣泛的服務網格，它是由Google，IBM和Lyft這三家互聯(lián)網巨頭聯(lián)合開發(fā)的一個基于服務網格的開源項目，功能豐富，成熟度高。下面將簡單介紹Istio的框架及功能。
- Istio架構
Istio架構如下圖所示，在邏輯上與Service Mesh框架思想保持一致，分為數(shù)據(jù)平面和控制平面兩大部分，整體架構如圖4所示。
①數(shù)據(jù)平面
數(shù)據(jù)平面由一組以Sidecar方式部署的Envoy代理組成，所有進入和流出服務的流量都會被Envoy攔截，并與控制平面進行交互，根據(jù)配置執(zhí)行相應的通信功能。
Envoy是用C++開發(fā)的高性能代理，Envoy代理作為唯一與數(shù)據(jù)平面流量交互的 Istio組件，相對于其他服務網格實現(xiàn)方案代理來說有著更豐富的治理能力和靈活的配置方式，并且支持各種插件可用于擴展流量治理能力，可生成遙測數(shù)據(jù)[2]。
Envoy和Istio并不是強綁定關系，Envoy可以在其他框架中使用，Istio也可以采用其他代理。Envoy本身的內置功能有：負載均衡、TLS 終止、動態(tài)服務發(fā)現(xiàn)、HTTP/2&gRPC 代理，熔斷器，健康檢查，基于百分比流量拆分的分段推出，故障注入等。Envoy允許在不需要重新設計架構或重寫代碼條件下，啟用或執(zhí)行的一些Istio的功能和任務，比如：流量控制功能、網絡彈性特性、安全性和身份認證特性基于WebAssembly的可插拔擴展模型等。
②控制平面
Istio的控制平面提供服務發(fā)現(xiàn)、配置和證書管理。由Pilot、Citadel、Galley三個組件整合成了一個單進程、多模塊的istiod，極大的降低了部署的復雜度。在整個運行流程中，需要這些組件協(xié)同工作。
Pilot組件是控制面最重要的組件，負責提供服務發(fā)現(xiàn)、流量路由及服務治理功能，其架構如圖5所示。
服務發(fā)現(xiàn)：Pilot通過插件的形式可以支持多種服務注冊平臺（K8s、Mesos等），通過平臺適配器（Platform Adapter）將服務注冊平臺的服務數(shù)據(jù)填充為標準服務模型（Abstract Model），例如Pilot通過K8s適配器，將K8s中的Service及Pod實例等服務信息，轉換為標準模型供Pilot使用。Pilot在得到統(tǒng)一的服務信息后，將服務信息通過Envoy API下發(fā)到數(shù)據(jù)面Envoy代理，實現(xiàn)服務發(fā)現(xiàn)功能[3]。
流量路由及服務治理：運維人員可以通過Rules API指定各種高級流量管理規(guī)則（Gateway、VirtualService等），這些規(guī)則將被轉換為數(shù)據(jù)面Envoy可以識別的格式，通過Envoy API下發(fā)給Envoy，Envoy在得到這些規(guī)則后，按照規(guī)則進行流量轉發(fā)及安全認證[3]。
Gally是負責配置的驗證和處理的組件，從底層平臺獲取配置，驗證配置信息的格式和內容的正確性，并將這些配置信息提供給Pilot使用。
Citadel 是與安全相關的組件，主要負責密鑰和證書的管理，可以實現(xiàn)強大的授權和認證等功能。
Part 04●??總結?●
本文從傳統(tǒng)微服務在具體實施中存在的問題出發(fā)，簡述了為解決這些問題而產生的服務網格架構思想，最后對這種架構思想一種最受歡迎的實現(xiàn)方案Istio和核心組件進行了的簡單介紹。但是任何一種方案都很難做到一勞永逸，Istio只是把原來分散在應用內部的復雜性統(tǒng)一抽象出來放到了統(tǒng)一的地方，且Istio的架構相對復雜，在具體生產中，必須做好清楚的規(guī)劃，權衡它帶來的好處是否遠大于額外維護它的花費，選擇合適的架構方案。
參考文獻
[1] 陶志,向忠清.微服務架構Service Mesh的設計與應用[J].計算機應用，2020，39（1）:39-53.
[2]Istio官網資料[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.
