1. 首頁 > 生活 > >

api網關架構 常用于api網關

小知識常用于api網關api網關架構



文章插圖
api網關架構 常用于api網關

文章插圖
今天準備談下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網關，配置中心，注冊中心等顯然是不合適的，這個也不方面后續進行微服務架構治理 。
在這種場景下，我們希望是各個微服務模塊盡量存粹，而將微服務治理能力平臺化，即將網關，注冊中心，配置中心，限流熔斷能能力全部整合到技術中臺中統一提供，而不是各個微服務體系單獨一套 。在這種整合后整個架構更加清晰，如下：
基于這個思路，遺留系統逐步遷移和消亡，那么ESB總線也準備消亡被API網關或微服務治理平臺代替 。在整個過程中，我們可以逐步提升API網關的協議轉換適配能力，以加快對ESB總線的替代操作 。
對API網關接口適配能力提升
最后談下API網關如何提升接口適配能力 。
API網關提供的接口適配，雖然不會像ESB服務總線那樣提供各種復雜的適配器，但是一些經常會使用到的適配能力還是需要提供，以方便實現API接口的快速開發和接入能力 。
最常見的-Http Rest API接口服務的代理接入能力
對于Http Rest API接口服務接入是API網關提供最常見的接口服務接入和適配能力，這里面一種是存代理方式接入或透傳，一種是在接入過程中還需要進行適度的數據裁剪和數據豐富 。不論是哪種接入，都可能存在在接入過程中增加API網關標準管控所需要的類似SysID，Token等信息 。
DB數據庫的適配接入
即當前一些API網關會提供的，可以將DB數據庫表快速的發布為Rest接口服務，常見的包括了數據庫表對象的CRUD主流操作 。同時我們看到，完全可以實現一個通用的Http Rest接口服務，對所有的數據庫表實現類似的操作能力，但是本身也存在安全管控的風險 。
第二種是提供一個類似Sql模糊查詢的關聯查詢接口服務接入能力，即模糊動態查詢條件，對于查詢結果可能是后臺多個表的關聯查詢，對于具體的查詢Sql由用戶自己定義 。
第三種也是經常會遇到的就是，對于復雜業務對象直接發布為Rest接口服務，一個復雜業務對象實際是后臺數據庫多張數據庫表構成，表之間可以是一種層次結構，也可能是一種關聯結構 。對于這種方式，當前一般的API網關實際上并不支持，但是實際是經常會遇到的一個DB數據庫快速接入和適配的場景 。
遺留SOAP-WS接口自動轉換為Http Rest接口
對于遺留的SOAP WS服務接口，應該提供快速的服務適配和接入能力，即將SOAP接口自動轉換為一個Rest API接口服務接入，同時將消息報文結構由XML轉換為XML或Json數據結構 。
服務編排和組合服務接入
這個是主流的API網關也會通過的服務注冊接入能力，即將已有的多個API服務接口進行服務組合和組裝，變成一個組合服務再發布出去，在這個過程中完成多個服務的整合和數據映射，這個在前面多篇文章里面都談到了服務編排的關鍵點 。
對于服務編排和組合接入，一般還是需要提供可視化的服務編排設計器來完成服務編排接入 。服務編排的場景即場景的服務串聯，服務組合，服務合并和拆分 。
消息中間件的消息接口發布為Http Rest接口
【api網關架構 常用于api網關】這個也是API網關應該提供的一個API接口服務快速發布的能力，即將已有的消息中間件的消息接口快速發布為一個Http Rest接口服務 。即調用API接口將數據寫入到消息中間件而不是數據庫，對于消息的訂閱則仍然可以走傳統的JMS消息訂閱接口進行 。