在微服務化建設中，應該考慮到 ESB ，也必須考慮到 ESB 。那麼同樣是面向服務的架構， ESB 與微服務相比差別在哪兒？微服務化的建設應該如何安置 ESB ？在新型架構終將取代腐化傳統架構的背景下，如何遷移、替代，保證業務的可用性？接下來的內容裡，將給大家做一個詳細的分析。

SOA與ESB

技術架構的發展有其規律可循，從單體到垂直拆分、再到面向服務、最後到分散式微服務，從技術架構上來看是化整為零的，從服務管理角度來看是從單一的管理到集中式的管理。在服務化以後，也就是提出面向服務的架構以後，除了微服務以外，SOA 和ESB 也是大家熟知的架構：

• SOA架構：其實是一種設計理念，沒有架構和技術的依賴，只是多個服務以獨立的形式部署執行，服務間通過網路呼叫，最終提供一系列完整的功能。

• ESB：企業服務匯流排，用來連線各個服務節點，服務間通訊都通過 ESB 做路由和轉發。最主要的是，不同應用可能有不同的協議和報文，ESB 最大的功能是解決不同的服務間互聯互通。所以，ESB 其實也算是 SOA 的一種實現形式。

微服務的特點

看著上面 SOA 的描述，是不是感覺跟微服務架構也差不多？或者說微服務是 SOA 的昇華。那麼微服務與 SOA、ESB 有什麼不同呢？

我們先來看看微服務優勢介紹：

1、獨立、專注、自治

• 可以獨立的部署、獨立的執行，使用單獨的資料庫，甚至使用單獨的前端。這樣可以將故障影響面降低，不會出現牽一髮動全身的事情。

• 專注於自身的業務，比如報表服務，只關注於報表，也就能聚焦於報表業務，不需要考慮監控、告警和日誌，只需要輸入資料，生成報表。

• 研發團隊自治，可以拉起一個三五人的小團隊，只做報表相關功能和業務，效率高、專業程度高、產生質量和價值高。

2、分散式，高可用，擴縮容，資源分配

• 微服務框架，支援分散式的部署和執行方式，解決了服務的高可用問題。

• 通過註冊中心的服務發現，實現服務的動態擴縮容，可根據業務併發量，自動調整橫向的擴縮容量。

• 根據不同的業務模組，調整服務的資源配比。例如在財務系統中，使用者管理模組（使用者增刪改）使用頻率較低，可以部署一個資源少、單副本的使用者服務；但是賬務模組使用極其頻繁，每天達到上百單，可能分配一個資源多、多副本的賬務服務。但是如果非微服務架構的話，就需要做系統的整體擴容，以滿足最大業務量的模組，會造成其他模組的資源浪費。

3、服務解耦、服務化

• 拆分了微服務以後，服務間的依賴都會通過網路傳輸的方式提供。也就是說一個服務只需要提供所需的功能介面，就可以滿足整體的業務實現。因此，微服務使用什麼程式語言，如何實現業務邏輯都可以不用考慮，只需要提供該有的功能介面（只關注於結果）。這樣服務在開發、管理、使用的時候，可以實現真正的解耦，不會受到開發框架、開發模式的制約。

• 微服務化以後，服務的業務能力，不只是該系統可以使用，其他有需要的部門或者系統也可以通過介面呼叫該微服務，提供給其業務處理能力。

ESB對比微服務

1、獨立而不自由。相對於微服務，SOA架構可以獨立部署業務服務，但是不夠自由，不能像微服務那樣自由互通，只能通過 ESB 做服務通訊，所有服務通訊都需要 ESB 轉發，在 ESB 處集中管理，配置許可權、配置策略。

2、非分散式解決方案，服務的高可用無法通過框架整體解決，只能通過傳統方式解決。所以，更無法實現橫向動態的擴縮容。

3、 ESB 儘管也是面向服務的框架，但是卻無法真正的實現服務化。服務化，應該是自消費的模式，微服務的服務能力提供以後，使用者可以實現訂閱使用。但是 ESB 中，服務能力提供出來只是給特定場景的某幾個服務使用，其他服務如果想使用，需要通過定製化的增加。

4、與自消費的道理相同，服務提供者不能實現自動化的服務提供，ESB中需要增加對應的介面以便於服務提供相應的業務能力。所以在ESB建設中，會提前制定好需要暴露的指定介面，如果有新增的需求，需要針對性的定製化。而微服務提供的則是一個微服務平臺，只要遵循特定的協議，無論是服務的提供還是使用，都可以自由的上下線和增減。

5、微服務架構是新型的服務化架構，而 ESB 架構很容易腐化，且維護困難，技術核心非開源，受廠商繫結。微服務基本上都是基於開源的新型的技術，不存在腐化，且可以自主掌握核心技術。

6、 ESB 是集中化的服務管理模式，ESB 的效能將決定集團整體的通訊效能，且由於過於“集中”導致一旦匯流排出現問題，整個集團的資訊化系統將面臨“癱瘓”的風險。而微服務則不同，微服務採用去中心化方案，任何一個元件出現問題都不會影響全域性的業務。

ESB終將被替代

業務持續增長，所以需要技術不斷革新，促進技術框架也不斷進步。一切變化的源頭都在業務的變化，業務消費量成幾何倍增長，所以要求服務可以自由的擴縮容；新型業務的不斷增加，要求服務支援動態的運營和管理。而ESB 的架構過於死板，已經完全不適合雲原生理念下的服務治理。

老舊的系統架構逐漸力不能支，新型的微服務架構應運而生，在這個趨勢的指引下，我們開始做微服務化的建設，但是在微服務化建設期間 ESB 如何安置，是一個比較大的問題。企業中多數系統的互聯互通都依賴於 ESB 的服務匯流排，但同時改造所有 ESB 接入的系統，工程量會很巨大，容錯率會很低，危險性也極高。因此ESB 的替代儘管勢在必行，卻也需要慎重的規劃。

通常 ESB 的改造需要採用逐步改造加逐步遷移的方式，根據不同的系統現狀，做相應的方式處理：

• 接受深度改造的系統，通過拆分改造成微服務系統，那麼之前的呼叫方式可以直接修改成微服務的呼叫方式，這部分在我們的微服務化建設當中，需根據實際情況做好相應的建設規劃；

• 支援輕度改造的系統，不做微服務化拆分，但是可以改造呼叫或訪問的方式和地址。這部分系統可以將呼叫地址直接換成 API 閘道器的地址，通過 API 閘道器提供原 ESB 的如協議轉換、路由轉發、認證控制等功能，替換掉 ESB 的代理；

• 完全不接受改造的系統，或者對 ESB 依賴極強的系統，在做深度改造之前，ESB 不能被取代，那麼仍需要保留 ESB 。但是需要考慮新改造的，或者增量的微服務系統，與 ESB、與老舊系統之間的通訊，因此需要對執行中的 ESB 做相容和納管。

在微服務建設的初期，ESB 因在企業中起到的關鍵作用，並不能完全替換或取代，因此需要有個過渡期：通過微服務管理臺，相容納管 ESB 的服務；通過API 閘道器轉換報文，路由轉發 ESB 的介面，以保證存量的系統與增量或改造的系統相容管理、互聯互通。

其實 ESB 的功能，路由、轉發，與 API 閘道器的功能極其相似。接下來，我們將會重點分析 API 閘道器在微服務中的作用與 ESB 的區別和優劣，敬請期待。