大家都清楚傳統的IT架構和集成一般都采用ESB服務總線進行集成，這是一種典型的中心化架構，但是可以充分的利用ESB總線的適配，協議轉換，消息攔截等能力進行各種SOA治理和管控操作。

那么在傳統企業IT架構轉型過程中，如果需要對ESB總線進行升級改造，或者說整體IT架構本身就存在老架構和新微服務架構共存的一個集成場景。那么在這種情況下還按傳統方式去升級ESB總線顯然不合適，最佳的方法應該是去考慮是否能夠用API網關替代ESB總線。

API網關概述

在微服務架構體系里面，我們一般會使用到微服務網關或叫API網關。

大家都比較清楚，在微服務架構體系下本身是去中心化的架構，通過服務注冊中心來實現服務注冊發現和消費調用，那么為何又需要使用API網關?

在傳統的ESB總線進行服務集成的時候我們就經常談到一個概念就是位置透明，即需要屏蔽底層業務模塊提供API接口服務地址信息，并實現多個微服務API接口的統一出口。即類似設計模式里面經常談到的門面模式。

如何給API網關一個定義?

簡單來說API網關就是將所有的微服務提供的API接口服務能力全部匯聚進來，統一接入進行管理，也正是通過統一攔截，就可以通過網關實現對API接口的安全，日志，限流熔斷等共性需求。如果再簡單說下，通過網關實現了幾個關鍵能力。

• 內部的微服務對外部訪問來說位置透明，外部應用只需和網關交互
• 統一攔截接口服務，實現安全，日志，限流熔斷等需求

從這里，我們就可以看到API網關和傳統架構里面的ESB總線是類似的，這些關鍵能力本身也是ESB服務總線的能力，但是ESB服務總線由于要考慮遺留系統的接入，因此增加了：

• 大量適配器實現對遺留系統的遺留接口適配，多協議轉換能力
• 進行數據的復制映射，路由等能力

對于兩者，我原來做過一個簡單的對比，大家可以參考。

API網關相比ESB欠缺能力分析

基于上面的對比基本可以看到API網關類似一個輕量的只支持Http Rest API接口的總線，其它類似ESB總線比較重的協議轉換，數據映射，輕量服務編排等能力都不再具備或提供。當考慮用API網關對ESB進行替代的時候，欠缺的能力包括。

1.SOAP WS的支持和集成能力

注意API網關是不支持對傳統的SOAP WS接口是進行適配和接入的。如果要接入，那么只能是純粹的Http服務代理模式進行接入，而對于消息報文等XML格式無法進行處理和解析。當無法對消息報文進行解析的時候，對這類WS服務要進行相應的管控也很難做到。

2.消息中間件能力

對于API網關底層一般并沒有一個消息中間件，那么對于消息集成，類似JMS消息的適配能力自然也沒有。API網關接口服務更多都是同步服務調用模式，類似原有的異步消息集成，消息一對多分發等場景在API網關本身無法實現。

3.各種適配和協議轉換能力

這個本身也不是API網關的強項，一般的API網關產品也不會去做這塊內容。類似DB數據庫的適配，文件適配，消息適配，TCP，SOAP和Rest API接口間的協議轉換等都無法提供。對于數據映射部分API網關產品會通過數據映射插件進行簡單的數據映射能力。

4.路由能力

對于路由能力來說，API網關一般會提供簡單的路由能力，比如通過Url里面傳遞的關鍵參數進行路由，但是無法支撐基于消息報文里面的內容進行路由。

API網關替代ESB的可行性分析

API網關替代ESB，簡單來說就是需要在API網關上擴展欠缺的能力，這樣原有注冊在ESB總線上的接口服務才能夠做到平滑遷移。

對于API網關對ESB的替換個人核心觀點如下：

即不對API網關引擎本身進行大量的代碼定制，而是應該將欠缺的能力作為代理組件或插件方式實現并最終和API網關融合為一個整體。

基于這個思路進行分析如下。

數據庫適配和協議轉換能力

對于這部分能力，最佳做法即是將其移出到API快速開發平臺或組件里面，即在該組件里面完成對數據庫的適配，協議轉換等動作，最終形成一個Http Rest API接口再注冊和接入到API網關。也就是說API快速開發平臺即是API網關的一個關鍵外掛。

消息中間件集成和適配

在傳統的SOAP WS接口服務實施里面，我們做了一個關鍵的事情。

即JMS消息集成將其分解為兩步，對于JMS消息的發送能力，通過JMS消息適配最終轉換為一個SOAP WS接口服務。該接口服務在獲取到消息后再將消息寫入到消息中間件。

但是對于消息的訂閱，由于要保留消息中間本身的消息持久化，一致性，重視，消息1對多發布訂閱能力，我們仍然保留了傳統的JMS消息訂閱機制。但是這種機制本身會走TCP協議接口，在訂閱端也存在要安裝相應的消息中間件代理SDK包。整體來說還是存在一定的耦合性，特別是消息中間件一些能力要進行變更的時候，往往涉及到訂閱端也需要修改。

在API網關集成下，引入一個開源的消息中間件來彌補異步消息集成是必須的。對應消息中間件介紹可以參考我以前發布過的相關文章。

在消息中間件引入后，可以將消息發布能力封裝適配后形成一個Http Rest API接口暴露。但是對于訂閱能力，個人希望是不再通過消息中間件本身的訂閱機制。

而是在各個訂閱端提供Http Rest API的導入數據接口服務，由代理組件來完成消息的發布和定義工作。也就是說不再是訂閱端去監聽消息的變化，而是代理組件在獲取到數據后根據消息訂閱情況主動分發。

對于SOAP WS接口服務的支持

由于當前API網關基本都是基于Http Rest API接口注冊接入進行設計，因此對傳統的SOAP WS接口服務的支持能力很弱。

個人想法是實現一個單獨的代理和轉換組件來進行SOAP WS的處理，在這個組件里面可以將SOAP WS接口轉換為Http Rest API接口服務。也可以對SOAP WS進行新的數據攔截和報文解析，并進行相應的安全訪問控制，路由格式轉換等操作。

當然對于SOAP WS接口服務本身也不是必須轉換為Http Rest 接口再注冊到API網關。這類遺留服務可以直接接入到API網關，但是本質是一種代理透傳的模式。在這種模式下，所有管控能力，轉換能力，路由能力等都需要外掛插件來解決。

那么外掛插件基本實現了一個小型的ESB總線該有的能力，如何保證外掛插件本身的可靠性和性能本身又成為一個關鍵問題。

基于內容動態路由支持

API網關可以根據Url地址參數信息進行簡單路由，但是基于內容的動態路由實際支撐得并不好。在傳統ESB總線實施中，我們可以根據消息頭，根據輸入消息報文內容中關鍵字段信息進行動態路由，包括在路由處理前還進行相關的安全訪問和權限判斷。

實際這些在API網關當前并不支持。

前面已經提到一種做法即在接口服務消費前進行代理組件攔截，還有一種做法則是單獨在開發一個路由服務，在該服務里面來實現動態基于內容的路由能力。

初步思考總結

如果僅僅是SOAP和Rest接口轉換，數據庫適配，代理路由等替換，采用API網關+插件方式完全可以實現。但是如果對于SOAP WS服務注冊接入，安全管控完整能力的實現，要在API網關上面進行定制和調整，其工作量不小于單獨實現一個小的SOAP WS服務集成的ESB總線能力，這個實際還需要進一步論證實現的可行性。