实时SOA从消息总线开始

　　面向服务的架构(Service Oriented Architectures)被越来越多地应用于实现高性能的实时系统。传统系统是基于“人类实时”，受到人耐性的限制。然而，越来越多的系统开始运行于“计算机实时”环境下，这里唯一的限制是计算机和网络的速度。

　　比如，正在开发中的新一代空中交通管理（Air Traffic Management）系统，是为了调整日益繁忙的航线，并连接各客户端（比如美国联邦航空管理局、国防部及国土安全部）的工作。这些系统需要更高的信息带宽用于追踪更多的飞行器和更复杂的“自由飞行”轨迹，同时需要更快的信息响应速度以更快地检测飞行异常。其它方面也有类似的需求，比如医疗保健系统、数据采集与监控（SCADA）系统、网络监控系统、能源分布系统、运输系统，以及其它关键基础设施系统。

　　SOA组件的最佳组合

　　实时应用程序需要面向服务的基础组件的最佳组合。SOA系统有三种基础组件：消息总线、信息转换/处理引擎和数据存储库（见图1）。一般来说，这些组件会集成到企业服务总线中（ESB），并使用J2EE应用程序服务器。

　　图1

　　而在这些基础组件中，消息总线是最重要的，因为它是所有其它组件交互的中介。

　　低性能的SOA系统或许会使用HTTP协议作为“消息总线”实现各组件间的消息交换。这种方案只适用于非实时应用程序。HTTP协议缺乏可靠性、带宽有限、延迟大，并且在系统暂时无法使用时不能提供缓冲或消息队列以延时递交。

　　解决方案是采用高性能的消息中间件，比如RTI Data-Distribution Service、IBM WebSphere MQ、TIBCO或SonicMQ等。这些中间件平台在开发时充分考虑了可扩展性和表现性能。而且，它们为不同的应用方案采用不同的优化架构。

　　为什么消息性能很重要？

　　这是计算机实时超越人类实时的需求与期望。若系统中存在人类这一环节，实时即指信息可以在一秒到几秒反应时间内随时可取；而在计算机到计算机环境中，却必须以毫秒甚至微秒级别的速度处理信息。

　　计算机实时对消息基础设施的要求更为严格：每个处理组件和存储组件每秒都会收到几十万的消息或事件，延迟不能超过微秒级别，最差不能超过毫秒级别。这意味着消息中间件必须可以在系统范围内每秒传送几百万的消息。

　　消息总线的负载能力也必须满足基础硬件设施的负载要求，并且不能在基础硬件设施的限制（中央处理器速度、核心、速度和网络带宽）外再有其它限制。随着中央处理器和网络速度的提升，那些可以因硬件升级而提升性能的系统将获得更大的竞争优势。比如，在一个自动交易系统中，决定性因素并不是判定交易所用的绝对时间，而是要在竞争交易发生前做出判定并执行。

　　关于计算机实时，SOA系统的最后一个问题是，它们的“反向性能负载效应曲线”，也就是系统在高负载下运作时的及时响应能力非常重要。一般的效应曲线，比如人类实时系统，由于负载的加重而使性能有所下降是可以接受的。这是因为人类的期望与耐性是随情况改变的，比如，人们明白在度假高峰期预定机票必须忍受较长的等待时间。而对计算机实时系统的要求却与此相反。高负载时期正是“最关键业务”发生的时期，也是需要系统表现最佳性能的关键时期。比如，业务繁忙时必须更快地处理交易判定。

　　人类实时系统与计算机度实时系统的区别在表1中做了概要说明。

　　表1

　　为实时SOA选择消息中间件

　　消息中间件是实时SOA系统的实现关键。虽然如此，仍然有许多问题需要考虑。如何为实时SOA系统选择最佳的消息中间件呢？可以从架构、服务质量（QoS）控制与过滤器、性能提升技术、实时判定机制和度量指标五个方面考虑。

　　1. 架构

　　消息中间件有四种基本架构：星型拓扑（hub-and-spoke）架构、集群拓扑架构、联合架构和对等架构（peer-to-peer）。（见图2）

　　图2

　　星型拓扑架构用一个服务器作为消息交换的路由，实现包含所有消息队列的消息“服务”。

　　集群拓扑架构使用一组服务器，分别处理不同种类的消息（比如消息队列或主题所有权）。每条消息通过一个服务器，但不是所有消息都用同一个服务器。

　　联合架构也使用一组服务器，但这组服务器是作为“资源库”使用。比如，消息队列可以出现在多个服务器中。消息可能只经过一个服务器代理，也可能经过多个服务器代理。

　　对等架构不在传输路径中使用任何代理。消息直接从发送方传向接收方。

　　各种架构都有其优缺点。星型拓扑型容易管理，便于操作，但表现性能、容错率和可扩展性比较差。集群架构可扩展性比星型架构好，但容错性同样较差，并且只能在网格范围内为附近的客户端提供较好的表现性能。联合架构的扩展性更好一些，但其延迟更大，因为每条消息都要经过至少两个服务器的代理。对等架构提供了最好的可扩展性、表现性能，最低的延迟和最高的容错率，但实现起来很困难，并且对业务的支持有限。

　　随着需求越来越具实时性，对性能、可预见性和平衡的要求越来越倾向于对等架构。这就是为什么像IP语音通信和IP视频传播（比如Skype）之类的需求网络会采用对等的设计方案。

　　2. 服务质量控制与过滤器

　　服务质量控制是以低延迟、高处理能力提供及时数据的关键。中央处理器、内存和网络带宽资源必须在所有通信过程中共享。然而，并不是所有的通信都需要相同的带宽或有相同的紧急性和重要性。如果没有服务质量控制，应用程序就无法分辨不同的信息类别和反应需求。这会导致中间件不能灵活地做出判定，对信息进行优化处理或满足应用需求。

　　比如，使用TCP协议（传输控制协议）的传统网络环境中，一个小而紧急的警告消息可能在TCP连接中被排在一个较大的文件传输后面。因为TCP无视消息源，并稳定有序地传输每一个字节。这个警告消息只有在传完整个文件之后才能被成功接收到。可以假想在广域网（WAN）中转播直播节目的情况。网络阻塞可能会造成图像丢失；由于没有服务质量控制，中间件就会继续查找丢失的图像，而不是选择传送最新的图像。这样就不只是丢失几张图片的问题，极有可能图像会冻结，直到成功取得丢失的图像。所以，即使硬件可以提供不错的表现性能，系统的整体性能仍然大打折扣。

　　为实现计算机速度的实时性能，消息中间件必须至少满足以下服务质量控制要求：稳定性、缓冲计算、流量控制、生命周期、历史记录和传输优先级。（见表2）

　　表2

　　过滤功能是系统扩展性与表现性能的关键。支持过滤的中间件可以只为各组件传送最重要的内容，这可以节省大量网络带宽和CPU资源，使系统可以处理更多的信息。比如，事件处理引擎可能会查找关系到某些计算机或网络单元，或者属于某种协议的网络活动。中间件并不会将所有网络事件都传送到引擎，并让引擎过滤掉不相关数据，而是先进行过滤处理，然后再发送相关数据，这样可为事件处理引擎节省网络带宽与CPU资源。

　　主要有两种过滤器：一种是基于时间的，另一种是基于内容的。基于时间的过滤器会限制信息频率，比如每秒最多允许发送10次更新信息。基于时间的过滤器对应用程序非常有用，例如以人为本的仪表板，只需要获得走向与概要信息即可。

　　基于内容的过滤器从内容上对信息进行简化处理。举例来说，一个显示程序可能只关心接近机场的飞机位置。基于内容的过滤器就会筛选出所有离机场很远的飞机。

　　3. 性能提升技术

　　一辆无论构造多么合理的汽车，如果没有强力的引擎就不可能发挥出优良的性能。同样，消息中间件也需要一些特征与技术以获得最佳性能。其中以下方面最为重要：组播技术、消息批处理功能、消息分段技术、异步远程拷贝和传送过程中的零拷贝访问。

　　4. 实时判定机制

　　实时并不是简单的速度快而已。为实现稳定的实时，系统必须同时稳定而高速。实时判定机制决定了每次系统运算时的稳定性。一个实时判定系统必须在每个运算上花费同样的时间。

　　然而，并不是你做的那些事决定实时操作能力，而是你不做的那些事决定了实时操作能力。因此，实时的满足需要处理器、资源定位和管理上的稳定性与一致性。内存分配、等待周期、关闭中断或者其它的任何程序操作都会引发无法预料的行为。为保证稳定性，每个操作必须以同样的方式同样的时间进行。对于一个包含多个步骤的操作，每一步都必须是可靠的，因为其中可能包含不可靠的信息。如果某一步是不可靠的，那整个操作链都会变为不可靠的。

　　因为基础硬件设施一般都是非常稳定的，因此系统的不确定因素源一般在操作系统、中间件或应用逻辑/代码中。实时操作系统是一项大受好评的技术。应用程序必须本着传送稳定结果的理念进行设计。然而，在许多系统中，中间件是实时运算的关键。

　　这意味着在实际应用中消息中间件必须：

　　使用异步操作技术而非阻塞操作。多线程技术为并发和多核架构提供了机会。

　　使用多线程技术并发处理紧急任务。仔细挑选架构与优先技术以避免线程冲突，并使用看门狗（watchdogs）和延时设定（timeouts）监控和维持应用程序正常运行。

　　在稳定的基础设施上执行（实时操作系统、实时Java虚拟机，实时中间件组件）。

　　谨慎地控制资源。控制动态内存的使用，限制关键路径外的内存分配。

　　进行任何存储访问时尽量使用内存缓存而非直接进行磁盘操作。

　　为中间件的可编程应用扩展提供“进程内（in-process）”机制，比如加载DLL文件或Java类。

　　5. 度量指标

　　可以认为，优秀的度量指标是决定中间件最终性能的唯一条件。然而，定义消息中间件的特征远比看起来复杂得多。

　　大多厂商只提供一些关于消息处理能力的信息，类似每秒处理多少消息或字节等。还有少数厂商提供关于延迟的测试数据（从发送方到接收方的端对端延迟）。几乎没有厂商会提供关于可扩展性和不稳定同步的度量指标，包括随着系统发展性能的变化、负载增加，或者消息之间的变更。并且，这些结果很大程度上依赖于计算机和网络硬件设施，以及测试方案。

　　比如，厂商可能会提供关于执行时间和处理能力的数据，声称他们的产品可以以低于0.5毫秒的时间完成一条消息的传送，并可以每秒传送1000000条消息，但并不会指出是否可以用一个应用程序同时完成这两项任务。甚至，都不会指明这个执行时间是否代表理想情况下的最佳性能，是平均时间还是可以保证大部分消息（比如99.99%）在这个时间内传送等。消息容量和内容类型（不透明的字节、字符串或复合类型）都有极大的影响。比如，如果指的是没有实际意义的四个字节的消息，“条/秒”也就没多少参考价值。如果不考虑类型转换（marshaling，一种称为列集转换方式），每秒多少字节的数据也没有意义。比如，传送raw XML字符串的低效率数据转换方式可以每秒传送许多字节。然而，使用经过压缩处理的XML语言或二进制格式的高效转换方式在传送实际消息时要快得多。这种例子数不胜数。

　　既然不存在标准的实时中间件性能的测试程序，我们就只有以下选择：依靠厂商给的数据，开发自己的度量标准，以及通过使用中间件的应用程序来进行判断。第一个过于模糊，第二个费时且成本高，而第三个是主观判断。

　　通过上面的说明，了解以下指标可能会有助于评估中间件的性能，并可最低限度地从提供实时SOA系统的厂商处获得如下信息：基于消息容量的处理能力、基于CPU使用情况的处理能力、消息批处理能力和基于稳定性的最佳表现；基于消息内容的执行时间、基于处理能力的执行时间等。

　　比如，图3到图7显示了两种不同中间件架构处理能力与执行时间的比较图：一个星型构架（JMS）和一个对等结构的网络（DDS）。

　　可以参考由RTI Data Distribution Service(运行环境数据分发服务)提供的更多详细的数据。运行平台是使用2GHz双核AMD皓龙的计算机，操作系统是红帽Linux4.0企业版。