實時企業服務總線的研究與設計

夏純中，宋順林

（1.江蘇大學 計算機與通信工程學院，江蘇鎮江212013；2.江蘇大學現代教育技術中心，江蘇 鎮江212013）

0 引 言

企業服務總線 （enterprise service bus，ESB）是基于面向服務架構 （service oriented architecture，SOA）思想的企業應用集成的基礎軟件架構［1］。ESB作為SOA架構的信息傳輸平臺，通過標準的適配器連接異構環境中的服務，實現各集成系統之間的互操作功能［2－3］。作為一種集中式的SOA方案，ESB的潛在問題就是它的性能瓶頸。研究者已經對ESB的性能模型進行了研究。ESB系統的性能取決于組合服務的性能，ESB的運行模型本質是一種排隊網絡性能模型［4］。使用動態可配置的消息路由優化ESB性能是一種常用的方法［5］，當某個服務負載過大或出現故障時，系統能夠自動將消息路由至其它服務。

為解決ESB系統內部多種不同類型的業務流競爭有限帶寬資源時導致的擁塞問題，提出一種實時ESB模型。通過對ESB模型進行改進，增加了業務類型優先級和業務執行時間約束的語義，以及業務請求監控和業務調度組件。系統運行時采用實時調度算法，根據不同類型業務流帶寬需求，按照業務類型優先級從高到低動態分配服務總線的業務流量帶寬。

1 現有的ESB模型及其存在的問題

Java業務集成 （Java business integration，JBI）是JCP（Java community process）制定的Java平臺的 ESB標準化技術規范［6］。JBI中定義了兩種組件：綁定組件 （binding components，BC）和服務引擎 （service engine，SE）。綁定組件用于根據特定協議和傳輸器發送和接收消息，如HTTP/Web Services、JMS、FTP等。服務引擎實現業務邏輯，編排整合各種服務。綁定組件把消息在特定協議的格式和規格化格式之間進行轉換，使JBI系統只需處理規格化消息，從而把JBI系統與特定協議分離。服務引擎和綁定組件通過傳輸通道 （delivery channel，DC）與標準化消息路由 （normalized message router，NMR）進行通信［7］。

JBI給出了ESB系統的接口和交互標準，但并沒有給出具體的實現方法，例如如何應付高并發的業務請求。一些基于JBI的ESB系統采用部署集群的方式應對高并發的業務請求，但由于接入總線的外部Web Service服務本身的處理能有限，即便配置再多集群，對該服務的調用仍然是多種業務流對有限資源的競爭使用。還有一些系統基于SEDA （staged event－driven architecture）架構［8］。業務請求被放置在緩沖隊列中，采用先到先服務和盡力工作的服務策略。這兩種實現方式都沒有考慮到不同類型的業務對時效性的要求。當系統重載，總線發生業務擁塞時，所有的服務都處于等待狀態，系統服務質量迅速下降。

ESB作為一個集中式數據和服務交換平臺，需要處理大量的實時業務。實時業務對業務的執行時間有明確的時間約束。ESB應具備實時調度能力，盡可能地保證每個任務滿足他們的時間約束。一方面對外部請求做出及時響應，另一方面縮短系統平均響應時間，提高系統資源利用率。

2 實時企業服務總線模型

企業應用集成中有3種常見的業務類型，如表1所示。

表1 3種不同級別業務類型

為了使ESB系統能夠處理實時業務，對JBI標準進行改進，采用優先級驅動策略，按照業務優先級的高低動態分配各類業務流的帶寬。

首先為基于JBI的綁定組件增加兩個語義。其一是優先級Priority，取值為high，middle或low。其二是業務時間約束timeoutMS，單位為毫秒。當業務排隊等待時間超過該約束時，業務將返回超時錯誤。

＜http：soap－provider

service＝"hospital：DiagnoseServiceSOAPBinding"

wsdl＝"classpath：diagnoseService.wsdl"

priority＝"high"

timeoutMS＝"30000"/＞

接著擴展JBI的標準化消息路由組件，增加下列3個組件，如圖1所示。

（1）流量整形漏桶組件。該組件位于服務提供者組件和消息路由組件之間，采用漏桶算法 （leaky bucket，LB）對業務請求進行流量過濾和整形。如圖1所示，業務請求先被一個輸入緩沖隊列中，漏桶流控組件根據系統分配給該業務的流量帶寬將業務消息放入輸出緩沖隊列中供消息路由組件分發。如果業務請求因為擁塞排隊超過有效時間，漏桶流控組件直接返回超時錯誤消息給綁定組件。

（2）流量優先級調度組件。該組件位于服務消費者組件或服務引擎組件和消息路由組件之間。如圖1所示，該組件為每一個業務流建立一個傳輸隊列，消息路由將不同的業務流消息放入相應傳輸隊列中。調度組件使用加權公平隊列算法 （weighted fair queuing，WFQ）［9］，以分配給該業務的帶寬作為權重調度各業務流，將消息路由至其它服務消費者組件或服務引擎組件。WFQ和LB算法共同作用保證總線上各業務流量的穩定。

（3）消息路由組件。該組件定時與流量整形漏桶組件通信，實時獲取并記錄各業務輸入流量、業務超時和丟棄情況。當服務提供者組件發生流量擁塞時，該組件能根據總線當前流量情況動態調整分配各業務流帶寬。

圖1 實時企業服務總線消息處理

在實時ESB模型中，一次完整的業務流程序列如圖2所示。假設客戶端通過Web Service Client以同步方式調用HTTP/SOAP BC。該調用在進入總線后變成異步模式的消息。BC將SOAP協議的調用請求轉換成標準化消息，通過傳輸通道放入BC對應的LB組件的輸入緩沖隊列中。LB組件根據分配的流量按指定速率將消息發送給NMR。如果業務請求因為擁塞排隊超過有效時間，LB直接返回錯誤消息給BC。NMR將消息路由至目的BC對應的WFQ組件，放入相應業務流的緩沖隊列中。WFQ組件根據優先級調度算法將請求發送給消費者BC組件。消費者BC組件調用外部系統相應的接口后將消息直接返回給標準化消息路由，標準化消息路由將消息返回給業務發起的BC。BC將標準化消息轉換成SOAP協議后返回給阻塞的客戶端。

圖2 消息序列

3 總線業務實時調度算法

對ESB進行調度，本質上是對在總線上運行的業務工作流的調度。如果業務請求超過流程路徑上某個結點的處理能力，超過的請求就會在該瓶頸結點的緩沖隊列中排隊，一旦排隊時間超過該任務的時限約束，該業務將被終止，此時之前結點執行的所有業務均為無效，浪費了系統的處理資源。因此必須計算出流程所經路徑的最大處理能力，流量整形漏桶組件按照該速率將請求發送至總線內部，超出處理能力部分的請求直接在漏桶組件輸入緩沖隊列中排隊，避免浪費有限計算資源。

這里考察不同的集成模式結點對處理能力的影響。設結點業務處理時間為T，則結點的處理能力，即帶寬BW＝1/T每秒處理的事務 （transaction per second，TPS）。ESB中的業務流有4種常見的集成模式，如圖3所示。

圖3 動態帶寬分配算法

（1）管道模式。最基本的企業集成模式，業務按照順序依次通過各個結點。綁定組件、協議轉換服務引擎等組件均以管道方式工作。該模式下整個流程的處理能力由流程路徑所經過結點中帶寬最小的結點決定。如圖3中，業務帶寬BW＝min（BW1，BW2）。

（2）基于內容路由模式。根據業務請求的內容決定轉發的目標結點。由于此種轉發具有隨機性，因此計算結點帶寬必須考慮流程轉發到不同結點的概率。如圖3中所示，假設結點1轉到結點2、3的概率分別為p、q，則BW＝min（BW1/p，BW2/q）。

（3）接收列表模式。請求同時發送給若干個結點，相當于一種多播模式。為了保持各結點的處理同步，結點1的發送速率應為列表結點處理能力的最小值。即BW＝min（BW2，BW3，BW4）。

（4）聚合模式。匯聚同一業務來自多個結點的消息，匯聚完成后流程繼續執行。該模式和接收列表模式配對使用。BW2＝BW3＝BW4＝BW1/3。

采用流量工程的思想為ESB系統中的業務流量建立數學模型。考慮一個包含N條業務流的系統，三類業務流的數量分別為k，l，m。系統的總帶寬為BWtotal，其中第i條業務流所需的帶寬為BWirequired，系統實際為該業務流分配的帶寬為BWiallocate，該帶寬必須滿足以下3個約束：

（1）所有業務流均不能超過其經過路徑上結點的最大處理帶寬BWimax

（2）對于經過相同路徑的結點，其帶寬之和不能超過公共結點的最大處理帶寬

（3）對于第二類業務，為其分配的帶寬必須滿足業務的最小保證帶寬BWi2min。

帶寬分配算法如圖4所示。首先為第二類業務預先分配最小保證帶寬，以保證系統重載的情況下第二類業務不會出現完全拒絕服務。接著將剩余帶寬按業務流量需求分配給優先級最高的第一類帶寬。并根據約束 （1）（2）對分配帶寬進行修正。如果不滿足約束條件，將超出約束部分的流量按需求比例減少。在充分保證實時業務所需的帶寬后，將剩余帶寬繼續分配給優先級較高的第二類帶寬。同樣根據約束 （1）（2）對分配帶寬進行修正。最后將剩余的帶寬按業務流需求分配給第三類業務。

4 系統實例分析

下面闡述實時企業服務總線在區域醫療衛生信息集成系統中的典型應用。區域衛生信息集成交換平臺采用基于SOA信息服務總線的總體架構，通過數據集成服務、接入服務、總線服務等核心整合服務［10－15］，實現區域醫療衛生信息化平臺與醫療機構信息系統的交互。

圖4 動態帶寬分配算法

如圖5所示，本例中的區域衛生信息集成交換平臺，采用ESB總線，提供區域醫療的診斷服務、轉診服務和預約服務3種服務。服務對外提供Web Service綁定接口供門戶調用。3種服務需要訪問居民健康主索引 （MPI）和健康檔案信息 （EHR）兩個子系統，獲取居民基本健康信息、病歷、檢驗報告、檢查報告等各種衛生信息。還需要訪問醫療機構信息系統，進行轉診或預約。所有系統接口均為Web Service方式。系統中包含以下3個服務引擎實現3種服務流程的編排：

（1）診斷服務SE。接收用戶醫療服務請求，查詢居民電子健康檔案系統。用戶首先通過Web門戶訪問該服務的HTTP/SOAP BC，接著綁定組件將請求轉發給診斷服務引擎。診斷服務引擎會首先查詢該病人的健康索引，然后獲取他的健康檔案，供醫生診斷使用。就診業務是醫院最核心、最繁忙的業務。此類服務必須滿足實時性，具備最高的優先級，系統必須優先保證該業務帶寬需求。

（2）轉診服務SE。通過醫院信息系統與社區衛生服務系統的互聯互通，實現雙向轉診的功能。與診斷服務引擎一樣，轉診服務首先獲取病人的健康檔案，然后根據轉診服務規則選取合適的醫療機構，并向其發送轉診請求。該業務允許一定程度延時，是非實時業務，其優先級為中，當系統重載時需為該業務保留最低保證帶寬。

圖5 典型企業服務總線集成場景

（3）預約服務SE。利用醫院系統提供的對外服務接口，實現網上預約功能。預約服務引擎會向不同的醫療機構發出預約申請，醫療機構給出最快能受理的時間，引擎選擇最優的服務返回給用戶。這類業務不具備實時性，優先級低。當總線重載時可以將該服務占用的帶寬轉移給高優先級的服務使用。

圖6是圖5中業務流程的抽象網絡圖。圖中X、Y、Z是3種業務流程的發起結點。X是第一類業務類型，Y是第二類業務類型，Z是第三類業務類型。由前述定義可知系統業務流數量N＝3，每一類業務流的數量k＝l＝m＝1。A、B、C、D、E、F、G是業務流程中的處理結點，A表示調用病人主索引系統，B表示調用健康檔案系統，C表示轉診規則組件，D表示預約決策組件，E、F、G表示三家醫院信息系統。假設結點A業務處理能力為每秒500TPS，B為450TPS，C、D均為200TPS，E、F、G分別為40TPS、80TPS和100TPS。轉診業務發往3個醫院的概率分別為0.2、0.4和0.4。

圖6 總線服務流程抽象

首先計算三類業務流的流量約束，用字母代表該結點的最大處理流量，數量單位均為TPS：

（1）診斷業務。經過結點 A和B。則 A＝500，B＝450，根據式 （1）可得約束X≤300。

（2）轉診業務。經過結點A、B、C、EFG。A＝500，B＝450，C＝200，EFG＝200。同理可得Y≤100。

（3）預約業務。經過結點A、D、EFG。A＝500，D＝200，EFG＝40。同理可得Z≤40。

接著計算經過相同結點的業務流量的約束。結點X、Y、Z共享結點A，X和Y共享結點B，Y和Z共享結點EFG的帶寬。則可得

現分別考察系統在輕載和重載情況下三類業務實際分配到流量。

（1）系統輕載。假設X、Y、Z均為100。此時系統尚未達到最大處理能力，第一類業務可以得到充分響應，X的處理能力為100。此外Y和Z在EFG結點存在資源競爭，優先保證第二類業務的流量，即Y＝100，此時Y至E、F、G的流量分別為20、40、40。受醫院E的處理能力所限，Z只能獲得醫院E剩下的20帶寬。這樣三類業務所分配到的實際帶寬為100、100和20。

（2）系統重載。假設X、Y、Z均為300TPS。Y的最小保留帶寬為100。此時系統已經達到最大處理能力。先為Y預留100的保留帶寬。受B結點約束，X可以使用剩余的350帶寬，而X實際需要300帶寬，所以剩余的50帶寬重新分配給Y。此時結點E上的第二類業務流量為30，僅剩余10，將其全部分配給第三類業務服務。這樣三類業務所分配到的實際帶寬為300、200和10。

從以上對比中可以看出，系統在重載時能夠降低非實時業務處理帶寬，優先為實時業務分配足夠的處理帶寬，從而保證實時業務請求的及時響應。

5 結束語

針對現有ESB在不同類型業務流競爭有限帶寬資源時產生系統擁塞的問題，提出一種實時ESB模型。該模型能根據不同類型業務帶寬需求，采用優先級驅動的帶寬分配策略。以區域衛生信息集成交換平臺為例搭建了仿真環境。仿真結果表明一方面該方法能夠保證高優先級業務帶寬，滿足實時業務的需求；另一方面通過流量調度減少因業務擁塞導致的服務質量下降并提升ESB系統的總體吞吐率。今后的工作將繼續研究如何使用分布式ESB集群實現高性能、可擴展的實時信息集成平臺。

［1］SHAO Huanqing，KANG Jianchu.Research and application of enterprise service bus ［J］.Computer Engineering，2007，32（2）：220－222 （in Chinese）.［邵歡慶，康建初.企業服務總線的研究與應用 ［J］.計算機工程，2007，32 （2）：220－222.］

［2］LANG Jiong，LIU Yanbing，XIONG Shiyong.Data integration method based on SOA software architecture ［J］.Journal of Computer Applications，2010，30 （9）：2370－2373 （in Chinese）.［郎炯，劉宴兵，熊仕勇.基于SOA軟件架構的數據集成方法 ［J］.計算機應用，2010，30 （9）：2370－2373.］

［3］LI Xiaodong，YANG Yang，GUO Wencai.Data share－and－exchange platform based on ESB ［J］.Computer Engineering，2006，32 （21）：217－219 （in Chinese）.［李曉東，楊揚，郭文彩.基于企業服務總線的數據共享與交換平臺 ［J］.計算機工程，2006，32 （21）：217－219.］

［4］YU Wei，LIU Yong.Performance prediction of SOA based on ESB ［J］.Microelectronics ＆Computer，2009，26 （5）：110－113（in Chinese）.［余威，劉勇.基于ESB的SOA性能預測［J］.微電子學與計算機，2009，26 （5）：110－113.］

［5］CAI Haini，WEN Junhao，JI Kai.Performance optimization of col－laborative design network based on service－oriented architecture ［J］.Journal of Southwest Jiaotong University，2010，45 （4）：603－608（in Chinese）.［蔡海尼，文俊浩，姬楷.基于SOA的協同設計網絡性能優化 ［J］.西南交通大學學報，2010，45 （4）：603－608.］

［6］LIANG Wenzheng，SHEN Hao，XIA Tao，et al.Technique of enterprise service bus based on SOA－JBI ［J］.Information and Electronic Engineering，2009，7 （6）：593－596 （in Chinese）.［梁文錚，沈浩，夏濤，等.SOA架構下基于JBI的企業服務總線技術 ［J］.信息與電子工程，2009，7 （6）：593－596.］

［7］PENG Zheng，NIE Ruihua，LI Fei.Research and implementation of SOA based on ServiceMix ［J］.Computer Engineering＆Science，2009，31 （4）：153－156 （in Chinese）.［彭政，聶瑞華，李飛.基于ServiceMix的SOA架構的研究與實現 ［J］.計算機工程與科學，2009，31 （4）：153－156.］

［8］ZHANG Weining，LIU Liegen，ZHANG Yu.Research and application of ESB based on message transmission ［J］.Microcomputer Information，2008，24 （9）：18－20 （in Chinese）.［張偉寧，劉列根，張宇.基于消息傳遞的ESB的研究與應用［J］.微計算機信息，2008，24 （9）：18－20.］

［9］ZHONG Shan，YUE Xiang.WFQ traffic scheduling algorithm［J］.Study on Optical Communications，2006，32 （5）：16－18（in Chinese）. ［鐘山，岳祥.WFQ流量調度算法研究 ［J］.光通信研究，2006，32 （5）：16－18.］

［10］YANG Hongqiao，BU Haibing.Design of regional medical information system based on ontology ［J］.Computer Engineering，2009，35 （11）：283－284 （in Chinese）. ［楊宏橋，卜海兵.基于本體的區域醫療信息系統設計 ［J］.計算機工程，2009，35 （11）：283－284.］

［11］WANG Shuai，SU Wei.The current situation and existing problems for the Chinese regional medical informatics and its corresding strategies ［J］. Modern Preventive Medicine，2010，37 （22）：4241－4243 （in Chinese）. ［王帥，蘇維.我國區域醫療信息化發展現狀、存在問題及對策研究 ［J］.現代預防醫學，2010，37 （22）：4241－4243.］

［12］LI Wei，JIANG Qisheng.Research of SOA－based information exchanging and sharing platform for regional medical institutions ［J］.Chinese Medical Equipment Journal，2010，31（11）：79－81 （in Chinese）. ［李偉，江其生.基于SOA 架構的區域醫療機構信息交換與共享平臺的研究 ［J］.醫療衛生裝備，2010，31 （11）：79－81.］

［13］ZHOU Jinhai，YIN Zhihong.Resource sharing strategy of regional medical information and images digitalization ［J］.Journal of Clinical Rehabilitative Tissue Engineering Research，2010，14 （48）：9069－9072 （in Chinese）.［周金海，印志鴻.區域醫療衛生信息及影像數字化資源的共享戰略 ［J］.中國組織工程研究與臨床康復，2010，14 （48）：9069－9072.］

［14］WU Ruming，XIN Xiaoxia，ZOU Saide.Research and realization of regional medical information sharing platform ［J］.Journal of Medical Informatics，2011，32 （1）：19－23 （in Chinese）.［吳汝明，辛小霞，鄒賽德.區域醫療信息共享平臺研究 與實現 ［J］.醫學信 息學雜 志，2011，32 （1）：19－23.］

［15］CHEN Haidong，SONG Yu，YU Saiyu.Design of regional medical information system ［J］.Military Medical Journal of Southeast China，2011，13 （1）：283－284 （in Chinese）.［陳海東，宋斌，余賽玉，等.區域醫療信息系統的設計 ［J］.東南國防醫藥，2011，13 （1）：283－284.］