实时SOA到底是什么（上）

[align=center]Stan Schneider[/align][align=center]美国RTI公司CEO，斯坦福博士[/align][align=center]概述[/align][align=center]
[/align][align=center]随着实时分布式系统复杂度的不断增加和研发规模的迅速扩大，系统集成的难度和风险都在大幅提高。不同阶段独立研发的各大系统之间需要集成，我们通常称为“系统中的系统”。众所周知，企业级系统通过SOA，即面向服务构架来加强集成。然而，企业级的技术并不能完全满足实时系统的要求，特别是对时间控制有严格要求的系统。[/align][align=center]这就引申出另一个概念，就是所谓的“实时SOA”。那究竟什么是实时SOA呢？理想情况下，它类似与企业级SOA，其体系结构可以有效地整合和集成各大系统。与企业级SOA不同的是实时SOA可以处理对时间要求极高的实时系统，并利用企业级技术将他们相互连接起来。对象管理组织（OMG）的数据分发服务器（DDS）标准为实时SOA提供了合适的框架。但作为一个对等的协议，DDS无法自动整合多个系统，这就需要在各DDS系统之间运用正确的协议和其它整合技术，才能够连接不同团队构建的独立系统并集成多种应用。[/align][align=center]本文简述了如何运用SOA原则建立一个快速实时分布式系统，该系统基于DDS标准和技术，并包括实时和企业级的功能。[/align][align=center]集成的重要性[/align][align=center]
[/align][align=center]2006年11月2日，美国海军有意炸沉“福吉谷”号宙斯盾巡洋舰，这艘只服务了18年的第四代巡洋舰的设计寿命至少为30年，那究竟发生了什么使得美军要主动销毁它呢？这艘巡洋舰的船体设计是合理的，发动机和主要设备也能够正常工作，问题只是在于系统软件无法升级到新的技术和现代武器系统。这是一个令人震惊的事实：系统软件升级的代价已经超过了保留10亿美元的资产1。[/align][align=center]为什么会这样？众所周知，复杂系统的集成是十分困难的，协调不同子系统的开发团队更是一项挑战。在过去，唯一的办法就是把整个系统的开发采用“烟囱式（STOVEPIPING）”垂直管理和运作模式。 这种模式成本巨大，更糟的是它还不鼓励可扩展的设计，导致集成和维护成本直线上升。从宙斯盾巡洋舰这个事件中可以看出，集成和维护的成本超过了船体本身，而这并不是偶然的特例。在很多行业中，实时系统集成的成本无法控制。[/align][align=center]这种状况再也不能继续下去了！[/align][align=center]系统集成的问题[/align][align=center]
[/align][align=center]系统集成的成本和风险随着系统和团队规模的扩大而不断增加。小型团队不需要太多的协调工作，比如一个团队只有10个程序员，他们只需每周例会，审查进展情况、检查接口和设计的变更等。100个人的团队则必须分成若干小组，文件设计、审查和项目管理也逐渐变得很重要。[/align][align=center]随着团队规模的增加，公司面临的压力是争取并完成更大的项目。该项目可能包括多个公司和组织之间的协作。在这种情况下，接口便成为谈判的细节，技术选择也变得十分困难，整个团队的设计审查成为关键。系统集成的成本大大增加，尤其是前期工作的开销。细小的变动也需要细致的文件备份和进度控制，甚至追加费用。[/align][align=center]如果还要考虑时间因素，则问题将变得更为复杂。大型系统的开发和维护通常需要跨越多个时间段，这意味着旧的技术和设计必须以某种方式保留与新版本的良好接口，否则可能带来严重后果。企图开发无需升级的“定制”软件（类似开源的诱惑）是错误的想法，如果原有软件无法更新到最新的平台，所有相关的技术都必须改变。“重用”是一个永远难以实现的梦想。与升级不同，承包商通过看似简单的更新收取了数亿美元的费用。[/align][align=center]简而言之，大型系统集成的成本极大并对系统维护有着极大的影响。[/align][align=center]
[/align][align=center]图1: 集成成本随系统增大[/align][align=center]集成规模随着系统增大迅速膨胀，构建和维护大系统的成本和风险完全由集成主导。[/align][align=center]耦合性问题[/align][align=center]
[/align][align=center]系统集成为何如此重要？根本原因在于系统是由很多模块组成的，而这些模块由不同的小组设计。当一个团队变大时，协调和交流就变得十分困难。大型团队构建的系统只能由独立设计、实施和管理的子系统组成，显然这并不容易。[/align][align=center]实时系统的集成[/align][align=center]
[/align][align=center]我们的第一个挑战是用独立设计的模块构建高性能的实时分布式系统。[/align][align=center]图2显示了典型的传统设计模式，即运用“客户端/服务器”或“远程对象”技术，如CORBA、ODBC、RMA、OPC等。在开发过程中，首先必须确定系统功能，然后再设计每一条信息访问方法和接口。这些数据“隐藏”在各个对象背后，每个设备或端点数据处理的要求事后进行。这种设计假定网络是相对静态的，服务器总是存在和可访问，服务器/客户端关系明确，客户知道在何处、更重要的是何时申请数据，所有应用都有类似的交付要求。它还假定一个“同步”处理的模式，客户端请求服务器，然后等待答复。但随着系统复杂度的增加，这个以“服务器为中心”的设计很容易崩溃，而且这种设计使得增加新的系统或数据（图2中红色线）非常困难。每个服务器通常还和各自的客户端耦合，除非现有的接口能够提供所需的一切信息，否则每个与新的数据有关系的接口都必须重新设计。[/align][align=center]
[/align][align=center]图2：传统OO设计的紧耦合网络[/align][align=center]传统技术需要开发人员定义为每个函数访问方法，然后实现服务器和其它特殊接口。这导致“意大利面条”式的网络设计和“烟囱式”的系统。[/align][align=center]图3描述的是一种以数据中心的设计方法。这种设计方法仅需要开发人员定义各个子系统数据的输入和输出，这与前面隐藏数据的方法正好相反，这种方式中信息流影响着每个模块。[/align][align=center]这种中间件能够自动发现信息发布者和接收者，并即时提供所需要的数据。这种“以数据为中心的发布/订阅”设计模式消除了耦合，大大简化了苛刻或复杂系统对数据共享需求的集成难度。因此，对象管理组织（OMG）迅速制定了数据分发服务（DDS）标准，并很快在很多系统中得到了广泛应用。在全球，大部分军事系统的集成技术都采用了DDS。它还在金融贸易、自动驾驶辅助系统、空中交通控制和能源等行业得到了广泛和成功的应用。[/align][align=center]
[/align][align=center]图3：以数据为中心的设计引入虚拟“总线” 概念[/align][align=center]以数据为中心的发布/订阅模式清晰地定义了接口和模型信息。有了清晰的接口，各个部件很容易接入“数据总线”。[/align][align=center]新的应用带来的问题[/align][align=center]
[/align][align=center]DDS最主要的优点是可以在原来系统中“插入”新的应用而无需重新设计其它接口（图中红线）。这看起来简单，但做到这一点却很困难。拥有一个可插入的接口需要假定“总线”能够捕获全部关键的实时性要求，比如数据是何种类型？何时能够获取？何时发出？如果不能及时得到将会发生什么？数据是否已经备份？这些数据如何接入？而且这还基于一个假设，即使增加更多的负载将不会影响整个系统的性能，如果能做到这样，应用之间不再直接关联。这便是一个隐含的松耦合类型。[/align][align=center]从更高层面看，DDS的数据总线参与者只需订阅他们需要的信息，并发布他们产生的信息。在这里，信息也称为“主题”，具有安全性以及容易集成的特点。中间件自动“发现”新的加入者，它们之间的数据通信在信息流开始之前就已完成，所有的应用都知道他们将获取什么（被称为“内容预知”）。由于数据流无需经过服务器或同步等延迟，该系统能够满足快速和实时性的要求。DDS的无疑是性能最高的中间件3。[/align][align=center]DDS成功的关键在于它定义了清晰的信息模型。如果你定义的信息模型正确，那么各个应用在设计时就可以明确他们的需要。在运行时，他们又通过发布/订阅模式的中间件实现。这些模块并不直接相互依赖，而这是避免耦合的关键。这些应用通常采用自适应模式。其它信息技术（例如JMS）不能做到这一点，因为他们无法定义类似的信息模型4。[/align][align=center]DDS启用了20多个“服务质量（QoS）”策略来定义信息模型。 QoS策略设置了信息发布者是否能提供可靠的信息流、发布数据的速度有多快、你希望何时发现数据。各个应用可以通过QoS明确其需求，甚至可以做到通过时间或信息的内容来筛选更新信息。中间件还能“听到”新加入者的需求，并决定发布者是否能满足这些需求。如果可以，中间件会在发布者和应用之间建立“合约”，并开始发送数据。如果不可以，它会报告发生了一个错误。例如，一个合约以是这样：发布者将以毫秒级的速度更新订阅者，而且是可靠的通信方式，如果传输发生错误请重新发送，一旦发布者失败，就可以切换到备份数据。[/align][align=center]这只是其中的一个例子，实际上DDS的QoS策略可以集成数以百计的复杂且苛刻的应用。由于中间件能够做出快速反应，使得通过这样的设置来满足苛刻的实时系统成为可能。实际应用的DDS系统在数以百万对订阅和发布者之间发送每秒钟数百万的消息，而延迟仅有几十微秒。设计人员可以提出时间要求，以支持有明确发送需求的程序。可靠的多播模式可确保新的“外挂程式”不对程序造成负担。它还具有很好的排列功能，可以部署在多达1000台计算机的系统里。DDS尤其适用于对不间断、可靠性有很高要求的应用中，类似作战管理系统或在电网管理系统等应用。[/align][align=center]在雷达中的应用[/align][align=center]
[/align][align=center]QoS策略是建立在每个数据传输路径基础上。以高速雷达为例，它需要向许多不同的订阅者发布雷达轨迹，为了能够追踪来袭的导弹，它必须向武器系统发送每秒2000多次的更新。对于这个订阅者来说，它需要最新的数据，因此如果由于传输错误造成样本丢失，不要浪费时间重发旧的数据。与此同时，日志系统需要雷达提供一切追踪数据以备以后分析，这些数据可能还需要多播到50个显控屏幕上，但这些控制屏每秒钟只能采样10个样本。每个屏幕可进一步选择其感兴趣的区域，比如只显示5英里范围内、朝我方行进并且是已经确认为敌方的雷达轨迹。[/align][align=center]DDS可以在同一时间内处理上述所有情况，而这也只是一小部分。因为中间件帮你解决了所有这些问题，应用程序只需要集中在逻辑和处理部分，大大降低了系统设计的工作量，而且中间件在处理这些问题时不会影响应用程序。你可以想象这对应用开发和集成起到了多大的简化作用。现在，假如这一切都正常运行，然后我们需要添加一个新功能。例如，我们需要用雷达来协调在本地区的航空交通。由于每个功能都有清晰的定义，我们不需要改变任何原有的应用，新的应用程序只是插入“数据总线”便能开始工作。[/align][align=center]当然，这些功能的前提是不受加载中间件的影响。 DDS对系统的影响各有不同，但对那些设置了点对点对等可靠多播的用户很少会受到较高负载的影响。使用得当的话，DDS比其它中间件的速度要快得多。除此之外，QoS策略还增加了故障检测层。如果新的负荷引起超载，中间件将立即通知其它应用程序：他们的合约出现了问题。这有助于早期发现设计问题，尤其是在系统测试中。不仅如此，它也允许运行中的系统在发生上述情况下采取有效的补救行动。[/align]