基於服務網格的分散式 ESB, 實現應用無關的傳統 ESB 轉型升級

語言: CN / TW / HK

在文章的開始前,我們首先要思考一個問題:從“煙囪式”架構、SOA 架構、微服務架構。服務架構為何一直在變化演進?

一、ESB 的由來

今天話題主要聚焦在金融行業中較常見的 SOA 架構實現的一種方式 —— 企業服務匯流排 ESB (全稱 Enterprise Service Bus)

在 SOA 架構下,隨著業務越來越複雜,服務越來越多,他們的呼叫關係圖會變成如下圖所示的情況。

那麼該怎麼理清這一團錯綜複雜的內容呢?

這時 ESB 企業服務匯流排便應運而生。通過下圖可以發現,所有服務皆和 ESB 連線,ESB 就像是人身體中的心臟,連線了各個服務節點。

例如,如果呼叫方和提供方需要通訊時,服務的互動路線是:

服務呼叫方 (服務請求) --> ESB (請求接收) --> 服務提供方 (服務處理) --> ESB (服務提供返回結果) --> 服務呼叫方 (服務返回)

傳統 ESB 發揮的核心功能在於,提供不同協議、報文服務之間通過 ESB 實現互聯互通。ESB 提供協議轉換、解釋以及路由定址等功能。在整個服務呼叫過程中起到至關重要的作用。

雖然 ESB 系統解決了 SOA 架構所帶來的問題。但是隨著網際網路快速發展,人們對於網際網路的日常依賴不僅越來越深,同時也對網際網路應用要求越來越高。響應時間超過一兩秒都可能直接降低使用者的體驗感,造成客戶的流失。同時,隨著業務發展,服務越來越多的情況下,ESB 內部呼叫關係在不梳理的情況下就會變成如下圖所示的混亂情況。

所以不管什麼架構定時整理都至關重要!

二、傳統 ESB 的劣勢

正如上文所描述的,傳統的 ESB 模式已經無法適應越發複雜的環境和越來越多的需要,它目前面臨的困境如下,

(1) 由於老舊 ESB 系統對於使用者來說是一個黑盒的存在,排查問題難。

(2) 服務和服務之間呼叫關係需要人工梳理記錄,耗時費力且不好維護追溯。且傳統 ESB 採用集中式架構,可擴充套件性、可觀測性低、且不支援微服務框架。

(3) 對於服務之間呼叫由於不支援鏈路追蹤、服務訂閱、故障分析、統計、服務治理方面的功能尤為欠缺。

這時,再從整個架構體系中看,老舊 ESB 就顯得較笨重且阻塞。隨著服務越來越多老舊 ESB 系統的弊端也逐漸明顯,系統改造、架構升級便被提上了日程。

那麼,如何解決老舊 ESB 所帶來的問題呢?

作為業務方來說最重要且核心關注點是:如何穩定、快速、改動小的情況下實現快速遷移優化替換?

解決該問題通常可通過兩方面入手:一方面是採用 ESB 替換升級,追求一站式解決。另一方面則是,“曲線救國”進行橫向擴充套件

下邊針對這兩方面咱們分別聊聊。

三、傳統 ESB 弊端的雙重解決之道

A. ESB 替換升級、一站式解決

新型 ESB 替代升級解決方案核心技術:採用新一代 Servicemesh 微服務架構,無須考慮架構、開發語言、伺服器是容器還是非容器等所有情況。服務治理相關的內容更是其強勢的地方。隨著網格技術越來越成熟,越來越多的企業引進 Servicemesh 服務網格技術。並且,隨著容器的優勢而快速擴充套件逐漸成為業界主流體系的同時,Servicemesh 自身的優勢越來越凸顯,成為業界主流微服務解決方案也不無可能。

Envoy 邊車接入無須關注架構問題的同時,支援在容器/虛擬機器/物理機上完美相容使用,對原服務無須做任何修改,可以對老系統漸進式升級改造。並且可監控從虛擬機器到容器、容器到虛擬機器之間呼叫的整條鏈路資訊,解決了應用容器化到非容器化監控斷層問題。

新型替代 ESB 方案的優勢如下,

(1) 不改變原有 ESB 的接入接出使用習慣

兼顧高效能高併發、可擴充套件、可觀測、可治理等場景。同時無需關注架構、報文編碼等。不管是單體應用還是微服務架構都能無縫相容。

(2) 減少溝通壁壘

減少各個部門溝通協作,降低推進所需的溝通協調成本。由於新型 ESB 是在不改變原有老 ESB 的接入方式,所以對於業務方來說感知較小甚至可做到無感知。有效避免了推動新技術時需要的各個部門溝通協作推行難等問題。

(3) 不增加新元件的維護

在不增加新元件的情況下,完美的解決現有老舊 ESB 系統所帶來的一切問題。減少運維人員負擔和接收新架構時所需要的學習成本。

(4) 自主可控

基於開源框架、程式碼自主可控。支援鏈路追蹤、故障定位分析。

B. “曲線救國” 橫向擴充套件

針對老舊 ESB 系統的劣勢,上述中採用新一代 Servicemesh 微服務架構是一種解決方案。第二種方案,則是被稱為“曲線救國”的橫向擴充套件,其思路是不管現有老舊 ESB 系統,採用最新的微服務框架+ API 閘道器的組合,來另闢蹊徑。新的系統採用微服務框架和 API 閘道器的方式來互聯互通。老舊服務則通過 API 閘道器轉向老 ESB 系統,來共同實現新老架構的一個更替。

如下圖所示,在企業內部開發新型業務系統通過微服務框架提供的解決方案可直接呼叫,如需要呼叫老存量業務資料則通過 API 閘道器 --> 老 ESB 系統,這就需要 API 閘道器需要兼顧一定的協議轉換功能。

這裡有一個需要注意的問題,在新型業務系統呼叫存量的單體應用或者老系統服務是沒問題的,但由於 API 閘道器和老 ESB 實現問題,無法逆向定址。所以老系統呼叫新型業務系統則是不通的。

同時,由於老舊系統逐步改造需要各方業務配合,所以老 ESB 系統到新架構過渡期較長,在過渡階段中會遇到一些比較棘手需要暫時繞開的處理方法。且在過渡階段老 ESB 系統所存在的種種問題由於沒有解決所以依舊存在。

四、總結

綜上,我們回顧了傳統 ESB 誕生的背景,在不斷的發展過程中,老 ESB 的弊端逐漸顯現。針對於老 ESB 系統所存在的種種弊端,目前有兩種可行的方式來實現系統改造和架構升級,一種是採用新一代 Servicemesh 微服務架構,另一種則是忽視老舊 ESB 系統,採用最新的微服務框架+ API 閘道器的組合,實現新老系統的交替。而對於不同的企業來說,兩種升級方式究竟選擇哪一種便是就是見仁見智了。