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