架構設計：系統間通信（35）——被神化的ESB（下）

2-4、ESB與版本控制

企業中的系統集成過程，存在很多非技術因素引起的變化。可能出現的情況是，某個一直能夠正常使用的調用功能A，在某一天突然就不能使用了。技術團隊和業務團隊排查了許久才發現功能A中對某個業務系統的調用接口已經被私自更改（可能只是多傳遞了一個參數、或者減少了一個參數的傳遞）。這種情況在現實中經常出現，可能是業務部門出於私利對外屏蔽了這個接口，也可能是技術人員在改動接口時，忘記了這個接口還有外部系統進行使用。

ESB中間件提供的版本管理功能可以幫助我們解決這個問題。這裏說的版本管理功能，並不是像Git那樣面向整個工程的版本管理，而是細化到服務接口層面的版本管理。以下示意圖向讀者展示了ESB中的版本控制功能是如何工作的：

上圖中，進行版本控制的關鍵功能就是ESB中的註冊中心模塊。在其中管理了各個業務系統已經向ESB總線註冊的能夠提供業務服務的接口定義和接口版本信息。ESB總線在進行服務編排時，只能使用已經向註冊中心註冊的業務接口和相應版本。

這樣的機制保證了業務系統可以在新版本準備好以後，再向註冊中心註冊一個新的接口版本。在此之前無論業務系統的模塊怎樣變更，只要在註冊中心註冊的原有接口定義沒有變化，就可以保證各個業務系統集成後的功能能夠正常工作。註冊中心在下線某個版本的服務時，會檢測是否還有業務功能對這個服務和版本存在調用關係，如果檢查發現服務依賴關係任然存在，則不允許進行下線操作。註冊中心還可以在服務的新版本註冊後，對現有編排邏輯中的老版本進行批量升級。

需要注意：ESB中的註冊中心模塊並不像協議轉換功能那樣，是ESB技術的必備功能。但是有註冊管理中心和版本管理機制的ESB實現更能保證總線上業務功能的穩定運行。

2-5、ESB與監控

雖然在ESB定義的特性中，並沒有規定監控是它的必要部分，但是由於現在的ESB中間件軟件都比較龐大，且往往在企業系統集成中扮演非常重要的角色。所以大多數ESB軟件都帶有監控模塊。這裏說的監控並不是業務層面的監控，而是指非業務性指標的監控：

• 對原子服務單元的健康性進行監控：

  爲了保證ESB提供的服務路由能夠被正確調用，ESB中間件需要對各個業務系統提供的原子服務的可用性進行健康監控。這是爲了保證在集成服務後，如果其中某一個原子服務出現問題技術團隊/業務團隊能夠第一時間知曉這個情況，並且能立即進行解決。如果原子服務出現問題，那麼很有可能代表着由這個原子服務參與各個服務編排也有可能出現問題（當然，這還要看設置的消息路由條件）。

• 對原子服務的調用情況進行監控：

  各業務系統提供的原子服務在ESB總線上被調用的次數、頻度、單次執行時間、峯值訪問時段等數據都可以反映這個原子服務的重要性和原子服務本身的性能指標。所以ESB的監控子系統需要對這些指標進行採集，間接幫助技術團隊/業務團隊對原子服務的非業務性指標進行優化。例如：增加業務系統的計算節點、擴大單個節點的硬件性能，甚至重構原子服務。

• 對集成後的新業務調用情況進行監控：

  在ESB中間件中，基於多個原子服務所構建的集成服務上，包括這個集成服務被調用的次數、這個集成服務總的單次執行時間、集成服務中哪一個原子服務是最消耗執行時間的、哪一個原子服務的執行次數是最多的，調用原子服務所採用的協議標準和消息格式，等等一系列數據指標都是監控子系統需要採集的重點數據。

• 對ESB中間件自身健康性進行監控：

  ESB中間件自身的健康指標至少需要包括：ESB每個子系統的CPU使用情況、內存使用情況、網絡使用情況、線程工作情況、磁盤I/O使用情況、集羣中當前活動節點（和發生故障的節點）等等。需要注意的是：對各個業務系統自身的健康狀態和性能狀態進行監控，並不是ESB中間件的監控子系統份內的工作，如果後者有和前者有關的功能，也只是對各個業務系統所提供的原子服務健康狀態進行監控。

3、常用ESB產品

3-1、商（付）用（費）ESB產品

• IBM ESB系列產品。

IBM提供了兩款純軟件的ESB產品：IBM WebSphere ESB和IBM WebSphere Message Broker（WMB）。後者是前者的升級版本（或者說是高級版本），支持更廣泛的傳輸協議和消息格式。

 
（此圖來源於網絡）

WebSphere Message Broker產品是一個全分佈式的ESB產品，它使用多個Message Broker實例分別處理不同的業務編排、消息轉換工作。並且使用Message Broker Explorer和Message Broker Toolkit（基於eclipse-plugin的開發者工具）對這些Broker進行統一管理。

• Oracle ESB產品 
  Oracle Service Bus (OSB)是Oracle的付費產品：

上圖來源於OSB官網文檔（https://docs.oracle.com/cd/E29542_01/doc.1111/e15020/introduction.htm#OSBCA117），顯示了OSB的基本功能全貌。和WMB類似，OSB也是全分佈式的ESB產品，並且爲開發人員提供的工具也是基於eclipse-Plugin。指的注意的是OSB和WMB實現業務編排的思路是一致的：ESB基礎層只提供消息轉換和協議轉換動作，而服務編排和路由規則則由特定的上層組件（Message Broker/Service Virtualization）進行處理，並且這些組件可以靈活部署。

不過筆者從兩者的官方文檔中並沒有看到這兩款付費的ESB產品對一些目前流行的傳輸協議和消息格式的支持，例如是否支持Protobuf、是否支持Netty4、是否支持Avro等等。

• 普元ESB產品

普元ESB產品是國內比較有代表性的有用自主產權的ESB產品（本人並沒有打壓國產其他ESB產品意思）：

上圖來源於普元官方白皮書截圖。普元的ESB中間件系統經過多年建設和升級，在國內商用ESB中間件中已經算是比較完整了。除了包括ESB技術必要的消息轉換、消息路由、協議轉換、服務編排功能外，還有衆多輔助功能，如ESB Studio中提供給開發人員使用的編輯管理工具，以及獨立的服務註冊管理單元，還包括監控ESB中間件監控平臺等子系統功能。

貌似普元ESB中間件是有社區版本的，可以供開發人員下載使用。不過功能方面肯定不如付費版本那樣全面。

3-2、共（免）享（費）ESB產品

• Mule ESB

Mule ESB是集成服務提供商MuleSoft（官方網站：https://www.mulesoft.com/）的產品之一。這家公司還有很多有趣的產品，例如：Anypoint MQ。

Mule ESB主要基於JAVA語言進行構建，支持多種傳輸協議（File,FTP,UDP,TCP,Email,HTTP,SOAP,JMS等），並且有獨立的提供給開發人員使用的工具：Mule Studio。消息格式轉換方面，Mule ESB提供了很多現成的組件，使開發人員能在編排的服務內部輕鬆實現消息轉換，當然開發人員也可以按照Mule ESB的規範自行定義消息格式轉換。

 
（上圖來源於網絡）

企業集成模式（Enterprise Integration Patterns，實際上是一本書名），其中專門討論的就是企業內部的各個業務系統如何進行集成。Mule ESB中的業務服務集成就基於EIP思想。

Mule ESB有兩個版本，社區版和企業版。前者是大多數開發者使用的版本；後者是需要付費的，但是功能更強大。

• ServiceMix

  想說說Apache ServiceMix，最後想想還是算了。說到這個開源ESB中間件，說起來都是痛。如果各位讀者要使用Apache ServiceMix，建議使用最新的5.6+版本。提醒一點：各位最好搞清楚OSGI的一些基本知識再使用它，免得走彎路。

• Apache Camel

Apache基金會下的一個頂級開源項目，它提供了一套消息路由規則和消息轉換引擎。不過他並沒有現成的消息轉換組件，技術人員需要遵循Camel的定義規則自行實現消息轉換（您可以實現一次消息轉換然後在各個路由定義中重複使用）。Apache Camel支持領域特定語言（DSL），這裏我們不需要把這個知識點鋪開來講，舉一個例子就行：

// 編排的業務過程process {    // 入庫
    procurement {
        Item_code = "12345678"
        name = "物品名稱"
        numner = 12
        time = "2016-09-08 18:30:01"
    }    // 發車
    sendCar {
        car_code = "098765"
        plate = "京AXXXXX"
        time = "2016-09-09 19:37:00"
        driver = "王老五"
    }
}1234567891011121314151617

以上DSL例子使用Groovy語言進行實現，雖然物流行業的業務人員不懂編程，但是他們也可以看懂以上例子所描述的業務過程，甚至還可以進行改編。這就是領域特定語言——專門用在特定行業或領域用來進行業務規則描述的語言。Apache Camel支持業務人員使用JAVA語言在業務集成領域進行規則描述。還是不能理解嗎？沒關係我們下一篇文章開始會比較詳細的介紹Apache Camel的使用，到時還會提到這個問題。

嚴格來說Apache Camel並不能算作ESB中間件服務，不過開發人員可以使用它獲得完整的協議轉換、消息路由和服務編排能力。然後再自行爲它集成注入版本控制、服務註冊、運行監控等其他能力並使用某種方式讓這些服務運行起來。也就是說，我們可以使用Apache Camel自行開發一個符合我們業務要求的ESB中間件服務。

4、後文預告

通過這兩篇文章，筆者並沒有採用企業/產品宣講的形式，用許多高大上的詞彙向各位讀者描述ESB技術。這樣依賴，各位讀者是否感覺到ESB技術並沒有那麼生澀難懂？實際上，如果用最簡單的詞語對ESB技術進行概括的話，那麼最形象的概括就是：轉換和集成。轉換是指轉換協議和消息格式，集成是指將原子服務按照要求有規律的進行串接。

從下篇文章開始，我們將向讀者介紹Apache Camel組件。這個組件服務開發人員進行轉換和集成的基本能力，但是要將它單獨作爲一款可用的ESB中間件進行發佈使用，那還有大量的設計和開發工作需要完成。最後，我們介紹如何基於Apache Camel設計一款滿足自身業務需求的ESB中間件產品。

來源：http://blog.csdn.net/yinwenjie