在文章的開始前，我們首先要思考一個問題：從“煙囪式”架構、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 網關的組合，實現新老系統的交替。而對於不同的企業來說，兩種升級方式究竟選擇哪一種便是就是見仁見智了。