相比于时髦的“SOA”,“批处理”略显老气。然而,这决不意味着“批处理”就属于那种该被历史遗弃的技术。相反,在当今企业 IT 系统的许多地方,“批处理”依旧发挥着其重要的作用。这一点在 OLAP 系统中体现得尤为突出。一个典型的批处理场景就是:定期从 OLTP 系统中将数据 ETL 至 OLAP 之中,然后产生报表数据。考虑到许多商业决策都要基于这类分析报表来制定,它的重要性可想而知。对于“批处理为何依旧存在?”这一问题,ZapThink 的分析师 Ronald Schmelzer 在其文章中给出了他的看法:
当今,批处理依旧十分重要的一个关键原因是:缺乏一种有效的方法,在每次业务处理单个事件(如输入的客户订单)的时候,重新产生一份完整的预报或商业计划。
既然批处理的历史使命仍在延续,在企业实施 SOA 的时候,对于它的考虑自然在所难免。此外,世上并没有一成不变的东西,批处理也不例外。Ronald Schmelzer 在谈到批处理的演变时,这样写道:
这么多年来,批处理技术已经由基于脚本的自动化发展到了由规则或策略驱动的工作负荷自动化(workload automation)。 ……当今批处理正在由静态、往往是单独的处理,转变成应用或组合业务流程的一个动态组件。其目标可能包括提高反应速度、增加公司的透明度,以及为 IT 采用一种更加以业务为中心和合规驱动(compliance-driven)的方式管理其运营提供支持。
将批处理暴露为服务是实现以上目标的前提。Ronald Schmelzer 表示,虽然服务给人的第一印象是暴露业务流程、数据处理或应用功能,但是它们也非常适合暴露驱动批处理。同时,他还认为,面向服务的批处理可以实现按需执行,而不必像传统的那样按时执行。
从面向服务的观点来看,其服务契约和策略必须指明:批处理在一天内能执行多少次,每次执行所花时间,以及其他服务或数据依赖。
针对 Ronald Schmelzer 的文章,Loraine Lawson 这样评论:
Schmelzer 的文章主要集中在“服务支持的批处理是如何给实时组织提供帮助的”。它重点论述了其好处,但我期望他能花些时间看看可能存在的缺陷。例如,尽管他讨论了确保批处理服务符合企业和 IT 规则,但对这如何在现实生活中发生却言之甚少。
Loraine Lawson 在其文章结尾引用了 Gartner 研究副总裁 Dale Vecchio 的文章:融合 SOA 和批处理应用(Mixing SOA and Batch Apps),后者认为,结合 SOA 和批处理应用之后,性能上有可能会受到负面影响。
就历史经验来说,批处理工作是在头天晚上某个预定义时间段内处理大量的数据。如果服务调用引入某种程度的延迟或戏剧性的性能干扰,那么批处理就无法及时完成。在整个工作日的时段内都发生会交易量,尽管任何组织都会有碰到峰值处理的时候,但批处理中的工作量和有限的时间段并未给错误留出多余的空间。
关于如何在 SOA 中实际应用批处理,这篇文章给出了来自 IBM 软件实验室的 Sridhar Sudarsan 的经验。Sudarsan 认为企业在改造批处理的过程中常常犯的几个错误包括:建立过于复杂的框架、过多使用第三方库、对批处理系统知识的缺乏(随着这些系统的开发者相继退休,熟悉这些系统的人也变得越来越少)。
至于从实践中学到的最佳实践,Sudarsan 给出了:
- 在编码之前先详细了解批处理的业务逻辑,不要仅仅进行代码翻译工作。否则,你将得到脆弱、难以维护的代码。
- 速度优于可移植性,尽量让处理接近于系统。并认为“单纯的数据处理或 ETL 类处理最好在数据层而不是在对象层进行”。
- 以高效的数据访问为目标。在设计数据模型时需要考虑:
- 缓存
- 把只读数据和更新数据分开
- 全局文件系统
- 数据分区、转移
- 复制
- 批量访问和一次访问一条记录
- 并发性 / 竞争性 / 一致性
- 数据联邦 / 转换 / 虚拟化
- 说明数据内容和工作需要的声明方式
- 将数据放在离应用层近的地方,以改善吞吐量
文章最后结束了 Sudarsan 提出的迁移四步骤:
- 在使用 Java 实现时,询问某一特殊步骤是否应该被实现成为特殊的批处理功能。可能是合并,也可能是要拆分。这部分时间应该占整体实现时间的 10%。
- 找出批处理功能的组件:数据流、逻辑、检查点和相关的任务控制参数。这应该花你 30% 的时间。
- 写出独立于批处理容器的逻辑;提供批处理应用要调用的 API。这应该花你 20% 的时间。
- 测试(单元测试、性能测试和伸缩性测试)。这应该花你 40% 的时间。
很明显,就现在的技术水平,不可能将批处理全部废除,而批处理技术本身也在与时俱进。相信在相当长的一段时间内,批处理和 SOA 应该和谐的相处在一起。
评论