Oswald Regular
OpenSans Regular
Continuous>Flows

实时业务数据处理是一项很艰巨的任务,很少有软件产品能实际达到要求。Ab Initio 却能实实在在地做到这一点。

只通过一种技术,Ab Initio 就能解决种类繁多的应用程序的功能需求,这就是 Co>Operating System 的 Continuous>Flows,无论是“微型批处理”还是数量庞大的“异步消息传递”,或是面向服务的应用程序 (SOA),乃至低延迟的“请求/响应”应用程序,都能从中受益。

Co>Operating System 是一个“数据流引擎”。该引擎通过一系列的“组件”传送记录流或交易数据。每一个组件都对输入记录进行各种计算(例如应用业务规则)以生成输出记录。复杂的处理逻辑被分解为简单易懂的步骤,每个步骤都由不同组件加以实施。每一条记录流都经沿途各个组件,直至处理完成。

数据流模型同时适用于批处理和实时处理。大部分批处理和其对应实时应用程序都十分相似,端点组件确定应用程序的类型是批处理还是实时。批处理应用程序连接平面文件和静态数据库表组件。而实时应用程序则连接消息队列、web 服务、RPC、CICS 和/或特殊用途组件(通常通过 TCP/socket 连接)。

由于批处理和实时应用程序极度相似,两者都使用 Ab Initio 的 Co>Operating System 技术,大大降低应用程序设计的复杂性,并且获取较高的性能。复杂程度的降低意味着效率的提升,而效率提升则表明实实在在的成本节省。

在批处理和实时应用程序之间重复使用业务逻辑

多数情况下,输入和输出组件之间的业务逻辑组件保持不变,这意味着可以在批处理和实时应用程序之间重复使用业务逻辑,极大地促进了工作效率。其他批处理和实时处理所用的技术和方法差异极大,从批处理转向实时的过程中需要多次重新实施相同的业务逻辑。使用 Ab Initio,您只需开发一次业务逻辑,插入 Ab Initio 的批处理和实时体系结构即可:

获取不同实时执行模型的性能

如何处理相互冲突的性能要求是应用程序架构所面临的一大难题。

  • 批处理应用程序要求尽可能高效地处理数据。批处理作业要处理相当多的交易,所以运行时间一般较长,并且只有在作业完成后才会产生结果。但在其运行时,用户希望每秒可以处理大量记录。
  • “微型批处理”应用程序汇集一组批处理作业。虽然每个批处理作业处理的数据量较少。但是,这些小型作业的数量可能非常巨大,每天可能运行数以千计或万计的这类小型作业。如果限制每个作业处理的数据量,则可将其响应时间降至最少。这种方式还能让相同的应用程序利用传统批处理设置有效处理海量数据。(每天处理数以万计的作业方式自身复杂性极高,Ab Initio 的 Conduct>It 可以解决这些问题。)
  • 异步消息传递应用程序连接消息队列,并且需要尽可能高效地处理交易数据。但是,下游系统通常希望在几秒到几十秒的时间内得到其响应消息。为实现对交互使用的支持,异步应用程序应该在一秒或两秒内给出响应。
  • “请求/响应”或同步消息传递应用程序需要交易数据一经出现就立即进行处理,并尽快响应,延迟通常不超过 1 秒。如果多个这样的应用程序合作处理交易数据,每个应用程序就需要在十分之几或百分之几秒内给出响应。Ab Initio 在几十毫秒内可靠处理有意义的工作单元,从而完美而直接地解决了这一问题(与一些已达到极限的专用系统形成鲜明对比)。

Ab Initio Co>Operating System 的 Continuous>Flows 是有效所有模式中的唯一技术。这得益于 Co>Operating System 的架构从一开始就以满足所有不同模式下全部要求而构建。

在 Ab Initio,批处理(包括微型批处理)和实时应用程序有两大主要区别:

  • 终止方式:批处理应用程序在处理完其输入所有数据后即终止。终止后,批处理应用程序与任何系统资源均不再有任何关联。

    而实时应用程序一旦启动,就会无限期地接收和处理进入输入的交易数据。如果新交易数据流中出现暂停,实时应用程序就会等待,直到新的交易数据出现。

  • 检查点操作和恢复:批处理应用程序在应用程序预设位置处取得检查点,所有通过这些位置的数据均会被保存到磁盘(否则就是检查点提取失败)。程序恢复意味着在上一个成功的检查点重新启动应用程序。

    实时应用程序在交易数据之间提取检查点,可频繁地对每个交易数据都设立检查点,也可以根据其他标准(如所用时间或交易数据数量)延长频率。重新启动的应用程序自动返回成功执行的上一检查点交易数据。

Continuous>Flows 提供与各种实时系统的连接

Ab Initio 的 Continuous>Flows 为多种实时系统提供接口:

  • 第三方队列系统:IBM MQ、JMS、TIBCO Rendezvous 和 Microsoft MQ。Ab Initio 为直接连接所有这些队列系统提供了组件
  • Web 服务:WebSphere、WebLogic、IIS 和 Apache/Tomcat
  • Ab Initio 队列和 RPC,用于在 Ab Initio 应用程序之间建立大量低延迟的点到点连接
  • 遗留/内部的消息传递软件

对 Web 服务和 SOA 的原生支持

Ab Initio 应用程序可以轻松在面向服务体系结构 (SOA) 中实现 Web 服务。这项任务由 Ab Initio 提供的 Servlet 完成,安装在客户选择的标准应用程序服务器中(WebSphere、WebLogic、IIS 或 Apache/Tomcat)。Servlet 提供注册机制,用于将特殊的 Web 服务呼叫与特定的 Ab Initio 应用程序关联到一起。Web 服务呼叫传入时,Servlet 通过 TCP 与 Ab Initio 应用程序通信(Ab Initio 应用程序在应用程序服务器之外运行自身的一组进程),并将 Ab Initio 应用程序返回的结果返给原始请求方。

Co>Operating System 完全支持 WSDL 定义的消息。

实现与特殊用途和遗留的消息传递系统的接口

商用队列产品和 Web 服务是行业内相对较新的技术,性能一般。如果消息量很大,或现有商用队列产品不能满足要求,用户通常自行构建高性能消息的传递解决方案。

通过特殊处理组件(Universal Subscribe 和 Universal Publish),Continuous>Flows 为遗留的解决方案提供可靠而稳定的接口。这些组件调用定制的 C++ 子例程,与遗留的消息传递系统连接。出现故障时,这些组件执行回滚和恢复任务。

Ab Initio 与用于特殊用途的消息传递系统合作产生极高性能,在关键任务应用程序中,每秒能稳定处理 500,000 多条消息。

此外,Universal Subscribe 和 Universal Publish 组件与针对第三方队列产品的 Continuous>Flows 组件使用方式相同。这样,用户从内部队列解决方案转为第三方队列产品时,只需对其 Ab Initio 应用程序做极少量的修改,即可投入使用。

可靠而稳定的故障处理能力

Co>Operating System 的检查点操作产品能够可靠处理应用程序故障。应用程序利用检查点向多个数据库和输入/输出系统(队列)提交更改。如果应用程序出现故障,Co>Operating System 将环境“回滚”到上次成功执行的检查点。主要故障(数据库拒绝加载、磁盘空间不足、网络故障等)解决后,应用程序会重新启动,并自动返回上次成功处理的交易数据所在位置。

从计算角度讲,大部分检查点操作架构的代价过高,开发人员尽其所能降低这种成本,却往往导致应用程序复杂且不稳定。Co>Operating System 架构既有极高的性能,而且稳定、可靠。Co>Operating System 提供了一系列的检查点操作方案,用于抵消交易数据相对恢复时间产生的延迟。任何情况下,Co>Operating System 都能保证一次性写入全部交易数据,而且只向所有目标设备(数据库、文件和队列)写入一次。

Co>Operating System 提供两种基本的检查点操作机制。两阶段提交的 XA 标准协议在业界声名远扬。Co>Operating System 内含一个交易管理器,协调不同数据库和队列产品之间的传递,甚至可将多个交易合并成一次提交,从而提高吞吐量。

但是,XA 也有其局限性:计算成本高,管理复杂,而且并非所有适用输入和输出设备都支持这种协议。因此,大部分 Ab Initio 都采用 Co>Operating System 原生的检查点操作机制,该机制与两阶段提交极为类似,能与 Ab Initio 连接的所有输入和输出设备(数据库、文件和队列)配合,可以跨异构和分布服务器工作,并且极其高效、可靠。Ab Initio 甚至在其连接器组件中构建了弥补某些第三方队列产品局限性的措施。例如,某些产品的队列管理器崩溃会导致多次传送交易数据,Ab Initio 合理解决了这一问题。

通过 Co>Operating System 原生的检查点系统,开发人员可用多种手段控制检查点的频率,例如交易数据数量和操作时间、交易数据结果(比如消息流中特殊令牌导致事件)等。此外,开发人员还可以控制多个输出设备间交易数据在检查点处的一致程度。默认设置就有很高的性能,保证绝对不丢失交易数据及应用程序的正确性。

操作可靠性

Co>Operating System 实实在在地解决了实时关键任务应用程序对操作的各项要求。以下为一些机制示例:

  • 同时运行实时应用程序的多个实例,获取负载平衡和故障转移
  • 只中断应用程序系统的部分片段,全天候 (24 X 7) 运转的整个系统无须停机,即可初始化更新的模块
  • 数据库池方式连接,限制资源使用
  • 将多个组件层叠到一个进程内之以,降低 CPU 和内存开销
  • 使用“微图形”(可动态加载的图形逻辑)显著减少对操作系统资源的使用

结论

在实时处理中运用 Continuous>Flows 方法,用户的实施环节效率会因实施图形化数据流得以显著提高,并获取真正通用的数据流连接模型,同时以可靠稳定的机制执行检查点操作和协调交易数据。

English
Français
Español
Deutsch
语言:
简体中文
日本語