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

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

API網(wǎng)關概述

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

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

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

如何給API網(wǎng)關一個定義?

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

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

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

• 大量適配器實現(xiàn)對遺留系統(tǒng)的遺留接口適配，多協(xié)議轉換能力
• 進行數(shù)據(jù)的復制映射，路由等能力

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

API網(wǎng)關相比ESB欠缺能力分析

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

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

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

2.消息中間件能力

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

3.各種適配和協(xié)議轉換能力

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

4.路由能力

對于路由能力來說，API網(wǎng)關一般會提供簡單的路由能力，比如通過Url里面?zhèn)鬟f的關鍵參數(shù)進行路由，但是無法支撐基于消息報文里面的內容進行路由。

API網(wǎng)關替代ESB的可行性分析

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

對于API網(wǎng)關對ESB的替換個人核心觀點如下：

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

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

數(shù)據(jù)庫適配和協(xié)議轉換能力

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

消息中間件集成和適配

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

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

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

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

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

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

對于SOAP WS接口服務的支持

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

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

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

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

基于內容動態(tài)路由支持

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

實際這些在API網(wǎng)關當前并不支持。

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

初步思考總結

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