基于微服務架構的企業服務總線在銀行系統集成中的應用

王世澤

摘 ?要：近年來，隨著各金融公司線上業務的快速發展和日趨激烈的競爭壓力，各金融領域企業都紛紛新建了很多業務系統，以此來應對技術與業務的挑戰，由于業務系統之間的交互變得越來越頻繁，但卻存在信息共享能力差[1]，信息集成不夠深入等問題，數據傳輸的準確性和及時性往往也難以得到保證。因此，ESB企業級服務總線系統作為系統的交易樞紐，其高可用性決定了一個企業能否不間斷地對外提供服務。該文結合目前廣泛使用的微服務架構思想，提出去中心化的ESBX實踐，構建了一種高可用的企業級服務總線系統，并詳細描述了其應用架構及邏輯部署架構。

關鍵詞：微服務;ESB;金融領域;去中心化

中圖分類號： TP393 ? ? ? ? ? ? 文獻標志碼：A

0 引言

隨著公司業務不斷擴展，特別是線上業務的拓展，對建立能更快速地響應市場變化、進行服務靈活便捷組合調整的IT架構的需求越來越急迫。因此，公司對原有系統進行邊界劃分，建立起多層次、條線化、松耦合的IT應用架構，簡化接口和交易環節，使架構更加清晰，以此來應對快速變化的業務訴求和面向互聯網流量大、來源廣、峰值和信息安全訴求強烈的非功能訴求。微服務架構體系在擴展性、容錯性以及日后基于容器技術的DevOps等方面具有優勢，促使公司服務向微服務方向轉變。微服務組件化、松耦合、自治和去中心化的優勢背后，同樣伴隨著服務依賴復雜多變、調用鏈路長難以監控、入口信息安全實現復雜等問題。為應對以上問題，該公司在傳統企業服務總線ESB思想上進行延伸和發展，研發基于微服務架構的企業服務總線，克服傳統ESB過于集中的不足，側重于服務治理和服務網關，集成傳統SOA理念并融入微服務思想。

1 ESB（企業服務總線）

企業服務總線（Enterprise Service Bus，ESB） 是一個主要依賴XML消息交換的企業級消息系統。其可以消除不同應用之間的技術差異，讓不同的應用服務器協調運作。從功能上看，ESB提供了事件驅動和文檔導向的處理模式，以及分布式的運行管理機制，它支持基于內容的路由和過濾，具備了復雜數據的傳輸能力，并可以提供一系列的標準接口。

2 微服務

微服務架構和 SOA 架構非常類似，微服務架構特別強調“業務需要徹底的組件化及服務化”，將系統拆分為多個可以獨立開發、設計、部署運行的模塊。這些模塊間通過服務化完成交互和集成。微服務的特征有4個。1）通過服務實現組件化 。2） 按業務能力來劃分服務和開發團隊。3）去中心化。4）基礎設施自動化（DevOps、自動化部署）。

3 基于微服務的ESB擴展-ESBX

微服務架構體系下，異構環境逐漸減少，公司整體技術棧相對統一，ESB在異構環境中的優勢逐漸降低，并且ESB的基本功能也決定了其固有的中心化特征，造成ESB系統很容易成為性能瓶頸以及熱點服務。而微服務在開發過程中的易用性和普及型提升開發效率，因此在微服務服務注冊和負載調用的基礎上，引入ESB思想，并對其進行擴展，形成ESBX（Enterprise Service Bus expand）。

ESBX將報文校驗、路由選擇、信息擴展、安全管控功能、流量擋板和預警監控添加進微服務間的同步或異步調用，形成ESB在微服務體系下的新型企業服務總線思想。

4 ESBX的架構設計

4.1 ?ESBX需要解決的問題

4.1.1 嚴格的信息安全要求

為了更好地保證信息安全，隔離敏感核心數據，采用網絡隔離技術，將網絡劃分為隔離區（Demilitarized Zone）簡稱DMZ區和內部服務區（Service Zone）簡稱SZ。然而，這樣不可避免地會使服務接入變得更加復雜。各服務調用者在接入前，都需要滿足安全要求，這樣會造成各系統重復建設。

4.1.2 與日俱增的服務量

當服務數量級增多后，服務的提供和調用都成為巨大的挑戰。因此，需要一個服務注冊中心，為服務的發布和調用提供統一的平臺，另外在服務接入前，應提供調用方和服務方的相關信息，避免建立不合理的調用關系。

4.1.3 統一監控平臺的缺失

從細微的角度看，可以監控服務器的運行狀態，通過告警及時發現異常。從整體角度看，可以分析服務的訪問熱度和響應能力，及時擴大規模或調整布局。

但無論是服務調用方還是提供方，對整個調用鏈路的信息進行采集、處理、統計和分析都是難以獨立實現的。因為這不僅需要向鏈路中的各系統采集數據，而且一旦調用關系改變，數據采集方案也需要更改。即使是這樣，由某系統獨立實現的信息采集，也只能獲得有限的、局部的調用數據，而對于企業級服務調用的風險預警和統計分析來說這樣是不夠的。因此，需要建立一個全司范圍內的，集信息收集、統計、分析和展示功于一體的平臺。

4.2 ESBX架構設計

ESBX平臺以提升業務組織能力為原則，其根本目標是幫助業務系統在復雜的IT架構下，實現一種便捷、統一的服務調用方案，主要包含統一管理服務、實時監控服務、服務注冊、統一接入服務、消費樁與服務樁功能，圖1 為應用架構圖。

5 ESBX建設實施

5.1 服務接入

針對不同的接入需求，平臺提供了API和OpenAPI 2種接入方案。API模式是公司核心系統之間的調用，OpenAPI模式是公司互聯網系統或公司外部系統與核心系統之間的調用。服務方和調用方只需要知道對方所處的網絡區域（DMZ或SZ），而服務注冊、安全認證和具體的網絡連接都由ESBX平臺實現。

OpenAPI調用模式：服務調用方在接入服務前，需要通過OAuth平臺獲取token。然后，通過token訪問outer-server，它會對服務調用方或提供方的身份進行有效性驗證，只有驗證通過的服務，才會被允許接入。token由OAuth系統統一生成和管理，服務方無需搭建認證系統。

API模式：SZ內部服務相互之間調用，它通過在各個服務實例中植入stub模塊，實現一種輕量、靈活的接入控制。

outer-server的作用是可以將內部API地址生成為對應的對外OpenAPI地址，供外部系統調用，也可以通過OpenAPI轉發為API的具體地址。當調用方為外部時，需要通過向outer發起請求，并傳入access_token等參數，實現將調用轉發給服務方，最后通過outer將結果轉發給調用方。

oauth-server為認證提供方，向客戶端、用戶提供認證和授權服務。

5.2 消費樁與服務樁stub

stub主要提供API調用（即點對點調用）的相關功能，例如服務注冊、消費注冊、授權管理、負載均衡和調用監控。

stub是一個JAR包，在服務開發期間引入，一同編譯打包。stub將提供消費樁或服務樁的相關功能。該stub將依托Spring Cloud框架，擴展Ribbon負載均衡功能，提供消費樁的功能，對所有請求進行攔截以實現服務樁的相關功能。

5.3 數據加密

外部系統調用內部系統是由outer-server對外部請求進行密文接收，解密轉發給內部系統，同時，將內部系統返回的報文加密發送給外部系統方，加密方式可在服務接入時設置，支持動態可調。

5.4 負載均衡和流量擋板

ESBX采用負載均衡機制，實現對服務方各實例上請求量的分流。在服務進行調用時，服務提供方的stub在攔截到請求后，將起到流量擋板的作用，防止針對資源的DoS攻擊直接沖擊服務系統。

5.5 服務注冊與管理

服務注冊管理admin為各業務系統提供了一個自服務化的管理平臺。服務提供方只需要在admin管理平臺上配置服務信息，即可完成服務注冊。服務注冊完成之后，可以根據需求選擇發布到不同的網絡區域，然后ESBX會為其匹配對應的接入方式（API或者OpenAPI），即可完成服務的發布。

ESBX會通過admin平臺將服務的信息錄入數據庫，待接入服務啟動后，注冊中心向已有的服務推送變更信息，調用方可以從注冊中心上獲取服務編碼。

5.6 實時監控

平臺采用心跳檢測機制，實現消費方對服務方系統狀態的監測。監控平臺monitor采集經過API或OpenAPI產生的調用信息，并為用戶提供實時查詢功能。

6 ESBX應用部署

圖2為邏輯部署架構圖，為了將ESBX的相關功能集成到各個業務系統中，要求調用雙方都嵌入stub模塊。管理中心以基礎數據為依托，在注冊中心上建立基礎節點，當服務啟動時，向注冊中心上報自身信息，進行服務信息注冊，注冊中心將添加啟動服務對應的實例信息，并將變更推送給已啟動的實例，更新實例緩存信息，管理中心和監控中心的失效不會影響整個系統的功能，stub將讓業務系統進入離線模式，依靠緩存信息進行服務調用。

注冊中心至少需要一個三節點的ZooKeeper系統。各個服務通過HTTP協議進行通信，調用數據將由各stub異步上報給監控中心，用于進行數據統計。

7 結語

該文對基于微服務與ESB架構思想的ESBX進行了研究，提出了一種高可用服務總線系統的構建思路，在信息交互、集成、共享及維護等方面獲得良好的效果，極大地提高了現有系統資源的利用率，提升了公司客戶服務體驗，以及業務產品開發效率和開發質量。

參考文獻

[1]劉保汛，劉文杰.基于SOA 架構的ESB 在商業銀行中的研究與實現[J].信息技術與信息化，2018（2）：19-21.