*Service Mesh* 是下一代的微服務架構基礎。螞蟻集團從 2018 年初就開始了技術探索並進行了落地試點。目前， Service Mesh 覆蓋了螞蟻數千個應用，實現了核心鏈路全覆蓋。
螞蟻集團通過 Service Mesh 的大規模落地，向雲原生走出了堅實的一步，驗證了可行性，真切看到了基礎設施下沉後無論是對業務還是對基礎設施團隊都帶來了研發和運維效率的提升，成本的降低。
與此同時，螞蟻也在積極將成熟的技術開放給社會，目前已將自研資料面 MOSN 開源，歡迎開源愛好者一起共建。
｜前言｜
微服務架構是當今網際網路和金融機構漸趨主流的系統架構模式，其核心是整合服務通訊、服務治理功能的服務框架，微服務框架在持續演進同時，服務網格（Service Mesh）作為一種新型的微服務架構，因架構靈活、普適性強，被認為具有較好發展前景。
中國工商銀行（後簡稱工行）主動探索服務網格領域，從 2019 年開始服務網格技術預研工作，通過對服務網格技術深入研究和實踐後，於 2021 年建設了服務網格平臺。服務網格與現有微服務架構融合發展，助力工行應用架構向分散式、服務化轉型，承載未來開放平臺核心銀行系統。
PART. 1 業界服務網格發展現狀
自 2016 年服務網格技術誕生以來，業界湧現了諸多的開源產品，如 Istio（Google + IBM + Lyft）、Linkerd（Twitter）、Consul（Hashicorp）等。其中以 Istio 社群活躍度和認可度最高，被作為服務網格的標杆開源產品。
服務網格是一個專門處理服務通訊的基礎設施層。它通過在業務 Pod 中注入 Sidecar 容器，接管業務容器的通訊流量，同時 Sidecar 容器與網格平臺的控制平面對接，基於控制平面下發的策略，對代理流量實施治理和管控，將原有服務框架的治理能力下層到 Sidecar 容器中，從而實現了基礎框架能力的下沉，與業務系統解耦。
圖 1：服務網格示意圖
Sidecar 容器接管後端服務通訊的進出流量後，通過標準協議進行服務間通訊，可實現跨語言、跨協議的服務互訪。此外，Sidecar 容器可對代理的流量進行管控，如統一的服務路由、安全加密、監控採集等。
圖 2：服務網格請求流轉過程示意圖
PART. 2 服務網格技術在工行的
探索與實踐
工行從 2015 年開啟了 IT 架構轉型工程，截止目前分散式體系已覆蓋 240 餘個關鍵應用，生產已有約超 48 萬個提供方分散式服務節點，日均服務呼叫量超 127 億，逐步實現了超越主機效能容量的叢集處理能力。工行分散式服務平臺在穩定支撐已有業務系統的平穩執行同時，也存在一些業界共性的挑戰，諸如：
（1）跨語言技術棧的互聯互通需研發多套基礎框架，技術研發和維護成本高。
（2）多產品線下，各應用使用了不同版本的基礎框架，推動各應用升級框架週期較長，生產並行執行多版本的基礎框架，相容壓力較大。
為解決當前痛點，工行積極引入服務網格技術，探索解耦業務系統與基礎設施，完善服務治理能力。
與微服務框架融合發展，構建企業級服務網格平臺
服務網格（Service Mesh）平臺在建設過程中，整合了原有分散式體系的註冊中心、服務監控等基礎設施，將原服務框架客戶端中最基礎的通訊協議編解碼能力以輕量級客戶端的形式保留在業務系統中，其餘服務框架客戶端的能力均下沉至 Sidecar 中，可與服務框架相容發展，平滑過渡。
目前工行已完成服務網格（Service Mesh）平臺的建設，在與分散式服務平臺融合發展過程中，打通了異構語言系統的服務治理與監控體系，解耦了業務與中介軟體系統，豐富了流量治理能力，並已在智慧投顧、文字識別等應用完成業務試點。
圖 3：服務網格邊車（Sidecar）與微服務 SDK 對比圖
服務網格控制平面包含了配置中心、註冊中心、安全中心、管控中心、監控中心、日誌中心等模組。資料平面 Sidecar 與原服務框架使用相同的通訊協議（Dubbo/Spring Cloud），支援服務網格系統與原服務框架系統互聯互通，平滑遷移。
圖 4：工行服務網格架構圖
探索企業級方案，支援規模化部署和平滑遷移
工行服務網格在大資料、高頻聯機等服務場景下，對流量代理部署模式、平滑遷移、效能優化等方面開展了落地實踐。
（1）大資料場景下的無侵入流量代理部署模式
工行應用開發語言主要使用 Java，但在大資料領域 Python 語言也被廣泛使用。針對異構語言場景，服務網格平臺提供了無侵入透明劫持的流量代理方案，簡化了異構語言應用接入難度。無侵入流量代理的核心是通過修改網路 Iptables 規則，強制攔截進出業務容器的流量，並將這部分流量重定向至 Sidecar 容器。
其具體實現為：在啟動業務 Pod 時，通過 Init Container（初始化容器）修改業務 Pod 的網路 Iptables 規則，該規則讓進出業務容器的流量都強制重定向至 Sidecar 容器，實現 Sidecar 容器對業務容器的流量接管。
圖 5：透明劫持流量代理示意圖
但是 Iptables 對效能和可維護性都存在較大的挑戰，故在聯機高頻服務場景，我們提供了輕量級客戶端與 Sidecar 協作的流量代理方案。
（2）高頻聯機場景下的低侵入流量代理部署模式
在聯機高頻服務場景，我們通過對業務應用引入輕量級的客戶端，該客戶端在對業務透明的前提下，改變業務應用的服務註冊發現行為，將原往註冊中心發起的服務註冊與訂閱的行為轉變為往本地 127.0.0.1 的 Sidecar 地址發起服務註冊與訂閱，並由 Sidecar 代理向註冊中心發起服務註冊與訂閱。業務容器通過 Sidecar 代理訂閱後，本地獲取的服務目的地址則為 127.0.0.1 的 Sidecar 地址，後續所有請求將會直接發往 Sidecar，再由 Sidecar 轉發至真實的服務目的地址，實現流量代理能力。
圖 6：埠流量代理示意圖
（3）傳統部署向網格化部署的平滑遷移
目前工行微服務主要有基於 Dubbo 和 Spring Cloud 兩種服務例項組成，且已在生產環境大規模執行，在引入服務網格系統時需具備與原微服務系統的平滑過渡能力。工行通過服務網格系統同時支援 Dubbo 與 Spring cloud 協議，服務網格例項可與原服務框架例項通過相同協議互相訪問。使在同一註冊中心下，服務網格系統與原分散式服務系統可融合發展，平滑過渡。
圖 7：平滑遷移示意圖
（4）規模化部署後的效能挑戰與優化
目前工行最大的註冊中心叢集上有超 48 萬提供者的超大規模業務場景，而在開源 Isito 架構中，服務發現的目的地址、配置資訊等會通過 Pilot 的 Xds API 進行全量下發。在大量服務例項的情況下，全量下發會影響 Pilot 和 Sidecar 的效能和穩定性。服務網格平臺通過引入第三方註冊中心與配置中心。由 Sidecar 直接對接註冊中心與配置中心，支援按需訂閱，配置精準下發，大幅降低 Pilot 和 Sidecar 壓力。通過壓測，控制平面具備支援百萬級例項的效能容量能力。
圖 8：工行控制面元件演進圖
構建企業級服務治理能力，支援精準流量管控
目前開源 Istio 的流量治理能力極其有限，只有基礎的路由與可觀察性，無法滿足企業級的需求。SOFAMesh 基於 Istio 架構設計，自研資料面，並調優部分控制面元件，可滿足企業落地需求，工行與 SOFAMesh 團隊合作，建設了金融級的服務網格平臺，並對流量管控能力進行了企業級增強。工行服務網格已具備完善的監控運維能力，能監控到各節點執行時狀態，支援對各節點進行實時流量調撥，對於故障節點具備實時流量摘除能力，能對各節點進行統一安全管控。
（1）監控運維能力
服務網格平臺內建了完善的監控與報警能力，支援向第三方監控系統上報服務監控、鏈路監控等監控指標；並具備根據單位時間內的業務請求異常率閾值的報警，且能在觸發限流、熔斷、降級、故障自愈等服務治理功能時，同步觸發對應的報警事件。
（2）流量治理能力
服務網格平臺已具備細粒度的流量精準匹配能力，從流量身份標識角度識別特定標識的流量合集，並對這部分流量進行精準管控。平臺現已支援（標籤級/方法級/服務級/應用級）限流、熔斷、降級、路由、流量映象、鏈路加密、鑑權、故障演練、故障隔離等企業級的流量管控能力。
（3）故障自愈能力
傳統故障反饋依賴監控報警後通過應急預案臨時處置故障節點，業務和運維定製應急預案的能力，強依賴有經驗的運維工程師，新人上手成本高；且預案操作散落在文件中，可維護性差，隨著業務迭代可能會逐步退化，增加操作複雜度。服務網格平臺提供了一套統一的基礎故障自愈系統，以時間視窗內的業務請求失敗率為黃金指標，輔助視窗期間最少呼叫次數、失敗率倍數等，實現常見故障自動感知，自動從客戶端或服務端側網路隔離故障節點，並在故障節點恢復後能網路自恢復，達到業務自愈的能力，提升了分散式系的運維高可用能力。
圖 9：故障隔離工作圖
（4）安全管理能力
服務網格平臺已支援安全認證能力，支援國密及多種主流演算法構建加密通道，實現更加安全的資料傳輸，以零信任網路的安全態度，實現全鏈路可信、加密；並能識別呼叫方身份標識，根據身份標識設定訪問控制策略（黑/白名單）。在有多接入方的業務場景中，可預防個別客戶系統故障或者惡意攻擊，對異常客戶實施黑名單管控，拒絕非法訪問，保護本系統的可用性。
圖 10：安全管控工作示意圖
PART. 3 未來展望
服務網格作為雲原生領域下一代微服務技術，經過 5 年多地演進，僅在個別頭部企業大規模生產實踐，以銀行為代表的金融同業中尚無成功案例。工行服務網格已完成多語言、異構技術、邊緣場景的業務試點，基本論證服務網格在流量管控、系統擴充套件性的優勢，具有下沉服務治理能力到基礎設施層，高度解耦中介軟體與業務系統的可行性。
後續，工行將在全面總結前期試點經驗的基礎上，擴大試點應用範圍，充分論證服務網格技術在差異化的技術架構、銀行多樣化業務場景的適應性，同步打磨完善平臺能力，全面提升效能容量和穩定性，為金融同業落地服務網格技術提供最佳實踐與示範。
本週推薦閱讀
開啟雲原生 MOSN 新篇章 — 融合 Envoy 和 GoLang 生態
