一.什么是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都在統一命名空間下，就可以相互通信，為什么還要加上這一層？有兩點需要考慮。
（1）點對點做服務的時候，通常需要考慮日志記錄，服務訪問安全、傳輸安全、數據安全、路由分發等一系列問題，而這些完全可以統一管理，統一驗證，靈活配置；
如果應用A調用了應用B，在調用了應用C等具有邏輯流程的調用時，還可以在ESB上實現流程引擎；
（2）ESB是一個中間件平台，包含了消息中間件的全部功能，有異步消息處理機制，可以實現業務系統之間真正的松耦合的結構。
三.如何實現ESB的各個功能
1、ESB的服務接入方式？
（1）RPC 遠程過程調用（面向方法）
目前公司使用的HSF實際上就是RPC，還是JSON-RPC，RPC的另一種實現還有XML-RPC，通訊方式相同，采
用調用本地服務（方法）一樣的調用服務器的服務（方式）的方式，只不過傳輸數據格式不同，JSON格式更加高效。
XML-RPC實際上就是這三種方式的最早通信方式，基於HTTP傳輸協議+XML參數封裝，一個XML-RPC消息就是一個請求體為xml的htpp-post的請求，
服務端執行了之后也以XML格式的編碼返回，后來這個標准演化成了SOAP，可以理解為SOAP是XML-RPC 的高級版本；
（2）SOAP 面向服務的架構（面向消息）
SOAP，簡單對象訪問協議，是一種輕量的、簡單的、基於xml的遠程訪問協議，可以實現多種傳輸層或應用層協議結合使用，
如TCP/HTTP/SMTP等,實際上應用最廣泛的還是基於HTTP+XML的實現，相對於XML-RPC，SOAP更好的利用了XML，
有相應的服務描述語言，也是一段XML，也就是WSDL(Web Services Description Language)，專門用來描述怎么訪問web服務，描述了哪些細節呢？
一般包含4點，用於訪問服務的地址信息，用於傳輸信息的傳輸協議（比如通道數），用於所有可使用功能的名稱和接口方法，
在所有的請求和響應中所使用的數據類型，具體什么格式，這里不再展開。
（3）REST 資源的狀態轉變（面向資源）
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、數據轉換
（1）在應用間交換不同格式的信息；
（2）操作消息的負載內容，包括加密、壓縮和編碼轉換；
（3）在異構的傳輸協議的數據類型間格式化消息；
此過程也是依賴工具比如Mule可以用Transformer 進行轉換，比如將JMS格式message轉化為其他類型的數據，JDBC Transformer可以將CSV或xml文件中的數據轉移到數據庫中等等操作。
4、消息路由
（1）基於消息內容和復雜規則路由消息；
（2）消息的過濾、聚合以及重新排列序號；
此過程也是依賴工具比如Mule可以用case when 等邏輯判斷，根據消息中指定的消息將消息發送到不同的服務端進行處理。
5、ESB總線和微服務通信區別
ESB的主要應用場景是集成，特別是對無法改變的異構系統做適配整合，比如遺留系統，外部系統。
在邏輯上和運行時都是集中的。邏輯上會有集中的高層視野，有利於可管理性，也就是便於治理。
但也有集中的復雜性特別是演進時的節奏糾纏，需要想辦法應對。運行時的集中則有比較大的容量和可用性風險。
微服務的通訊一般是自治的，在運行時是分散的，容量和可用性風險可以分散應對。邏輯上也是分散的，這一點有好處也有壞處，分散復雜性的同時也失去了統一視野。
折中的辦法是建立服務治理中心，作為邏輯中心，采用事后模式的治理演進風格。