本文主要是對ESB的總結，下面我將從以下幾點去理清ESB相關知識點，

• 什么是ESB
• ESB解決了什么問題以及什么是HSB
• ESB產品有哪些？如何選擇
• 如何實作ESB的各個功能
• ESB與微服務的區別

一、什么是ESB

ESB是Enterprise Service Bus的簡稱，中文翻譯為企業服務總線，企業服務總線是一個實作系統間集成和互聯互通的重要技術架構，可以理解為是一種訊息和服務集成的中間件平臺，

二、ESB解決了什么問題以及什么是HSB

圖片摘自網路，侵刪

ESB主要是為了解決多個應用系統互聯所面臨的的復雜性，減低集成和維護成本，舉個例子，比如我們的醫療業務系統都知道分為很多個系統，包括HIS、LIS、EMR等等，如果這些業務系統是由多個商家做的，可能會有構建語言不同、通信協議不同、資料傳輸格式不同等問題，那么如何把這些系統用一條線串起來呢？就是用ESB；還有我們醫療從業者、患者、管理人員等可以通過多個渠道訪問后臺系統，比如瀏覽器的portal,移動設備等；還有一些特殊的醫療業務應用系統，比如雙向會診、遠程會診、業務協同等等，即實作了ESB的基本特點，又滿足醫療衛生行業的特定需求的ESB，叫做健康服務總線（Health Service Bus，HSB），ESB為了解決剛才說的問題，就需要保證多個應用系統的服務接入，協議轉換，提供可靠的訊息傳輸，資料格式轉換，基于內容路由等功能，有人可能會有疑問，應用A發送訊息給ESB，ESB再將訊息轉換給應用B，那么應用A直接通過SOAP協議發送給B，效率不是應該更高嗎？而且如果這些IT系統都在一個網路中，提供的WebService都在統一命名空間下，就可以相互通信，為什么還要加上這一層？有兩點需要考慮，第一點，點對點做服務的時候，通常需要考慮日志記錄，服務訪問安全、傳輸安全、資料安全、路由分發等一系列問題，而這些完全可以統一管理，統一驗證，靈活配置，；如果應用A呼叫了應用B，在呼叫了應用C等具有邏輯流程的呼叫時，還可以在ESB上實作流程引擎；第二點，ESB是一個中間件平臺，包含了訊息中間件的全部功能，有異步訊息處理機制，可以實作業務系統之間真正的松耦合的結構，

三、市面上 ESB產品有哪些？如何選擇

一．CXFCXF的定位不是ESB總線，而是一個服務框架（Service Framework），主要還是為關于服務的應用提供API上的支持，或者背景關系上的管理，可是它的前身之中的一個的Celtix就是IONA公司捐獻給開源界的ESB總線，所以總體上還是能提供ESB總線的功能（需依靠與其他的容器），在CXF中的總線僅僅是起到一個共享資源的提供者的作用，這些貢獻資源就相當于JBI規范中的系結組件（BC）或服務引擎（SE），即使如此CXF并沒有提供了對JBI規范的完整實作，能夠說它僅僅是一個相似的JBI容器，CXF支持與除了HTTP之外的其他協議的通信系結，比如REST、JSON和CORBA等，所以對于Ajax有較強的兼容性，這相對與其他的ESB總線而言能夠說是一個較大的優勢，可是CXF的ESB總線是根據Spring框架來實作的，由Spring來管理Bus中的各個組件，而Spring對各個Bean或組件的管理是通過一個背景關系的組態檔來實作的，這種方式相對與其它的ESB總線（比如根據JMX）的方式而言，則不支持動態的熱部署，也就是說CXF不是一個JBI容器，它必須依附與其它的容器來執行，現有的資料來看，CXF眼下能夠部署在JBoss和BEA Weblogic中，Tomcatserver因為不支持完整的J2EE規范，特別是基于JCA的EJB，所以對CXF支持的程度不理想，盡管資料中沒有涉及到Geronimo，可是以Geronimo對J2EE規范的兼容程度來看，特別是EAR檔案的支持，在Geronimo中部署CXF應該沒有什么太大的障礙，相同你能夠在使用Spring的應用中嵌入CXF，而這僅僅須要在Spring的組態檔里填寫對應的配置資訊就可以，關于CXF的檔案較為豐富，這部分是因為它本身是整合了Xfire和Celtix這兩個本身較為成熟的開源專案，另外它較大的依賴于Spring框架，所以假設對Spring較為熟悉的話，在使用上一般就沒有太大的障礙了，

二．Open ESBOpenESB是Sun公司提出來的開源ESB專案，所以對JBI規范的支持程度就不用多說了，而GlassFish ESB則是將OpenESB的核心執行環境與GlassFish應用server以及NetBean的集成開發環境整合在一起的有一個ESB專案，當然當中還包括了一些OpenESB中已有的組件（子集），在OpenESB中提供了可以支持WS-BPEL2.0的引擎，可是如今這個組件支持WSDL1.1，暫不支持WSDL2.0，并且這個引擎要依托與NetBean集成開發平臺，起碼僅僅能得到基于NetBean的對應開發包和組件包，可是這個組件對BPEL提供了強大的支持，當中包含支持端點狀態的監控、支持多執行緒運行、業務流程的除錯、系統錯誤的可靠性恢復中各個業務流程實體的資料庫持久化以及負載均衡等，在資料方面僅僅有一個演示視頻，主要還是基于NetBean平臺的使用介紹，其它發布的資料則則較少，特別是API方面差點兒沒有，所以假設要對OpenESB進行依照自身的要求進行擴展則較為困難，除非對OpenESB的原始碼進行全面的分析，

三．ServiceMixServiceMix是Apache基金會下的一個ESB總線，同一時候也是一個獨立的JBI容器（也就是說它支持完整的JBI規范），說它是一個獨立的JBI容器，是由于它擁有自己獨立的執行環境，能像應用server一樣啟動，并支持動態的熱部署等，這一點則差別于CXF，ServiceMix的容器執行環境採用內核的架構，并以Geronimo關于J2EE方面的實作為基礎（當然也就支持J2EE的各方面規范，比如安全性方面的JAAS等），所以在性能上還是較為出色的，在通信上，整合了ActiveMQ，也支持多種的通信協議，比如HTTP和JMS，同一時候在管理組件上採用了JMX的管理架構，從而可以對部署在總線上的各種組件進行動態的配置和管理，或通過Web的形式，或通過JMX遠程訪問均可，ServiceMix內核可以整合到所處的作業系統中，從而作為OS的對外提供的服務，差別與其它總線的是，ServiceMix還提供了自己的腳本命令控制臺，并通過一些簡單命令來管理應用組件以及ServiceMix內核實體，關于ServiceMix的資料也較為的完備，當中當然也包含一些簡單的小樣例，關于組件擴展方面和流程引擎整合方面的具體資料則不夠具體，假設要做進一步的總線上的擴展，則須要對原始碼和樣例進行較為深入的學習和研究，當然這一切的基礎是對JBI的規范有較為全面的了解，

四．JBoss ESBJBoss ESB是JBoss社區為面向SOA而提出的一個EAI系統平臺，它提供了非常多EAI本身所應具有的功能，比如業務流程監控、集成開發環境、作業流用戶介面、業務流程管理、分布式計算架構以及作為應用容器的功能等，能夠說JBossESB在功能上是較為強大的，但相對于上面的總線而言，它的技術架構方案是最獨立的，由于它除了支持J2EE標準外，對于JBI規范壓根就不沾邊，當然也就不存在JBI規范中的規范化訊息路由、服務引擎和系結組件了，JBossESB除了支持 Web Service外，還支持多種的遠程呼叫協議，比如JMS，僅僅是相對于ServiceMix和CXF而言，假設要對JBossESB進行擴展，可能要花費較大的時間和精力，JBossESB相對上述的開源專案而言，一個非常大的優勢在于檔案資料是最為豐富和完備的，所以在開發和擴展上減小了不小的阻力，它而且依托于成熟的JBoss社區，周圍齊全的開源專案支持，為后期的平臺擴展提供了豐富的選擇空間，

四、 如何實作ESB的各個功能

1.ESB的服務接入方式？

• RPC 遠程程序呼叫（面向方法）
• SOAP 面向服務的架構（面向訊息）
• REST 資源的狀態轉變（面向資源）目前我們公司使用的HSF實際上就是RPC，還是JSON-RPC，RPC的另一種實作還有XML-RPC，通訊方式相同，采用呼叫本地服務（方法）一樣的呼叫服務器的服務（方式）的方式，只不過傳輸資料格式不同，JSON格式更加高效，XML-RPC實際上就是這三種方式的最早通信方式，基于HTTP傳輸協議+XML引數封裝，一個XML-RPC訊息就是一個請求體為xml的htpp-post的請求，服務端執行了之后也以XML格式的編碼回傳，后來這個標準演化成了SOAP，可以理解為SOAP是XML-RPC 的高級版本；SOAP，簡單物件訪問協議，是一種輕量的、簡單的、基于xml的遠程訪問協議，可以實作多種傳輸層或應用層協議結合使用，如TCP/HTTP/SMTP等,實際上應用最廣泛的還是基于HTTP+XML的實作，相對于XML-RPC，SOAP更好的利用了XML，有相應的服務描述語言，也是一段XML,也就是WSDL(Web Services Description Language),專門用來描述怎么訪問web服務，描述了哪些細節呢？一般包含4點，用于訪問服務的地址資訊，用于傳輸資訊的傳輸協議（比如通道數），用于所有可使用功能的名稱和介面方法，在所有的請求和回應中所使用的資料型別，具體什么格式，這里不再展開，有興趣可以查看一下以下鏈接：WebService之WSDL檔案講解最后說REST，非協議非規范，只是一種約束、概念或者開發方式，簡單的說就是，用HTTP動詞（GET,POST,DELETE,DETC）描述操作，表示資源的轉換，滿足REST的約束叫RESTful結構，其實目前公司的并不是RESTful風格，近年來的REST被炒得很火，但不是所有情況都是適合的，REST目前都是基于HTTP/HTTPS，而SOAP可以支持很多傳輸協議，從HTTP/HTTPS到SMTP（Simple Mail Transfer Protocol，簡單郵件傳送協議），甚至JMS（Java Messaging Service，Java訊息傳遞服務），而SOAP已經是一個工業標準，它具備良好定義的協議，以及一套良好確立的規則，在大型和小型系統中均有采用，

2.ESB的如何進行協議轉換？

現在使用的ESB協議轉換基本上使用的ESB產品，實作基本上二進制進行轉換；具體的可以找相應的產品的，比如 WSO2d產品的實作：WSO2 ——（7）ESB功能：協議轉換目前有一些問題需要再調查一下，cxf3.1目前也只支持wsdl1.1，axis2的最新版也不支持wsdl2.0，需要繼續查詢資料如何轉換；有些企業再做介面對接的時候可能只提供wsdl,需要自己根據wsdl生成服務端提供服務給他們，可以利用soapUI實作，有些企業只支持wsdl1.0，我們要實作自己的ESB就要提供wsdl1.0與wsdl2.0版，

3.資料轉換

• 在應用間交換不同格式的資訊
• 操作訊息的負載內容，包括加密、壓縮和編碼轉換
• 在異構的傳輸協議的資料型別間格式化訊息此程序也是依賴工具比如Mule可以用Transformer 進行轉換，比如將JMS格式message轉化為其他型別的資料，JDBC Transformer可以將CSV或xml檔案中的資料轉移到資料庫中等等操作

4. 訊息路由

• 基于訊息內容和復雜規則路由訊息
• 訊息的過濾、聚合以及重新排列序號此程序也是依賴工具比如Mule可以用case when 等邏輯判斷，根據訊息中指定的訊息將訊息發送到不同的服務端進行處理，

5. 其他功能

ESB當然還有其他功能，這里不再介紹，基本上各個ESB工具已經封裝好，可根據ESB工具自己拓展和呼叫，這里給出其他功能介紹的鏈接 java系統間通信ESB，

原文鏈接： https://www.jianshu.com/p/10ec5b86296f