我们目前正在评估流程从Spring批量管理员转移到基于Spring Cloud的基础架构 .
our main challenges / questions:
1. 作为 spring 批处理作业的整体设计的一部分,我们正在获取一些通用MD并将其聚合到通用数据结构中,许多作业使用这种结构以更优化的方式运行 . 在我们的案例中,SCDF任务的性质是否会成为一个问题?我们应该重新考虑转移到Streams吗?以及如何做到这一点?
2. 使用SCDF的一个主要原因是支持扩展以获得更好的性能 . 作为第一个POC,我们很难创建一个真正的 Cloud 基础架构,而我正在寻找使用远程分区设计进行扩展解决方案的独立SCDF . 我们正在寻找演示/介绍GitHub项目/指南 - 我没有找到任何相关的东西 . 它是否也需要过去几年通过JMS基础设施(Spring Integration)解决节点之间的通信?
3. 我们面临的主要挑战是重构我们的批处理作业,并能够支持每个节点上的远程分区和多个线程 . 是否可以创建具有这两个方面的 spring 批处理作业 .
4. 将20个乔布斯的单片 jar 拆分成单独的 spring 靴überjars并非简单的任务 - 任何想法/想法/最佳实践 .
最好,很高兴
1 回答
我遇到了与Elad的第3点相同的问题,并最终通过使用基本框架解决了它,如演示here但使用DeployerPartitionHandler和DeployerStepExecutionHandler的修改版本 .
我首先尝试了创建两级分区的天真方法,其中每个工作程序执行的步骤本身被分区为子分区 . 但该框架似乎并不支持这一点;它对步骤的状态感到困惑 .
所以我回到了一组平面分区,但是将多个步骤执行ID传递给每个工作者 . 为此,我创建了DeployerMultiPartitionHandler,它启动配置的worker数,并为每个worker传递一个步执行ID列表 . 请注意,现在有两个自由度:worker和gridSize,它是尽可能均匀地分配给worker的分区总数 . 不幸的是,我不得不在这里复制很多DeployerPartitionHandler的代码 .
在静态函数partitionOffset的帮助下将分区分发给worker,这确保了每个worker接收的分区数最多相差一个:
在接收端,我创建了DeployerMultiStepExecutionHandler,它继承了TaskExecutorPartitionHandler中分区的并行执行,另外还实现了与DeployerMultiPartitionHandler匹配的命令行界面: