ESB總線的核心架構

根據近期對開源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配置文件。能夠看到對於xml配置文件這種方式更加方便和解耦，在設計器產生部署包或測試運行的時候，設計器端首先是讀取xml配置文件的內容再動態生成和部署服務。

最後一個內容是SOA管控平臺，主要的做用是實現服務的全生命週期管理，包括服務的元數據管理，服務目錄庫，服務的申請，服務的開通和鑑權，服務運行日誌審計和監控，服務運行分析，服務預警，服務SLA等各類功能。即SOA管控平臺提高了對ESB引擎自己的管控和治理能力。

管控平臺自己也是相對獨立的內容，能夠看到對於管控平臺和ESB引擎自己是完全解耦的，即若是實施了管控平臺，則只須要在ESB引擎上啓動管控代理和相關的配置參數，在這種模式下ESB引擎自己運行態的運行信息便可以準實時的採集到管控平臺中進行存儲和統計分析。

固然，對於管控平臺產品的服務權限管控，服務動態路由設置，服務流量控制等內容，也會影響到ESB引擎在運行態的運行。而一般ESB總線的作法則是對於log日誌，安全，流量控制等都是ESB總線的inbound和outbound上的可插拔式的攔截器，經過這種組件動態裝載和配置啓用的模式來完全實現管控平臺和ESB引擎的解耦。

對於ESB總線產品自己也應該是符合SOA架構的，即須要實現組件化和服務化，實現服務組件自己的動態加載和熱部署，當前相似servicemix在這點上的作法是值得借鑑的，即基於karaf+osgi模式來實現一個組件化的運行框架和環境，極大的方便後了整個運行態的動態管控能力。