实时企业服务总线的研究与设计

夏纯中，宋顺林

（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.］