今天準備談下ESB服務總線和API網關產品的集成和融合分析。

先談下背景，在前面我寫過多篇企業傳統IT架構微服務架構轉型的文章，中間也分析過API網關產品和ESB服務總線產品的區別。而實際上可以看到企業進行微服務架構轉型，往往都是一個逐步遷移和過渡的過程。

而對於企業遺留IT環境，由於涉及到的遺留系統消息，協議，數據複雜，往往已經使用了類似ESB服務總線產品進行業務系統之間的應用和數據集成。而實際在轉型中往往一個遺留系統可能會完全重新採用微服務架構框架體系進行建設，而這個微服務應用中也涉及到API集成的問題，這種API集成往往會採用更加輕量高效的API網關來完成。

很多時候我們在談到微服務的時候，都會說到ESB服務總線已經過時，但是實際上對於大的企業存在大量遺留IT系統建設和集成的場景下，一定會存在ESB服務總線和API網關兩種集成產品共存和協同的一段周期來完成過渡。

因此今天準備從幾個方面來講解下ESB和API網關的集成和協同。

1.從產品規劃層面，對ESB總線和API網關兩種產品集成
2.從企業IT存在遺留和微服務兩種應用場景下的集成
3.在準備遷移到完整微服務後，對API網關本身的適配能力提升

下面將分別從這三個方面進行介紹。

對ESB總線和API網關兩類產品的整合

對於我們從10年開始進行自研ESB服務總線的研發，從最早的完全自研，到13年底我們重新啟動基於開源的SercieMix和Camel規則引擎進行定製開發。在這幾年中重點也是對SOA服務開發設計，服務全生命周期管理，SOA管控治理等能力進行完整。

整體的ESB總線的產品架構圖如下：

在整個產品的研發和設計中，我們實際做了以下重要事情。

其一就是ESB底層引擎和ESB管控治理平台的完全分離。即引擎和管控平台可以單獨賣，也可以單獨進行部署，兩者之間通過內部接口進行交互。這個分離不僅僅是方面後續的資源彈性擴展，更加重要的是實現了管控和引擎能力的進一步解耦。

其次就是重新進行ESB開發設計器的開發，在Web端提供簡單的服務組裝設計能力，包括我們常見的數據庫適配，協議轉換，數據映射等基本都可以通過服務設計器完成。

最後就是進一步擴展上層的OpenAPI能力開放平台，對於能力開放平台可以看我前面已經發佈的文字，能力開放平台更多的是實現整個服務接入和消費的自服務能力，對服務本身的運營能力和運維監控能力。

而對於API網關，我們則是基於開源的Kong網關進行定製開發。

當前Kong網關也是大家採用比較多的一個開源API網關產品，底層基於Ngnix和OpenRestry，語言是Lua語言，最重要的是整個架構設計中的可插拔的插件機制，這種插件機制很方便我們自定義插件擴展。比如我們現在對於安全，日誌，運行監控等功能都能夠很方便的通過插件擴展來實現。

當然你也能夠看到對於ESB總線本身也可以完全兼容API網關產品有的對Http Rest接口註冊接入，安全，日誌，流控等功能要求。但是ESB總線整體還是偏重，如果是一個完整的微服務架構應用環境，我們還是推薦直接採用API網關來實現。

基於上面分析，我們看到。

對於ESB總線和API網關都是底層的進行SOA服務和API接口集成的底層引擎。而對於SOA服務全生命周期管理，服務運行監控，能力開放等業務場景和功能需求是完全可以整合為一套的。這也是我們在進行產品規劃和設計的時候重點考慮的內容，即將引擎能力和管控治理能力分離，將管控治理能力進行共性化整合設計。

基於以上思路我們對整個架構進行整合如下：

即整體思路是底層引擎是兩套，即一個是偏重的ESB總線引擎，一個是API網關引擎，但是對於SOA治理管控和運營開放則是整合為一套。一個是SOA運維監控平台是統一的一套，一個是能力開放平台也統一為一套。

但是我們看到雖然ESB總線是一個偏重的引擎，但是我們不啟用其複雜的協議轉換，數據映射，服務編排等功能的時候仍然可以做為要給輕量的SOA總線來使用。

而且我們看到另外一個場景，即企業很多時候不會很快就完成一個微服務架構化的轉型，始終是存在傳統的遺留系統，因此集成問題和場景本身是很複雜的，即使整個集成趨勢是Http Rest接口集成和API網關集成為主，但是你還是得兼容傳統觀的WS服務集成和簡單的協議轉換能力。

實際上對於ESB總線來說本身就是支持Http Rest接口服務得註冊和接入的。因此對ESB服務總線和API網關引擎存在兩種思路可以選擇。

其一兩套獨立的引擎，然後在管控治理和服務運營開放層面整合為一套，即上圖。
其二對已有的ESB服務總線產品進一步升級，加強對Http API接口的支撐和管控。

對於第二種方式相對來說並不會很複雜，也容易實施，即通過對ESB服務總線的升級來完成對ESB總線+API網關兩方面能力的完全支撐。你可以說賣的是ESB服務總線，但是完全兼容適配API網關所有能力。

基於上面這個思路，我們需要做的主要包括

安全能力增強：包括Basic安全，Auth2.0，Token動態令牌，Https支持等方面能力。
限流熔斷能力：包括完整的限流熔斷能力提升，而且能夠控制到細粒度的單個服務。
對於Http Rest接口服務註冊能力增強，同時增加簡單的數據映射能力支持。
對API標準規範，設計，服務契約，幫助，swagger集成等方面能力增強。
API在線測試和自動化測試能力增強
對於Http Rest API和傳統的WS接口服務互轉能力的增強

基於以上關鍵點進行進一步的優化和完善後，即能夠為企業提供一套完整的SOA服務總線產品，同時支撐傳統的ESB服務總線能力，又對Http Rest API接口的接入，註冊和管控方面能力得到全面增強。

ESB總線和API網關兩級集成

在前面我就談到，傳統企業在進行微服務架構轉型過程中，是一個逐步遷移和改造的過程，因此往往存在新微服務架構採用API網關，遺留系統集成仍然是ESB服務總線的業務集成場景。

那麼在這種集成場景下，就存在ESB服務總線和API網關兩級集成和協同的場景。

我們以一個集成場景來進行說明，即企業遺留系統集成採用ESB服務總線，而對於新建設的一個微服務應用採用API網關，那麼就存在兩者協同和集成的過程，整體集成架構如下：

可以看到，在這種集成架構下，微服務整體應用系統中所有的需要和遺留系統交互的接口全部首先接入和註冊到API網關，同時API網關暴露的服務進一步集成和註冊到ESB服務總線，形成兩級服務集成的方式。

在這種兩級服務集成模式下好處包括

微服務應用體系裏面的各個微服務僅僅需要暴露特定的API接口到網關和ESB
內部微服務間的Rest API交互仍然可以走註冊中心，而且對外透明
可以進一步使用ESB總線協議轉換和適配能力，完成SOAP和Rest接口轉換和適配

雖然兩級集成模式下增加了一定的性能損耗，也拉長了整個服務調用鏈路。但是在新舊架構並存的過程中，這種兩級集成仍然是我們推薦採用的方式。既滿足了微服務應用內部的微服務治理要求，又實現了和外圍系統間的集成。

如果站在微服務應用角度來看，那麼我們完全可以將外部遺留系統都作為對微服務通過API網關暴露的接口的消費方，不同點僅僅在於這些對API網關發起的消費都統一通過ESB服務總線進行了路由和中轉。

通過ESB總線代理的作用一方面是實現對所有接口的管控治理，另外一個重點就是解決老接口協議調用方式和新接口之間的適配和轉換問題，如下圖：

我們可以舉例來進一步說明。

在傳統遺留集成架構中，全部採用SOAP WS進行服務集成，接口全部註冊接入到ESB總線。對於遺留系統A我們進行微服務改造和微服務化，那麼遺留系統A原來暴露的SOAP WS接口，在進行微服務改造後全部採用標註的Http Rest API接口。

但是原來的遺留系統B，或C並不希望由於A的微服務化改造而導致原來對SOAP WS接口服務的消費端進行全部改造並增加工作量。那麼這個時候就存在通過ESB總線進行適配問題。

場景一：遺留系統訪問微服務提供的接口

微服務模塊提供Http Rest接口並註冊接入到API網關。
ESB服務總線適配API網關的Http Rest接口並將其暴露為SOAP WS接口。
對於遺留系統仍然消費和原來已有的SOAP接口，因此無須改造

場景二：微服務需要訪問ESB總線提供的SOAP接口

注意在這種場景下，API網關往往並不具備對SOAP服務進行接入和適配的能力，因此在這種場景下，具體的協議轉換和適配仍然需要ESB總線完成。

ESB總線對遺留系統提供的SOAP接口進行適配，發佈為Http Rest接口
ESB總線實際對遺留系統SOAP同時發佈SOAP和Http Rest兩個服務
API網關將ESB總線提供的Http Rest接口註冊和接入
微服務模塊訪問API網關提供的Http Rest接口服務

實際上我們看到，在微服務集成場景下，對ESB發佈的Rest接口並不一定要接入API網關，對於微服務模塊可以直接訪問ESB總線提供的接口服務。但是在這種場景下，每個微服務對於ESB總線來說都是一個獨立的接入系統，需要在ESB總線進行管理。

基於API網關構建微服務集成技術中台

在上面這個場景可以看到，一個傳統的應用遷移到微服務架構，就形成一個微服務應用體系，在這個微服務應用裏面就存在API網關，服務註冊中心，配置中心等微服務治理管控組件。那麼當多個傳統遺留系統都逐步轉移到微服務的時候，如果同時存在多個各自為政的API網關，配置中心，註冊中心等顯然是不合適的，這個也不方面後續進行微服務架構治理。

在這種場景下，我們希望是各個微服務模塊盡量存粹，而將微服務治理能力平台化，即將網關，註冊中心，配置中心，限流熔斷能能力全部整合到技術中台中統一提供，而不是各個微服務體系單獨一套。在這種整合後整個架構更加清晰，如下：