王世澤

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

關(guān)鍵詞：微服務(wù);ESB;金融領(lǐng)域;去中心化

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

0 引言

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

1 ESB（企業(yè)服務(wù)總線）

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

2 微服務(wù)

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

3 基于微服務(wù)的ESB擴展-ESBX

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

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

4 ESBX的架構(gòu)設(shè)計

4.1 ?ESBX需要解決的問題

4.1.1 嚴格的信息安全要求

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

4.1.2 與日俱增的服務(wù)量

當服務(wù)數(shù)量級增多后，服務(wù)的提供和調(diào)用都成為巨大的挑戰(zhàn)。因此，需要一個服務(wù)注冊中心，為服務(wù)的發(fā)布和調(diào)用提供統(tǒng)一的平臺，另外在服務(wù)接入前，應(yīng)提供調(diào)用方和服務(wù)方的相關(guān)信息，避免建立不合理的調(diào)用關(guān)系。

4.1.3 統(tǒng)一監(jiān)控平臺的缺失

從細微的角度看，可以監(jiān)控服務(wù)器的運行狀態(tài)，通過告警及時發(fā)現(xiàn)異常。從整體角度看，可以分析服務(wù)的訪問熱度和響應(yīng)能力，及時擴大規(guī)?；蛘{(diào)整布局。

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

4.2 ESBX架構(gòu)設(shè)計

ESBX平臺以提升業(yè)務(wù)組織能力為原則，其根本目標是幫助業(yè)務(wù)系統(tǒng)在復雜的IT架構(gòu)下，實現(xiàn)一種便捷、統(tǒng)一的服務(wù)調(diào)用方案，主要包含統(tǒng)一管理服務(wù)、實時監(jiān)控服務(wù)、服務(wù)注冊、統(tǒng)一接入服務(wù)、消費樁與服務(wù)樁功能，圖1 為應(yīng)用架構(gòu)圖。

5 ESBX建設(shè)實施

5.1 服務(wù)接入

針對不同的接入需求，平臺提供了API和OpenAPI 2種接入方案。API模式是公司核心系統(tǒng)之間的調(diào)用，OpenAPI模式是公司互聯(lián)網(wǎng)系統(tǒng)或公司外部系統(tǒng)與核心系統(tǒng)之間的調(diào)用。服務(wù)方和調(diào)用方只需要知道對方所處的網(wǎng)絡(luò)區(qū)域（DMZ或SZ），而服務(wù)注冊、安全認證和具體的網(wǎng)絡(luò)連接都由ESBX平臺實現(xiàn)。

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

API模式：SZ內(nèi)部服務(wù)相互之間調(diào)用，它通過在各個服務(wù)實例中植入stub模塊，實現(xiàn)一種輕量、靈活的接入控制。

outer-server的作用是可以將內(nèi)部API地址生成為對應(yīng)的對外OpenAPI地址，供外部系統(tǒng)調(diào)用，也可以通過OpenAPI轉(zhuǎn)發(fā)為API的具體地址。當調(diào)用方為外部時，需要通過向outer發(fā)起請求，并傳入access_token等參數(shù)，實現(xiàn)將調(diào)用轉(zhuǎn)發(fā)給服務(wù)方，最后通過outer將結(jié)果轉(zhuǎn)發(fā)給調(diào)用方。

oauth-server為認證提供方，向客戶端、用戶提供認證和授權(quán)服務(wù)。

5.2 消費樁與服務(wù)樁stub

stub主要提供API調(diào)用（即點對點調(diào)用）的相關(guān)功能，例如服務(wù)注冊、消費注冊、授權(quán)管理、負載均衡和調(diào)用監(jiān)控。

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

5.3 數(shù)據(jù)加密

外部系統(tǒng)調(diào)用內(nèi)部系統(tǒng)是由outer-server對外部請求進行密文接收，解密轉(zhuǎn)發(fā)給內(nèi)部系統(tǒng)，同時，將內(nèi)部系統(tǒng)返回的報文加密發(fā)送給外部系統(tǒng)方，加密方式可在服務(wù)接入時設(shè)置，支持動態(tài)可調(diào)。

5.4 負載均衡和流量擋板

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

5.5 服務(wù)注冊與管理

服務(wù)注冊管理admin為各業(yè)務(wù)系統(tǒng)提供了一個自服務(wù)化的管理平臺。服務(wù)提供方只需要在admin管理平臺上配置服務(wù)信息，即可完成服務(wù)注冊。服務(wù)注冊完成之后，可以根據(jù)需求選擇發(fā)布到不同的網(wǎng)絡(luò)區(qū)域，然后ESBX會為其匹配對應(yīng)的接入方式（API或者OpenAPI），即可完成服務(wù)的發(fā)布。

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

5.6 實時監(jiān)控

平臺采用心跳檢測機制，實現(xiàn)消費方對服務(wù)方系統(tǒng)狀態(tài)的監(jiān)測。監(jiān)控平臺monitor采集經(jīng)過API或OpenAPI產(chǎn)生的調(diào)用信息，并為用戶提供實時查詢功能。

6 ESBX應(yīng)用部署

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

注冊中心至少需要一個三節(jié)點的ZooKeeper系統(tǒng)。各個服務(wù)通過HTTP協(xié)議進行通信，調(diào)用數(shù)據(jù)將由各stub異步上報給監(jiān)控中心，用于進行數(shù)據(jù)統(tǒng)計。

7 結(jié)語

該文對基于微服務(wù)與ESB架構(gòu)思想的ESBX進行了研究，提出了一種高可用服務(wù)總線系統(tǒng)的構(gòu)建思路，在信息交互、集成、共享及維護等方面獲得良好的效果，極大地提高了現(xiàn)有系統(tǒng)資源的利用率，提升了公司客戶服務(wù)體驗，以及業(yè)務(wù)產(chǎn)品開發(fā)效率和開發(fā)質(zhì)量。

參考文獻

[1]劉保汛，劉文杰.基于SOA 架構(gòu)的ESB 在商業(yè)銀行中的研究與實現(xiàn)[J].信息技術(shù)與信息化，2018（2）：19-21.