我们的团队目前运行了许多我们从过去团队继承的计划作业，这些作业不是很多，但足以让人难以跟踪。我们当前设置面临的主要问题是： - 不清楚运行的内容和时间 - 通知工作失败的不同方式 - 并不是所有的工作都支持重新运行，关于重新运行是否会起作用或让事情变得更糟的运气。
为此，我们一直在考虑使用 Spring Batch 重写我们的作业并使用 SOS Job Scheduler 来管理它们。
有没有其他人使用过这种方法或者可以推荐一种管理工作的好方法？
【问题讨论】：
标签： spring-batch job-scheduling
我不确定您是否有真正的问题，但是，用 Spring Batch 编写的作业非常适合作业调度程序。我已经编写了几十个通过 AutoSys 和 Tivoli 安排的作业；不熟悉 SOS，但我希望它几乎相同。
通过 Spring Batch 调度作业的主要技巧是确定作业所需的参数。
Spring Batch 使用JobInstance 和JobExecution 的概念来管理作业；实例由作业名称和相关参数定义，而执行是运行实例的尝试。一旦执行运行完成，实例也已完成，无法重新运行。
实际上，这意味着如果一个作业不使用外部参数（即大多数重复的计划作业），它需要在每次运行时传入某种综合参数，因为如果你不将某些东西作为参数传入，您只能运行一次（因为空的参数集定义了唯一的JobInstance）。
如果作业经常运行，我会使用当前时间戳之类的东西，以确保每个 JobInstance 都是唯一的。如果它每天运行，则传入当前日期可确保您每天获得一个 JobInstance，这有利于跟踪和重新启动。
总而言之，预定的 Spring Batch 作业并不复杂，而且运行良好。
根据提问者的评论进行编辑：
Spring Batch 的模型对我来说没有意义的一点是，确定作业参数的逻辑都是外部化的；在调用脚本可以轻松生成日期等参数的许多情况下，这可能没问题，但是我有很多工作对参数逻辑具有更高的复杂性。
我最终做的是扩展CommandLineJobRunner 以获取一个名为JobParameterGenerator 之类的新接口的实例。 JobParameterGenerator 的实现通常特定于特定的工作；例如，一种实现必须进行一些数据库查找来为工作制定适当的日期范围。我还创建了一个基本的JobParameterGenerator，它只返回当前的 DateTime 以用于始终是新实例的作业。希望这会有所帮助。
【讨论】：