ESB服務總線核心架構
SOA團隊 2020-03-16
根據近期對開源ESB產品的研究，已經對Oracle和Tibco的ESB總線產品的實施經驗積累，對ESB總線的核心產品架構有了進一步的清晰認識，將ESB的核心架構整理為上圖，上圖中看到的內容也是做為一款完整的ESB服務總線產品所必須要具備的功能。
首先整個架構體系里面分為三個組件或子系統，即偏開發態的設計器，偏運行態的ESB核心引擎和SOA治理管控平臺三個方面的內容。以上三者組合和集成形成一款完整的ESB服務總線產品。對于三者之間的關系可以簡單的描述為：
首先對于ESB總線引擎是一個完全相對獨立的內容，即常說的ESB的Server端，一個完整的ESB引擎一般都會集成消息中間件的能力。類似ServiceMix的ESB可以看到核心是基于OSGI運行框架下的ActiveMQ+CXF組件來實現基礎核心功能。沒有設計器和管控平臺，引擎也可以獨立部署和運行，即可以自己寫代碼或寫配置文件，將開發好的服務包部署到ESB引擎環境里面。
一個ESB引擎本身也需要部署在application server里面，即引擎可以部署在類似weblogic,jboss或tomcat等各種中間件容器中。而對于很多開源的ESB可以看到引擎本身已經集成了更加輕量的Jetty做為服務運行容器。其次對于單獨的引擎應該是不需要DB數據庫的，即ESB服務運行的log日志審計可以存儲在服務端的log日志文件中，只有當安裝了管控平臺后，我們可以在server上部署代理，準實時的將運行日志信息采集和存儲或db數據庫。
其次是ESB設計器，設計器是屬于開發和設計態的一個內容，重點則是對http，rest，已經服務+DB，消息等各種內容進行集成。當前類似talend和mule等都提供了很強大的服務設計器能力。即我們常說的服務代理，http和soap服務集成，數據庫適配，路由，消息集成和適配，分支和條件判斷，異常處理，任務作業，組合服務等都是設計器需要支撐的核心能力。
設計器設計完成后的內容可以導出為部署包，對于部署包則可以部署到ESB服務引擎中。當前的做法主要有兩種，一種是在設計器中本身就提供連接到服務器進行遠程和自動部署的能力，另外一種做法則是在SOA管控平臺里面提供服務部署和管控的能力。
設計器往往是給服務開發和設計人員使用，目的是為了簡化服務的開發和封裝，提升開發效率，一個開放的架構模式最好的方式就是脫離了設計器仍然可以通過其他手工方式進行服務的開發和封裝，而不是被設計器綁定。而對于設計器本身的輸出，一種是轉化為了普通的java代碼，還有一種方式是設計器的輸出為xml配置文件?？梢钥吹綄τ趚ml配置文件這種方式更加方便和解耦，在設計器產生部署包或測試運行的時候，設計器端首先是讀取xml配置文件的內容再動態生成和部署服務。
最后一個內容是SOA管控平臺，主要的作用是實現服務的全生命周期管理，包括服務的元數據管理，服務目錄庫，服務的申請，服務的開通和鑒權，服務運行日志審計和監控，服務運行分析，服務預警，服務SLA等各種功能。即SOA管控平臺提升了對ESB引擎本身的管控和治理能力。
管控平臺本身也是相對獨立的內容，可以看到對于管控平臺和ESB引擎本身是徹底解耦的，即如果實施了管控平臺，則只需要在ESB引擎上啟動管控代理和相關的配置參數，在這種模式下ESB引擎本身運行態的運行信息即可以準實時的采集到管控平臺中進行存儲和統計分析。
當然，對于管控平臺產品的服務權限管控，服務動態路由設置，服務流量控制等內容，也會影響到ESB引擎在運行態的運行。而通常ESB總線的做法則是對于log日志，安全，流量控制等都是ESB總線的inbound和outbound上的可插拔式的攔截器，通過這種組件動態裝載和配置啟用的模式來徹底實現管控平臺和ESB引擎的解耦。
對于ESB總線產品本身也應該是符合SOA架構的，即需要實現組件化和服務化，實現服務組件本身的動態加載和熱部署，當前類似servicemix在這點上的做法是值得借鑒的，即基于karaf+osgi模式來實現一個組件化的運行框架和環境，極大的方便后了整個運行態的動態管控能力。
遠行科技
遠行云商
