实时SOA从消息总线开始

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企业版。

图3

图4

图5

图6

图7

总结

    要想赢，就必须给赛车安装最好的组件。同样，性能关键的SOA系统也必须建立在消息处理、事件处理引擎和数据库的最佳组合上。在这些SOA基础组件中，消息中间件是最重要的，因为它是所有其它组件的交互中介。
    如何确定最好的中间件呢？
    首先，考虑架构。选择最符合需求的架构。架构不合适，系统就不可能有优良的表现性能。
    其次，选择满足需求的服务质量控制。对网络和数据传送的有效控制将极大地影响到所有组件的工作效率。
    第三，选择适合应用程序的、包含性能提升技术的中间件。比如组播技术，就可以在同等负载下极大地提高网络的“扇出(fan out)”能力。
    第四，如果系统必须在一定状况下保持性能稳定，那就在设计方案中保证至少关键组件可以在这些实时环境中稳定运行。没有其它可以保证系统稳定响应的途径。
    最后，基于以上了解，选择包含对应用程序最为重要的指标的中间件。
    明白了以上所有因素，你就离建立最佳性能的SOA系统更接近了一步。

    Gerardo Pardo-Castellote博士，现任Real-Time Innovations公司CTO。