介绍

我一直在与几家客户合作开发一个新产品，名为 Spring Batch。其目标是提供工具和应用程序来支持企业环境中的批量处理。Spring Batch 是 Spring Portfolio 的一部分，最初版本随 Spring 2.1 版本系列发布。

构建原型代码的最初动力实际上来自于 Interface21 的一些独立客户。这提供了一些有用的额外细节和一些实现约束，使其可以应用于客户提出的现实世界问题。我希望这篇文章能激发更多兴趣，并提供关于总体方法的反馈。

Rod Johnson 将在 JavaOne 大会上与来自 Accenture 的合作伙伴一起介绍 Spring Batch。如果您有幸到场，您将看到该产品的一些细节和背后的思路。在这里，我将展示 Spring Batch 基础设施层的一些细节，这些细节在演示中不会涉及。

源代码将在我弄清楚如何将所有构件（网站、JIRA、持续集成等）整合起来后立即发布到 Subversion。我还计划再写几篇博客，详细介绍该产品的设计方式。有一个邮件列表供有兴趣跟踪我们向 1.0 版本迈进的发布过程的人员使用。要订阅该列表，请访问列表信息页面。

Spring Batch 基础设施

最初版本提供了一些低级工具来支持产品的其他部分。我们将这些工具称为 Spring Batch 基础设施。

基础设施的目标之一是为批量处理的优化提供声明式或半声明式的方法。这包括将操作批量处理在一起的能力，以及在发生异常时重试某个工作单元的能力。这两个要求都具有事务性特征，并且可能涉及类似的概念（传播、同步）。它们也都适用于 Spring 中常见的模板编程模型，例如：TransactionTemplate, JdbcTemplate, JmsTemplate.

框架中的核心接口是BatchOperations和BatchCallback，主要实现BatchOperations是BatchTemplate。示例用法

BatchTemplate template = new BatchTemplate();

template.setCompletionPolicy(new FixedChunkSizeCompletionPolicy(20));

template.iterate(new BatchCallback() {

    public boolean doInIteration(BatchContext context) {
        // Do stuff in batch...
        return true; // Return false signals that data are exhausted
    }

});

回调会重复执行，直到完成策略确定批处理应该结束，在此示例中是在执行 20 次操作后。在实际操作中，这会使用标准的 Spring 事务管理框架包装在事务中。

Spring Batch 基础设施还提供了用于业务操作自动重试的 API。这与批处理支持是独立的，但通常会与它结合使用。在这种情况下，核心接口是RetryOperations和RetryCallback，主要实现RetryOperations是RetryTemplate.

示例用法

RetryTemplate template = new RetryTemplate();

template.setRetryPolicy(new TimeoutRetryPolicy(30000L));

Object result = template.execute(new RetryCallback() {

    public Object doWithRetry(RetryContext context) {
        // Do stuff that might fail, e.g. webservice operation
        return result;
    }

});

优化事务性流水线处理

产品发布后，基础设施可以立即用于简化批处理优化和自动重试。该框架旨在让应用程序开发人员无需了解框架的任何细节——有一些应用程序开发接口可用于方便地构建数据处理流水线，但除此之外，我们的目标是尽可能实际地支持接近 POJO 的编程模型。这类似于 Spring Core 在事务管理和 DAO 实现领域所采取的方法。

Spring Batch 容器层

Spring Batch 的设计愿景是基础设施可以用于在我们称为 Spring Batch 容器层中实现一类面向流程的批处理应用程序。第一个发布的容器是一个批量处理应用程序，它在其实现中使用了基础设施。这个所谓的“简单批处理执行容器”将提供强大的功能，用于批处理生命周期的可追溯性和管理。一个关键目标是，对于非开发人员（例如具有一定业务背景的应用支持团队），批处理过程的管理（查找作业及其输入和结果、启动、调度、重新启动）应该尽可能容易。有人告诉我这是亵渎，但我喜欢将其视为一个“ETL”工具（抽取、转换和加载）。至少容器实际上正在做 ETL 的工作，即使它不符合某些人对传统 ETL 的概念。Spring 编程模型非常适合这类问题——编写你的 POJO，它知道如何定位和处理单个数据项，然后让框架完成基础工作。

关注此空间，获取更多关于容器层、领域概念、通用语言和设计细节的博客。

未来方向

除了简单容器之外，我们还希望提供一个扩展，它可以获取一个输入源，将其划分为子范围，并并行处理这些子范围。一个常见的应用是将并发处理放在远程代理（例如 EJB 或 Web 服务）后面。所有并发子进程都能单独识别自己，显示统计信息，并在出错后从最后一个已知良好记录处重新启动。它们还能够将其可报告的详细信息聚合到父进程，以便操作员可以获得并行作业的单一视图。实现为逻辑工作单元的相同业务逻辑可以像在简单容器中一样使用。区别仅在于配置——Spring 编程模型再次展现其最佳之处。

Matt Welsh 的研究表明，SEDA 比更僵化的处理架构具有巨大的优势，并且消息传递容器为我们提供了很多开箱即用的弹性。因此，我们希望提供一个更具 SEDA 特色的容器或容器支持，同时支持更传统的方法。这里可能与 Mule 和/或其他 ESB 工具存在关联，从而带来高度可扩展架构的优势，其中传输和分发策略的选择可以尽可能晚地进行。相同的应用程序代码原则上可用于处理少量数据的独立工具，以及大规模企业级批量处理引擎。