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

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

API網(wǎng)關(guān)概述

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

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

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

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

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

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

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

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

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

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

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

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

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

2.消息中間件能力

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

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

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

4.路由能力

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

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

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

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

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

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

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

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

消息中間件集成和適配

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

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

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

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

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

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

對于SOAP WS接口服務(wù)的支持

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

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

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

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

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

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

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

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

初步思考總結(jié)

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