基于SI实现Remote Chunking模式的示例：
Step本地节点负责读取数据，并通过MessagingGateway将请求发送到远程Step上;远程Step提供了队列的监听器，当请求队列中有消息时候获取请求信息并交给ChunkHander负责处理。
接下来我们看下最后一种分区模式;Partitioning Step：分区模式需要对数据的结构有一定的了解，如主键的范围、待处理的文件的名字等。
这种模式的优点在于分区中每一个元素的处理器都能够像一个普通Spring Batch任务的单步一样运行，也不必去实现任何特殊的或是新的模式，来让他们能够更容易配置与测试。
通过分区可以实现以下的优点：
分区实现了更细粒度的扩展;
基于分区可以实现高性能的数据切分;
分区比远程通常具有更高的扩展性;
分区后的处理逻辑，支持本地与远程两种模式;
分区作业典型的可以分成两个处理阶段，数据分区、分区处理;
数据分区：根据特殊的规则(例如：根据文件名称，数据的唯一性标识，或者哈希算法)将数据进行合理的数据切片，为不同的切片生成数据执行上下文Execution Context、作业步执行器Step Execution。可以通过接口Partitioner生成自定义的分区逻辑，Spring Batch批处理框架默认实现了对多文件的实现org.springframework.batch.core.partition.support.MultiResourcePartitioner;也可以自行扩展接口Partitioner来实现自定义的分区逻辑。
分区处理：通过数据分区后，不同的数据已经被分配到不同的作业步执行器中，接下来需要交给分区处理器进行作业，分区处理器可以本地执行也可以远程执行被划分的作业。接口PartitionHandler定义了分区处理的逻辑，Spring Batch批处理框架默认实现了本地多线程的分区处理org.springframework.batch.core.partition.support.TaskExecutorPartitionHandler;也可以自行扩展接口PartitionHandler来实现自定义的分区处理逻辑。
Spring Batch框架提供了对文件分区的支持，实现类org.springframework.batch.core.partition.support.MultiResourcePartitioner提供了对文件分区的默认支持，根据文件名将不同的文件处理进行分区，提升处理的速度和效率，适合有大量小文件需要处理的场景。
示例展示了将不同文件分配到不同的作业步中，使用MultiResourcePartitioner进行分区，意味着每个文件会被分配到一个不同的分区中。如果有其它的分区规则，可以通过实现接口Partitioner来进行自定义的扩展。有兴趣的TX，可以自己实现基于数据库的分区能力哦。
总结一下，批处理框架在扩展性上提供了4中不同能力，每种都是各自的使用场景，我们可以根据实际的业务需要进行选择。
批处理框架的不足与增强
Spring Batch批处理框架虽然提供了4种不同的监控方式，但从目前的使用情况来看，都不是非常的友好。
通过DB直接查看，对于管理人员来讲，真的不忍直视;
通过API实现自定义的查询，这是程序员的天堂，确实运维人员的地狱;
提供了Web控制台，进行Job的监控和操作，目前提供的功能太裸露，无法直接用于生产;
提供JMX查询方式，对于非开发人员太不友好;
但在企业级应用中面对批量数据处理，仅仅提供批处理框架仅能满足批处理作业的快速开发、执行能力。
企业需要统一的批处理平台来处理复杂的企业批处理应用，批处理平台需要解决作业的统一调度、批处理作业的集中管理和管控、批处理作业的统一监控等能力。