企業ESB平臺部署及接口服務設計研究

摘要：企業服務總線（Enterprise Service Bus，ESB）從面向服務體系架構（Service Oriented Architecture，SOA）發展而來，是傳統中間件技術與XML、Web服務等技術結合的產物，可以消除不同應用之間的技術差異，讓不同的應用服務器協調運作，實現了不同服務之間的通信與整合。文章以某制造企業ESB平臺部署及設計為例，介紹了ESB的實現方法。

關鍵詞：企業服務總線；服務體系架構；ESB平臺部署；接口服務設計；制造企業 文獻標識碼：A

中圖分類號：TP393 文章編號：1009-2374（2016）23-0021-02 DOI：10.13535/j.cnki.11-4406/n.2016.23.009

1 概述

ESB全稱為Enterprise Service Bus，即企業服務總線。它是傳統中間件技術與XML、Web服務等技術結合的產物。ESB提供了網絡中最基本的連接中樞，是構筑企業神經系統的必要元素。ESB的出現改變了傳統的軟件架構，可以提供比傳統中間件產品更為廉價的解決方案，同時它還可以消除不同應用之間的技術差異，讓不同的應用服務器協調運作，實現了不同服務之間的通信與整合。從功能上看，ESB提供了事件驅動和文檔導向的處理模式以及分布式的運行管理機制，它支持基于內容的路由和過濾，具備了復雜數據的傳輸能力，并可以提供一系列的標準接口。

本文以某制造企業建設ESB的過程為例，簡要介紹了企業部署ESB平臺，并通過該平臺進行接口服務設計的一些基本方法。

2 ESB平臺部署

第一，系統軟件的選擇主要包括如下：

ESB平臺軟件：IBM Message Broker 8.0

系統管理服務器及日志服務器：Apache Tomcat 9.0

系統日志數據庫：采用Oracle或者MySQL

第二，系統主要硬件設備如下：

負載均衡設備：基于F5構建，對外提供ESB平臺的標準服務端口，由該設備接收所有的ESB服務請求，并將服務請求按照MB服務器集群中各服務器的負載情況分發給MB服務器集群中的MB服務器。

MB服務器集群：基于Linux服務器構建，安裝了IBM MessageBroker軟件，基于集群的Message Queue構建；服務器上運行了株機ESB平臺系統，進行相關的數據處理及基于株機ESB規范的業務操作。

管理、日志服務器：MessageBroker的日志服務器，安裝了Apache Tomcat，運行了日志軟件以及系統配置軟件，MB服務器將在啟動時從該服務器讀取相關配置信息，并在業務操作中將日志數據發送到該服務器?？紤]到維護管理的復雜度，該服務器可以酌情建設APP服務器集群，但是基于關鍵性原則，不建議構建超過2臺服務器的集群。

NAS：安裝了NFS提供共享硬盤，通過iScsi對外提供數據庫存儲，主要保存在ESB運行過程中的各項日志信息，該數據庫服務器可以使用主機現有的服務器實例來運行。

3 集成概念設計

3.1 業務場景到ESB集成的判斷標準

3.1.1 業務服務滿足度判斷標準。業務服務滿足度的判斷標準是用來分析、判斷該服務是否能夠滿足具體的業務，或者換言之是否存在具體的業務會使用到該服務。在業務分析時，該問題主要是用來衡量業務使用ESB來支持的價值，當該服務被越多的業務場景使用到，服務在該問題評判上的評分就越高。業務服務滿足度的問題是“這個服務提供的業務功能能否滿足業務流程和目標？這個服務能夠直接（相對于繼承于它的子服務）滿足某個業務目標？”

3.1.2 服務實現復雜度判斷標準。服務實現技術復雜度評判標準是用來分析、判斷該服務的實現成本以及該成本是否能夠被預算所實現。在實際業務實現時，存在一些老舊的不能支持Web service模式的系統，并且在過去集成這些系統時，使用了耦合度較高的集成模式，比如DLL方式；這樣如果要將這些集成遷移到ESB上，需要較多的預算甚至需要重新改造軟件系統本身；部分系統雖然支持Web service模式，但是因為原開發廠商的問題，要使用Web service的成本較高，服務實現復雜度判斷標準的問題是“業務上是否可以提供資金支持本服務的整個生命周期（創建、管理、治理和維護）？”

3.1.3 服務實現安全性判斷標準。服務實現安全性評判標準是用來分析、判斷該服務在實現后是否會帶來潛在的數據暴露風險。在實際業務中，任何數據都存在它的保密級別，比如某類數據可以被匿名訪問獲取或者某類數據的所有訪問操作均需要記錄訪問者，也存在一些數據只能被少數人訪問，而使用了ESB后，數據被發布到ESB上，客觀上就可以被所有能訪問ESB的外部用戶訪問到，因此需要考慮每一個服務對外公開的范圍，甚至部分數據就不能使用ESB來對外提供集成。服務實現安全性判斷標準的問題是“業務上是否允許將本服務提供給內部或外部的用戶或業務合作伙伴？比如這樣做可能會帶來額外的成本、商業秘密、安全性等問題？”

3.2 集成概念設計的原則性要求

3.2.1 完整性?；跇I務的需要，所有交互的數據、文檔必須是完備的，數據交互本身必須包含所有本次需要交互的數據，并確保發送端發出的數據與接收端接收的數據完全一致。自校驗可以被認為是保證數據完整性的主要手段，這是指：（1）在每一次數據交互過程中，通過技術手段來確保交互的數據的完整性；（2）在數據交互結束后，通過其他方法對于雙方的數據進行檢驗，按照檢驗值判斷雙方數據一致。

3.2.2 及時性。該企業的信息系統均設計為支持內部生產業務運作，這就意味著大多數業務集成場景下，數據的實時性要求并不高，系統操作是要求當業務操作到需要被交互數據時，能夠得到數據；在系統設計時就對應著可以通過在業務操作過程中補充拉取數據的方法來保證交互的及時性。

3.2.3 自糾錯。作為數據完整自校驗的后續手段，當發現兩邊數據出現不一致情況時，需要在系統集成時從集成方法上提供方法，來完成數據的重新交互。這意味著系統間的數據交互可以在任何狀態下重新開始，無論是系統在數據傳輸過程中停機，還是業務問題需要重新初始化數據，均能夠通過自糾錯方法完成數據的重傳，以達到數據在所有系統的最終一致。

3.3 集成場景

按照業務場景的特點，可以將業務場景分成如下種類來設計每一種場景的實現方法，來保證集成的完整性、及時性、自糾錯。需要說明的是，這種方法僅是每一種場景集成設計的建議模板，在實際的設計過程中可以根據具體情況進行調整。集成場景的區分主要是基于每一個集成場景所交互的數據的特點進行分類，這些數據特點包括：

3.3.1 交互類型：交互類型是指在業務場景的使用過程中，服務的請求方對于服務返回的時間要求，這主要反映了及時性的要求，交互類型主要分為異步數據交互與同步數據交互。

3.3.2 數據變化頻度：數據變化頻度是指服務所提供的數據的變化頻度，該類數據的增改的頻次情況，基本上以每天都可能有更新描述為頻度較高，否則為頻度較低。

3.3.3 數據量大?。簲祿看笮∈侵阜战换サ臄祿膯未谓换祿康拇笮?，這包括兩種情況：（1）單條數據的數據量較大；（2）單條數據的數據量不大，但是每次交互的數據條目較多。數據量大小一般以字節單位衡量；單次交互數據量在2K字節以上被認為數據量大，否則被認為數據量小，單次交互數據量在1M字節以上被認為數據量超大；在集成場景中，因為交互多條數據而造成的交互數據量大并不被認為數據量大。

3.3.4 數據實時性要求：數據實時性要求主要反映在異步數據交互中，數據使用系統對于數據的實時性要求，或者換言之系統間針對某服務提供的數據，多少時間內不一致不會造成業務問題。在分析時，系統間僅允許10分鐘的數據差異稱之為數據實時性要求高，否則稱之為數據實時性要求低。

4 公共接口服務設計

公共服務是指在ESB規范中，要求所有業務系統均實現的交互服務，這些服務被用來支持最基礎的集成業務，保證系統間集成的可靠性以及企業信息化系統數據的整體一致性。因此公共服務被設計為在所有接入ESB平臺的系統中部署，作為規范要求所有接入系統實現。我們整理出了如下公共服務，作為企業ESB平臺的公共服務，要求各業務系統實現。

表1

服務名 服務說明 業務系統角色

CHECKAVAIL 基礎的心跳服務，ESB使用該服務確認業務系統的狀態，并進行基礎信息的交互。 作為服務提供端

NOTIFYINFOCHANGE 基礎的通知消息服務，ESB通過該消息通知業務系統某種業務數據發生了變化。 作為服務提供端

RECINFODESC 基礎的數據對照服務，業務系統通過該服務獲取某業務數據的描述。 作為服務請求端

SYNCBASORG 獲取組織機構信息服務，ESB通過該服務對業務系統提供組織機構的更新信息。 作為服務請求端

SYNCBASUSER 獲取用戶信息服務，ESB通過該服務對業務系統提供用戶的更新信息。 作為服務請求端

SYNCBASDATA 系統預留的獲取部分公共數據編碼的方法，該數據編碼形式為名稱=值的形式，提供諸如性別編碼、職位類型編碼等編碼的獲取。 作為服務請求端

5 開發及應用流程

5.1 確定業務系統功能范圍

該階段的主要工作是確認當前需要部署到ESB的業務系統的功能范圍，并討論各功能集成場景。

5.2 確定該業務系統相關的服務接口

本階段的主要工作是針對前一階段得到的服務列表進行分析，確認能夠完成本次系統集成。

5.3 基于ESB提供的wsdl生成代碼

代碼生成后即可開始Web服務的調用。

5.4 測試及上線

為了確保各自實現的正確性，為了以后的聯調聯測工作能夠順利進行，要求參與集成的各方對自己的開發結果進行測試。測試過程中使用的測試數據由各自虛構，但需使用有意義、符合規則、盡量真實的數據。集成相關方按照上線計劃準備相關程序和基礎數據，在指定時間進行上線。

作者簡介：龔偉（1979-），男，四川榮縣人，中車株洲電力機車有限公司信息管理部高級工程師，碩士，研究方向：裝備制造業信息化。

（責任編輯：黃銀芳）