作者：顧欣

微服務架構是當今互聯網和金融機構漸趨主流的系統架構模式，其核心是集成服務通信、服務治理功能的服務框架，微服務框架在持續演進同時，服務網格（Service Mesh）作為一種新型的微服務架構，因架構靈活、普適性強，被認為具有較好發展前景。中國工商銀行（后簡稱工行）主動探索服務網格領域，從 2019 年開始服務網格技術預研工作，通過對服務網格技術深入研究和實踐后，于 2021 年建設了服務網格平臺。服務網格與現有微服務架構融合發展，助力工行應用架構向分布式、服務化轉型，承載未來開放平臺核心銀行系統。

01

業界服務網格發展現狀

Cloud Native

自 2016 年服務網格技術誕生以來，業界涌現了諸多的開源產品，如 Istio（Google + IBM + Lyft）、Linkerd（Twitter）、Consul（Hashicorp）等。其中以 Istio 社區活躍度和認可度最高，被作為服務網格的標桿開源產品。

服務網格是一個專門處理服務通訊的基礎設施層。它通過在業務 Pod 中注入 Sidecar 容器，接管業務容器的通信流量，同時 Sidecar 容器與網格平臺的控制平面對接，基于控制平面下發的策略，對代理流量實施治理和管控，將原有服務框架的治理能力下層到 Sidecar 容器中，從而實現了基礎框架能力的下沉，與業務系統解耦。

圖 1：服務網格示意圖

Sidecar 容器接管后端服務通信的進出流量后，通過標準協議進行服務間通信，可實現跨語言、跨協議的服務互訪。此外，Sidecar 容器可對代理的流量進行管控，如統一的服務路由、安全加密、監控采集等。

圖 2：服務網格請求流轉過程示意圖

02

服務網格技術在工行的

探索與實踐

Cloud Native

工行從 2015 年開啟了 IT 架構轉型工程，截止目前分布式體系已覆蓋 240 余個關鍵應用，生產已有約超 48 萬個提供方分布式服務節點，日均服務調用量超 127 億，逐步實現了超越主機性能容量的集群處理能力。工行分布式服務平臺在穩定支撐已有業務系統的平穩運行同時，也存在一些業界共性的挑戰，諸如：

1）跨語言技術棧的互聯互通需研發多套基礎框架，技術研發和維護成本高。

2）多產品線下，各應用使用了不同版本的基礎框架，推動各應用升級框架周期較長，生產并行運行多版本的基礎框架，兼容壓力較大。

為解決當前痛點，工行積極引入服務網格技術，探索解耦業務系統與基礎設施，完善服務治理能力。

1

?與微服務框架融合發展，構建企業級服務網格平臺

服務網格（Service Mesh）平臺在建設過程中，集成了原有分布式體系的注冊中心、服務監控等基礎設施，將原服務框架客戶端中最基礎的通訊協議編解碼能力以輕量級客戶端的形式保留在業務系統中，其余服務框架客戶端的能力均下沉至 Sidecar 中，可與服務框架兼容發展，平滑過渡。目前工行已完成服務網格（Service Mesh）平臺的建設，在與分布式服務平臺融合發展過程中，打通了異構語言系統的服務治理與監控體系，解耦了業務與中間件系統，豐富了流量治理能力，并已在智能投顧、文字識別等應用完成業務試點。

圖 3：服務網格邊車（Sidecar）與微服務 SDK 對比圖

服務網格控制平面包含了配置中心、注冊中心、安全中心、管控中心、監控中心、日志中心等模塊。數據平面 Sidecar 與原服務框架使用相同的通訊協議（Dubbo/Spring Cloud），支持服務網格系統與原服務框架系統互聯互通，平滑遷移。

圖 4：工行服務網格架構圖

2

?探索企業級方案，支持規?；渴鸷推交w移

工行服務網格在大數據、高頻聯機等服務場景下，對流量代理部署模式、平滑遷移、性能優化等方面開展了落地實踐。

（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：工行控制面組件演進圖

2

?構建企業級服務治理能力，支持精準流量管控

目前開源 Istio 的流量治理能力極其有限，只有基礎的路由與可觀察性，無法滿足企業級的需求。SOFAMesh 基于 Istio 架構設計，自研數據面，并調優部分控制面組件，可滿足企業落地需求，工行與 SOFAMesh 團隊合作，建設了金融級的服務網格平臺，并對流量管控能力進行了企業級增強。工行服務網格已具備完善的監控運維能力，能監控到各節點運行時狀態，支持對各節點進行實時流量調撥，對于故障節點具備實時流量摘除能力，能對各節點進行統一安全管控。

（1）監控運維能力

服務網格平臺內置了完善的監控與報警能力，支持向第三方監控系統上報服務監控、鏈路監控等監控指標；并具備根據單位時間內的業務請求異常率閾值的報警，且能在觸發限流、熔斷、降級、故障自愈等服務治理功能時，同步觸發對應的報警事件。

（2）流量治理能力

服務網格平臺已具備細粒度的流量精準匹配能力，從流量身份標識角度識別特定標識的流量合集，并對這部分流量進行精準管控。平臺現已支持（標簽級/方法級/服務級/應用級）限流、熔斷、降級、路由、流量鏡像、鏈路加密、鑒權、故障演練、故障隔離等企業級的流量管控能力。

（3）故障自愈能力

傳統故障反饋依賴監控報警后通過應急預案臨時處置故障節點，業務和運維定制應急預案的能力，強依賴有經驗的運維工程師，新人上手成本高；且預案操作散落在文檔中，可維護性差，隨著業務迭代可能會逐步退化，增加操作復雜度。服務網格平臺提供了一套統一的基礎故障自愈系統，以時間窗口內的業務請求失敗率為黃金指標，輔助窗口期間最少調用次數、失敗率倍數等，實現常見故障自動感知，自動從客戶端或服務端側網絡隔離故障節點，并在故障節點恢復后能網絡自恢復，達到業務自愈的能力，提升了分布式系的運維高可用能力。

圖 9：故障隔離工作圖

（4）安全管理能力

服務網格平臺已支持安全認證能力，支持國密及多種主流算法構建加密通道，實現更加安全的數據傳輸，以零信任網絡的安全態度，實現全鏈路可信、加密；并能識別調用方身份標識，根據身份標識設置訪問控制策略（黑/白名單）。在有多接入方的業務場景中，可預防個別客戶系統故障或者惡意攻擊，對異?？蛻魧嵤┖诿麊喂芸?#xff0c;拒絕非法訪問，保護本系統的可用性。

圖 10：安全管控工作示意圖

03

未來展望

Cloud Native

服務網格作為云原生領域下一代微服務技術，經過 5 年多地演進，僅在個別頭部企業大規模生產實踐，以銀行為代表的金融同業中尚無成功案例。工行服務網格已完成多語言、異構技術、邊緣場景的業務試點，基本論證服務網格在流量管控、系統擴展性的優勢，具有下沉服務治理能力到基礎設施層，高度解耦中間件與業務系統的可行性。后續，工行將在全面總結前期試點經驗的基礎上，擴大試點應用范圍，充分論證服務網格技術在差異化的技術架構、銀行多樣化業務場景的適應性，同步打磨完善平臺能力，全面提升性能容量和穩定性，為金融同業落地服務網格技術提供最佳實踐與示范。

往期推薦

數字化轉型下的銀行云單元架構

漫畫：據說很多搞軟件的羨慕硬件工程師

一線大廠的企業云原生成本優化實踐指南

源三：聊聊注冊中心在螞蟻集團的降本提效之路

聊聊技術人的“績效考核”

敏捷效能提升的五大要素與誤區

Log4j2維護者吐槽沒工資還要挨罵，GO安全負責人建議開源作者向公司收費

億級流量架構實戰之秒殺設計

精華：軟件架構模式的7種武器

聊聊真正的架構設計

總結

以上是生活随笔為你收集整理的中国工商银行的 Service Mesh 探索与实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。