本文主要是對ESB的總結剥汤，下面我將從以下幾點去理清ESB相關知識點颠放。
- 什么是ESB
- ESB解決了什么問題以及什么是HSB
- ESB產品有哪些？如何選擇
- 如何實現(xiàn)ESB的各個功能
- ESB與微服務的區(qū)別
一吭敢、什么是ESB
ESB是Enterprise Service Bus的簡稱慈迈，中文翻譯為企業(yè)服務總線，企業(yè)服務總線是一個實現(xiàn)系統(tǒng)間集成和互聯(lián)互通的重要技術架構省有，可以理解為是一種消息和服務集成的中間件平臺痒留。
二、ESB解決了什么問題以及什么是HSB
ESB主要是為了解決多個應用系統(tǒng)互聯(lián)所面臨的的復雜性伸头，減低集成和維護成本。
舉個例子舷蟀，比如我們的醫(yī)療業(yè)務系統(tǒng)都知道分為很多個系統(tǒng)恤磷，包括HIS面哼、LIS、EMR等等扫步，如果這些業(yè)務系統(tǒng)是由多個商家做的魔策，可能會有構建語言不同、通信協(xié)議不同河胎、數(shù)據傳輸格式不同等問題闯袒，那么如何把這些系統(tǒng)用一條線串起來呢？就是用ESB游岳；還有我們醫(yī)療從業(yè)者政敢、患者、管理人員等可以通過多個渠道訪問后臺系統(tǒng)胚迫，比如瀏覽器的portal,移動設備等喷户；還有一些特殊的醫(yī)療業(yè)務應用系統(tǒng)，比如雙向會診访锻、遠程會診褪尝、業(yè)務協(xié)同等等，即實現(xiàn)了ESB的基本特點期犬，又滿足醫(yī)療衛(wèi)生行業(yè)的特定需求的ESB河哑，叫做健康服務總線（Health Service Bus，HSB）哭懈。
ESB為了解決剛才說的問題灾馒，就需要保證多個應用系統(tǒng)的服務接入茎用，協(xié)議轉換遣总，提供可靠的消息傳輸，數(shù)據格式轉換轨功，基于內容路由等功能旭斥。
有人可能會有疑問，應用A發(fā)送消息給ESB古涧，ESB再將消息轉換給應用B垂券，那么應用A直接通過SOAP協(xié)議發(fā)送給B，效率不是應該更高嗎羡滑？而且如果這些IT系統(tǒng)都在一個網絡中菇爪，提供的WebService都在統(tǒng)一命名空間下，就可以相互通信柒昏，為什么還要加上這一層凳宙？有兩點需要考慮。第一點职祷。點對點做服務的時候氏涩，通常需要考慮日志記錄届囚，服務訪問安全、傳輸安全是尖、數(shù)據安全意系、路由分發(fā)等一系列問題，而這些完全可以統(tǒng)一管理饺汹，統(tǒng)一驗證蛔添，靈活配置，首繁；如果應用A調用了應用B作郭，在調用了應用C等具有邏輯流程的調用時，還可以在ESB上實現(xiàn)流程引擎弦疮；第二點夹攒，ESB是一個中間件平臺，包含了消息中間件的全部功能胁塞，有異步消息處理機制咏尝，可以實現(xiàn)業(yè)務系統(tǒng)之間真正的松耦合的結構。
三啸罢、市面上 ESB產品有哪些编检？如何選擇
一．CXF
CXF的定位不是ESB總線，而是一個服務框架（Service Framework）扰才，主要還是為關于服務的應用提供API上的支持允懂，或者上下文上的管理●孟唬可是它的前身之中的一個的Celtix就是IONA公司捐獻給開源界的ESB總線蕾总，所以總體上還是能提供ESB總線的功能（需依靠與其他的容器）。在CXF中的總線僅僅是起到一個共享資源的提供者的作用琅捏。這些貢獻資源就相當于JBI規(guī)范中的綁定組件（BC）或服務引擎（SE）生百。即使如此CXF并沒有提供了對JBI規(guī)范的完整實現(xiàn)。能夠說它僅僅是一個相似的JBI容器柄延。CXF支持與除了HTTP之外的其他協(xié)議的通信綁定蚀浆，比如REST、JSON和CORBA等搜吧，所以對于Ajax有較強的兼容性市俊。這相對與其他的ESB總線而言能夠說是一個較大的優(yōu)勢÷四危可是CXF的ESB總線是根據Spring框架來實現(xiàn)的摆昧，由Spring來管理Bus中的各個組件。而Spring對各個Bean或組件的管理是通過一個上下文的配置文件來實現(xiàn)的僵刮。這種方式相對與其它的ESB總線（比如根據JMX）的方式而言据忘，則不支持動態(tài)的熱部署鹦牛。也就是說CXF不是一個JBI容器，它必須依附與其它的容器來執(zhí)行∮碌酰現(xiàn)有的資料來看曼追，CXF眼下能夠部署在JBoss和BEA Weblogic中，Tomcatserver因為不支持完整的J2EE規(guī)范汉规，特別是基于JCA的EJB礼殊，所以對CXF支持的程度不理想。盡管資料中沒有涉及到Geronimo针史，可是以Geronimo對J2EE規(guī)范的兼容程度來看晶伦，特別是EAR文檔的支持，在Geronimo中部署CXF應該沒有什么太大的障礙啄枕。相同你能夠在使用Spring的應用中嵌入CXF婚陪，而這僅僅須要在Spring的配置文件里填寫對應的配置信息就可以。關于CXF的文檔較為豐富频祝，這部分是因為它本身是整合了Xfire和Celtix這兩個本身較為成熟的開源項目泌参。另外它較大的依賴于Spring框架，所以假設對Spring較為熟悉的話常空，在使用上一般就沒有太大的障礙了沽一。
二．Open ESB
OpenESB是Sun公司提出來的開源ESB項目，所以對JBI規(guī)范的支持程度就不用多說了漓糙。而GlassFish ESB則是將OpenESB的核心執(zhí)行環(huán)境與GlassFish應用server以及NetBean的集成開發(fā)環(huán)境整合在一起的有一個ESB項目铣缠，當然當中還包括了一些OpenESB中已有的組件（子集）。
在OpenESB中提供了可以支持WS-BPEL2.0的引擎昆禽』韧埽可是如今這個組件支持WSDL1.1，暫不支持WSDL2.0为狸。并且這個引擎要依托與NetBean集成開發(fā)平臺歼郭，起碼僅僅能得到基于NetBean的對應開發(fā)包和組件包遗契》簦可是這個組件對BPEL提供了強大的支持，當中包含支持端點狀態(tài)的監(jiān)控牍蜂、支持多線程運行漾根、業(yè)務流程的調試、系統(tǒng)錯誤的可靠性恢復中各個業(yè)務流程實例的數(shù)據庫持久化以及負載均衡等鲫竞。在資料方面僅僅有一個演示視頻辐怕，主要還是基于NetBean平臺的使用介紹。其它發(fā)布的資料則則較少从绘，特別是API方面差點兒沒有寄疏。所以假設要對OpenESB進行依照自身的要求進行擴展則較為困難是牢，除非對OpenESB的源碼進行全面的分析。
三．ServiceMix
ServiceMix是Apache基金會下的一個ESB總線陕截，同一時候也是一個獨立的JBI容器（也就是說它支持完整的JBI規(guī)范）驳棱。說它是一個獨立的JBI容器，是由于它擁有自己獨立的執(zhí)行環(huán)境农曲，能像應用server一樣啟動社搅，并支持動態(tài)的熱部署等，這一點則差別于CXF乳规。
ServiceMix的容器執(zhí)行環(huán)境採用內核的架構形葬，并以Geronimo關于J2EE方面的實現(xiàn)為基礎（當然也就支持J2EE的各方面規(guī)范，比如安全性方面的JAAS等）暮的，所以在性能上還是較為出色的笙以。在通信上，整合了ActiveMQ冻辩，也支持多種的通信協(xié)議源织，比如HTTP和JMS。同一時候在管理組件上採用了JMX的管理架構微猖，從而可以對部署在總線上的各種組件進行動態(tài)的配置和管理谈息，或通過Web的形式，或通過JMX遠程訪問均可凛剥。ServiceMix內核可以整合到所處的操作系統(tǒng)中侠仇，從而作為OS的對外提供的服務。差別與其它總線的是犁珠，ServiceMix還提供了自己的腳本命令控制臺逻炊，并通過一些簡單命令來管理應用組件以及ServiceMix內核實例。
關于ServiceMix的資料也較為的完備犁享，當中當然也包含一些簡單的小樣例余素。關于組件擴展方面和流程引擎整合方面的具體資料則不夠具體。假設要做進一步的總線上的擴展炊昆，則須要對源碼和樣例進行較為深入的學習和研究桨吊，當然這一切的基礎是對JBI的規(guī)范有較為全面的了解。
四．JBoss ESB
JBoss ESB是JBoss社區(qū)為面向SOA而提出的一個EAI系統(tǒng)平臺凤巨。它提供了非常多EAI本身所應具有的功能视乐，比如業(yè)務流程監(jiān)控、集成開發(fā)環(huán)境敢茁、工作流用戶接口佑淀、業(yè)務流程管理、分布式計算架構以及作為應用容器的功能等彰檬。能夠說JBossESB在功能上是較為強大的伸刃。但相對于上面的總線而言谎砾，它的技術架構方案是最獨立的。由于它除了支持J2EE標準外捧颅，對于JBI規(guī)范壓根就不沾邊棺榔。當然也就不存在JBI規(guī)范中的規(guī)范化消息路由、服務引擎和綁定組件了隘道。JBossESB除了支持 Web Service外症歇，還支持多種的遠程調用協(xié)議，比如JMS谭梗。僅僅是相對于ServiceMix和CXF而言忘晤，假設要對JBossESB進行擴展，可能要花費較大的時間和精力激捏。
JBossESB相對上述的開源項目而言设塔，一個非常大的優(yōu)勢在于文檔資料是最為豐富和完備的。所以在開發(fā)和擴展上減小了不小的阻力远舅。它而且依托于成熟的JBoss社區(qū)闰蛔，周圍齊全的開源項目支持，為后期的平臺擴展提供了豐富的選擇空間图柏。
四序六、 如何實現(xiàn)ESB的各個功能
1.ESB的服務接入方式？
- RPC 遠程過程調用（面向方法）
- SOAP 面向服務的架構（面向消息）
- REST 資源的狀態(tài)轉變（面向資源）
目前我們公司使用的HSF實際上就是RPC蚤吹，還是JSON-RPC例诀，RPC的另一種實現(xiàn)還有XML-RPC，通訊方式相同裁着，采用調用本地服務（方法）一樣的調用服務器的服務（方式）的方式繁涂，只不過傳輸數(shù)據格式不同，JSON格式更加高效二驰。
XML-RPC實際上就是這三種方式的最早通信方式扔罪，基于HTTP傳輸協(xié)議+XML參數(shù)封裝，一個XML-RPC消息就是一個請求體為xml的htpp-post的請求桶雀，服務端執(zhí)行了之后也以XML格式的編碼返回矿酵，后來這個標準演化成了SOAP，可以理解為SOAP是XML-RPC 的高級版本背犯；
SOAP坏瘩，簡單對象訪問協(xié)議盅抚，是一種輕量的漠魏、簡單的、基于xml的遠程訪問協(xié)議妄均，可以實現(xiàn)多種傳輸層或應用層協(xié)議結合使用柱锹，如TCP/HTTP/SMTP等,實際上應用最廣泛的還是基于HTTP+XML的實現(xiàn)哪自，相對于XML-RPC，SOAP更好的利用了XML禁熏，有相應的服務描述語言壤巷，也是一段XML,也就是WSDL(Web Services Description Language),專門用來描述怎么訪問web服務，描述了哪些細節(jié)呢瞧毙？一般包含4點胧华，用于訪問服務的地址信息，用于傳輸信息的傳輸協(xié)議（比如通道數(shù)）宙彪，用于所有可使用功能的名稱和接口方法矩动，在所有的請求和響應中所使用的數(shù)據類型，具體什么格式释漆，這里不再展開悲没，有興趣可以查看一下以下鏈接：
WebService之WSDL文件講解
最后說REST，非協(xié)議非規(guī)范男图，只是一種約束示姿、概念或者開發(fā)方式，簡單的說就是逊笆，用HTTP動詞（GET,POST,DELETE,DETC）描述操作栈戳，表示資源的轉換。滿足REST的約束叫RESTful結構难裆，其實目前公司的并不是RESTful風格荧琼。
近年來的REST被炒得很火，但不是所有情況都是適合的差牛，REST目前都是基于HTTP/HTTPS命锄，而SOAP可以支持很多傳輸協(xié)議，從HTTP/HTTPS到SMTP（Simple Mail Transfer Protocol偏化，簡單郵件傳送協(xié)議）脐恩，甚至JMS（Java Messaging Service，Java消息傳遞服務）侦讨。而SOAP已經是一個工業(yè)標準驶冒，它具備良好定義的協(xié)議，以及一套良好確立的規(guī)則韵卤，在大型和小型系統(tǒng)中均有采用骗污。
2.ESB的如何進行協(xié)議轉換？
現(xiàn)在使用的ESB協(xié)議轉換基本上使用的ESB產品沈条，實現(xiàn)基本上二進制進行轉換需忿；具體的可以找相應的產品的，比如 WSO2d產品的實現(xiàn)：
WSO2 ——（7）ESB功能：協(xié)議轉換
目前有一些問題需要再調查一下，cxf3.1目前也只支持wsdl1.1屋厘，axis2的最新版也不支持wsdl2.0涕烧，需要繼續(xù)查詢資料如何轉換；有些企業(yè)再做接口對接的時候可能只提供wsdl,需要自己根據wsdl生成服務端提供服務給他們汗洒，可以利用soapUI實現(xiàn)议纯。有些企業(yè)只支持wsdl1.0，我們要實現(xiàn)自己的ESB就要提供wsdl1.0與wsdl2.0版溢谤。
3.數(shù)據轉換
- 在應用間交換不同格式的信息
- 操作消息的負載內容瞻凤，包括加密、壓縮和編碼轉換
- 在異構的傳輸協(xié)議的數(shù)據類型間格式化消息
此過程也是依賴工具比如Mule可以用Transformer 進行轉換世杀，比如將JMS格式message轉化為其他類型的數(shù)據鲫构，JDBC Transformer可以將CSV或xml文件中的數(shù)據轉移到數(shù)據庫中等等操作
4. 消息路由
- 基于消息內容和復雜規(guī)則路由消息
- 消息的過濾、聚合以及重新排列序號
此過程也是依賴工具比如Mule可以用case when 等邏輯判斷玫坛，根據消息中指定的消息將消息發(fā)送到不同的服務端進行處理结笨。
5. 其他功能
ESB當然還有其他功能，這里不再介紹湿镀，基本上各個ESB工具已經封裝好炕吸，可根據ESB工具自己拓展和調用。這里給出其他功能介紹的鏈接 java系統(tǒng)間通信ESB勉痴。
五赫模、ESB與微服務的區(qū)別
見我另一篇文章：企業(yè)服務總線 與 注冊服務管理
