ESB 專案需求分析和方案設計淺談

婁 麗軍 (loulj@cn.ibm.com), 軟體架構師, IBM 軟體部

ESB 的需求分析

需求分析階段是梳理專案中相關功能需求和非功能需求的重要步驟，它是整個專案成敗的關鍵。在這個階段我們將從企業業務需求出發，梳理端到端的跨系統業務流程；基於業務流程，依據科學的方法論進行服務鑑別；由服務列表出發，梳理服務的消費和提供關係；然後根據 SOA 的最佳實踐，定義服務的介面，包括服務的 Schema 描述，欄位的型別，編碼的規則；依據服務的消費－提供關係，梳理 ESB 中的服務對映和轉換規則和策略。

概括而言，我們需要從功能性和非功能性兩個方面來進行 ESB 的需求分析。

針對 ESB 的功能性需求，我們要側重瞭解以下方面的問題：

1. 梳理出要被整合的系統的名稱，個數。

2. 針對每個系統而言，要了解：

• 該系統的對外介面是向外呼叫 (OutBound)，被別人呼叫 (Inbound)，還是二者都有；
• 介面的實時性要求，是實時的還是批量的，還是二者皆有？
• 介面的呼叫方式，是同步的還是非同步的，還是二者皆有？
• 應用系統所執行的作業系統平臺。
• 應用系統本身的程式語言？C/C++, Java…..
• 這些系統現有介面的情況，是否已經可以提供對外介面，介面的方式是什麼，包括介面的通訊協議是什麼，HTTP/MQ/Socket/ 其它？介面的資料格式是什麼，XML/ 自定義格式 / 其他行業標準格式？介面的程式語言是什麼，Java/C/C++？如果本身不能提供介面，那麼要做介面開發時有什麼要求或限制條件？
• 這些應用後臺資料庫的情況，資料庫能否直接訪問？
• 每個應用跟其他應用交換資料時，源資料格式和目的資料格式，比如從文字格式轉換為 XML 格式？
• 交易特徵：哪些處理要採用兩階段提交；是否需要多個訊息組成一個交易；是否要保證訊息之間的處理順序；
• 介面卡的情況：對於一些特殊系統，是否已經具備現成的介面卡；介面卡是單向的還是雙向的；
• 訊息通訊的模式：是 Send and Forget、Request/Reply 還是 Pub/Sub?

針對 ESB 的非功能性需求，我們要確認：

1. ESB 平臺的擴充套件性和高可用性需求，包括 HA 和叢集等；

2. ESB 平臺的效能需求，主要包括系統間資料交換的頻率，要交換的資料的大小 ( 訊息大小將直接對效率造成影響 )；峰值時候對 ESB 資料吞吐量、響應時間的要求等；

3. 哪些交易要保證資料傳輸的高可靠性；

4. ESB 平臺的可管理性需求，如服務的生命週期管理，ESB 平臺的維護和管理；如果企業已經設立了 SOA 管控方面的規範，那麼要遵從規範的制約，比如要考慮是否有規定的命名規則，企業是否有企業級的資料規範和底層通訊協議的規範等；

5. 安全性方面的要求：是否採用 SSL 傳輸加密，是否對訊息進行加密/解密處理等；

6. 錯誤處理和日誌以及平臺本身的執行監控等方面的要求等。

回頁首

ESB 的方案設計

方案設計的主要內容包括：

• ESB 涉及 IT 應用環境分析，定義 ESB 與相關應用的介面模式；
• ESB 架構概要設計，並定義架構原則；
• ESB 相關產品選擇，包括與外圍系統的介面卡選擇和 ESB 產品選擇；
• ESB 元件模型設計，分解 ESB 的相關模組，滿足 SOA 的分離關注點等架構原則；
• ESB 運作模型設計，滿足平臺的非功能性需求；
• ESB 平臺的服務流設計，涉及路由、轉換和對映等；
• ESB 的同步、非同步或者釋出/訂閱模式設計；
• ESB 平臺的接入渠道和資料介面設計，包括 XML/JMS、SOAP/HTTP、EDI/MQ 等；
• ESB 相關的介面卡設計，包括技術介面卡或者自開發的介面卡；
• ESB 平臺的容錯和重試機制設計，包括日誌等的統一管理等；

圖 1 是一個採用 ESB 整合的高層架構設計舉例：

圖 1. ESB 參考架構

如圖 1 所示，ESB 架構設計時主要要考慮通訊協議接入和轉換、資料接入和轉換、資料處理流程以及服務的註冊和管理等方面的內容。其中通訊協議接入和轉換是指對各種被整合的應用系統的通訊協議的支援和轉換能力，例如 HTTP、JMS、Socket、FTP 等；資料接入和轉換是指對各種被整合的應用系統提供的資料格式的支援和轉換能力，例如 XML、SOAP、自定義格式以及符合某些行業標準的專有格式（SWIFT、EDI、HL7 等）；資料處理流程是指路由、格式轉換、資料庫讀寫等對資料的各種處理；統一服務註冊儲存管理是指對服務的註冊、釋出、查詢，以及對運營時服務的管控，並且提供服務運營狀態的統計分析資料。

ESB 的元件模型

圖 2. ESB 元件模型

圖 2 給出了一個 ESB 元件模型的示例，其中包含的各主要元件及其功能如下：

1. Message Broker Runtime 組件提供訊息路由、格式轉換、訊息日誌等操作的執行時環境。該執行環境由 IBM Message Broker 提供；

2. Messaging Broker Instance 組件是處理基於 MQ 訊息業務請求的容器。它是作為一個 Broker 例項執行在 Message Broker Runtime 上的。該例項提供了 MQ 訊息的業務請求處理器、服務日誌、服務定位等功能的執行容器；

3. Web Service Broker Instance 組件是處理基於 Web Service 的業務請求的容器，它是作為一個 Broker 例項執行在 Message Broker Runtime 上的。該例項提供了 Web Service 的業務請求處理、服務日誌、以及服務定位等功能。

4. Event Broker Instance 組件是平臺內部處理 Pub/Sub 事件的容器。它是作為一個 Broker 例項執行在 Message Broker Runtime 上的。該容器提供了 Event Handler 元件的執行環境，將基於 MQ/JMS 的事件分發到不同平臺元件的目標佇列上。

5. Message Handler 組件是處理基於 MQ 訊息的業務請求，包括訊息解析、格式轉換，服務鑑權與認證、服務路由、服務日誌等功能。Message Handler 元件處理 MQ 訊息的典型流程如下：

• 首先對 MQ 訊息進行解析，對解析後的業務請求進行分析，之後通過 Authentication 與 Authorization 元件判斷該請求者的業務請求是否可以進行後續處理；
• 通過 Service Locating 元件對該業務請求進行服務定位與路由；
• 將基於 MQ 的業務請求訊息轉換成 Web Service 的業務請求訊息；
• 通過 Service Logging 元件對整個業務請求進行日誌記錄；
• 返回業務請求處理結果給業務發起者，如果失敗，返回錯誤訊息。

6. Web Service Handler 組件是處理基於 Web Service 的業務請求，與 Message Handler 元件功能類似，也包括訊息解析、格式轉換，服務鑑權與認證、服務路由、服務日誌等功能。Web Service Handler 元件處理 Web Service 請求的典型流程如下：

• 首先對 Web Service 請求訊息進行解析，對解析後的業務請求進行分析，之後通過 Authentication 與 Authorization 元件判斷該請求者的業務請求是否可以進行後續處理；
• 通過 Service Locating 元件對該業務請求進行服務定位與路由；
• 通過 Service Logging 元件對整個業務請求進行日誌記錄；
• 返回業務請求處理結果給業務發起者，如果失敗，返回錯誤訊息。

7. Event Handler 組件實現對 Pub/Sub 的處理。

8. Service Locating 組件負責根據業務請求定位具體的服務提供者。Service Locating 通過對服務目錄的查詢選擇適合的服務進行後續的呼叫，該查詢工作可以通過實時的服務目錄查詢獲得結果。

9. Service Logging 組件負責記錄整個業務請求處理過程中的情況，該元件的實現可以通過檔案或者資料庫的方式。

10. Authentication 組件負責對業務請求者進行鑑權，判斷該業務請求者是否可以訪問平臺服務，該鑑權的工作在企業服務匯流排的外部進行，Authentication 元件只是呼叫外部功能完成。

11. Authorization 組件判斷業務請求者是否具備訪問某特定服務的許可權，該驗證許可權的工作在企業服務匯流排的外部進行，Authorization 元件只是呼叫外部功能完成。

以處理基於 MQ 訊息輸入為例，ESB 的元件互動圖如圖 3 所示：

圖 3. ESB 元件互動圖

ESB 方案設計時的最佳實踐

根據我們以往專案設計和開發時的一些經驗，我們建議進行 ESB 的方案設計時要遵循下述最佳實踐：

1. 確定標準的使用：使用與否、使用到什麼程度；
2. 確定在 ESB 上實現的業務邏輯：ESB 是一個服務路由和轉換中心，而不是一個應用伺服器，因此它並不能取代應有伺服器。複雜的訊息解析和轉換相比簡單的路由操作所需消耗的成本要高的多，因此在 ESB 上應該主要考慮路由、格式轉換、服務呼叫等問題，而對於資料本身的處理應該交給相應的應用來完成；
3. 確定訊息格式：從標準化的角度而言，XML 當然是首選，但是從解析 / 處理效能、行業標準以及對現有應用的最大相容性的角度而言，可能會採用某些特定格式，例如 EDI、SWITF、平文字或者自定義格式等；
4. 區別訊息頭和訊息體：把資料的 Meta-data，例如：安全相關的資訊、日誌的等級、請求端的標識等放在訊息頭中，而不要放在訊息體中。這樣可以很容易地改變其內容及其對其的處理邏輯。在 ESB 中只處理訊息頭，避免對訊息體的解析；
5. 設計時參考 ESB 相關的成熟 Patterns；
6. 使用服務註冊庫：如需要服務 Endpoint 的查詢：推薦從服務註冊中心進行查詢，這樣的好處在於：服務提供者可以容易地釋出新的服務，服務提供者和 ESB 之間的耦合度可以更低，通過關於服務本身的 Metadata 來進行服務的查詢和路由；
7. 注重效能和高可用性的考慮；
8. 在必須的情況下考慮交易完整性；
9. 介面卡的採用：應用系統通過介面卡實現與 ESB 的雙向互動，介面卡主要分為技術介面卡、應用介面卡兩種，介面卡的物理部署可以與 EIS 部署在一起、或者與 ESB 部署在一起，也可以單獨部署，在介面卡設計時要考慮通訊協議和訊息格式兩個方面；
10. 多 ESB 的設計：ESB 也是一個邏輯的元件，在一個企業裡可能需要多個 ESB，例如：企業內部 ESB 連線企業內部各個系統，外部 ESB 實現企業與合作伙伴等的外部連線；再如：企業內部可能存在若干個部門級 ESB 和一個全企業 ESB；
11. 確定服務版本控制策略；
12. 確定端到端的 QoS 準則；
13. 注重安全性；
14. 確定 IT 部門 ESB 平臺的負責主體，長期的投入。

ESB 的安全性考慮

對於 ESB 的安全性考慮，主要有兩種方式，第一種方式是通過 ESB 內部的 Mediation 節點來進行服務請求者的認證 / 授權；另一種是呼叫一個外部服務進行服務請求者的認證 / 授權，如圖 4 所示，圖中給出了這兩種方式的示意圖，具體實施時可以進行選擇。

圖 4. ESB 的兩種安全實現方式

執行在 ESB 平臺上的服務的管理和監控

當一個企業開始它的 SOA 之旅時，開始階段通常會選取一個具體的專案進行 SOA 的嘗試，然後便會逐步走向全企業採納，這時，大多數企業都會面臨一個問題，那就是服務越來越多，對這些服務目錄的管理出現了很多問題，例如：所有與服務相關的資訊是如何被管理的，包括儲存、管理、維護、存取等？服務請求者如何決定使用哪個服務？服務請求者如何定位服務的 Endpoint？當服務資訊發生改變時如何得到通知？

因此我們建議使用者在儘可能早的情況下考慮服務註冊中心的建設，所謂服務註冊中心是一個企業範圍內的服務資訊的儲存庫，該儲存庫儲存了企業中註冊的服務和服務相關的資訊，它的主要功能包括：

1. 採用集中的方式來管理服務相關的資訊 (Interface, Service Location, Service Specification…)，為服務後設資料同時提供“註冊中心”功能，允許使用者儲存、管理和查詢包含服務描述的服務後設資料構件（WSDL、XSD、WS-Policy、SCDL 或 XML 文件）；
2. 提供服務的治理功能，實現整個服務生命週期的管理；
3. 提供服務間依賴、包容關係的管理；
4. 提供分類 (Categorization) 和版本控制 (Versioning) 等功能；
5. 提供服務發現和通知等能力等。

除了服務註冊中心的考慮之外，我們還要考慮對服務的管理。服務不僅具有特定的功能，還應該滿足一些諸如效能、可用性、安全性等 QoS 指標。服務響應的快慢、什麼時間可用、可以被誰呼叫、在某個時間段裡能被呼叫多少次、哪些事件要記錄日誌，這些都是服務管理要考慮的問題。通過服務註冊中心和服務監控平臺的有機配合，我們可以根據服務的響應時間、服務可用與否等策略來實現對服務的動態訪問。讓我們來看一個例子：

圖 5. 使用服務監控平臺之前 ESB 的服務請求和響應


圖 6. 使用服務監控平臺之後 ESB 的服務請求和響應

如圖 5 和圖 6 所示，我們可以利用服務監控平臺對服務進行監控和統計分析，從而使 ESB 平臺可以根據服務提供者的效能優劣來動態地繫結和呼叫高效能的服務，其過程如下：

• 服務請求者請求“PurchaseOrder”服務
• 服務註冊庫查詢到服務提供者
• 服務註冊管理平臺第一次呼叫了 Proder1 提供的服務
• Provider1 的效能被監控工具監控到
• 隨著時間的推移，Provider1 的效能越來越差
• 監控軟體監控到這一現象，就會停止使用 Provider1 提供的服務
• 當下一次服務請求者再次請求此服務時，服務註冊管理平臺將呼叫 Provider2，請求來自 Provider2 提供的服務。

回頁首

ESB 的開發和測試

在 ESB 開發和測試階段要完成的工作主要包括：

• 基於 eclipse 工具的模型驅動的快速開發；
• ESB 整合流程的開發；
• ESB 路由、訊息處理邏輯的開發；
• ESB 資料對映和轉換的開發；
• ESB 外圍介面卡的開發和配置；
• 單元測試：基於模組的測試，包括介面卡的測試，路由的測試，BO 的測試等；
• 整合測試：ESB 與其他服務提供者和服務消費者的整合測試，重點關注服務介面；
• ESB 平臺的效能測試以及系統測試，即整個 ESB 涉及到的端到端業務場景的測試等。

進行基於 WebSphere Message Broker 平臺進行 ESB 開發時，通常要考慮以下一些方面的最佳實踐，例如：通用的錯誤 / 例外處理、通用的日誌 / 管理機制、子流程設計、交易完整性和訊息永久性、ESQL 的使用等。

回頁首

結束語

本系列文章結合交通運輸業和製造業企業的不同行業特點和需求，為大家介紹了兩個真實環境下企業 ESB 的方案設計，並且結合多年的專案實施經驗和方法論，與大家分享了在 ESB 專案實施過程中有關需求分析、方案設計等方面的一些經驗，希望大家的 ESB 專案獲得成功。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14789789/viewspace-610864/，如需轉載，請註明出處，否則將追究法律責任。