我们的应用包含大量部署在docker swarm集群中的微服务（大部分是基于java的独立应用），每个服务都可以在运行时进行扩展，甚至整个堆栈有时也可能会重启。
但是，当删除或重新启动某个服务时，可能会在正确的容器内运行一些耗时的任务。例如：
上传大容量容器时移除/重新启动容器。
从保存在容器内/tmp 目录中的上传文件导入数据时，容器删除/重新启动。
为某个数据表创建索引时移除/重启容器。
....
我们必须尽快恢复它们。以上面的西装为例：
无法恢复，使用需重新上传文件。
应恢复，从其终止处重新启动导入作业。
同2。
听起来我们需要一个分布式框架，它可以持久化所有任务的状态，检查每个任务的健康状况，并在需要时恢复。
有什么轻量级的解决方案可以推荐吗？
【问题讨论】：
标签： java scheduled-tasks docker-swarm
不同服务之间的任务编排从来都不是真正的轻量级 IMO，并且实施这样的更改可能会分配工作并且对于您所在的组织来说非常难以掌握（我稍后会解释）。
我们现在正在经历这个过程，我们首先尝试使用 Spring Batch 来执行此操作，但像您一样，我们需要将其分布在多个服务中并具有高可用性，因此我们转向在 AWS 中使用 Step Functions。
您仍然可以在本地进行开发，但也可以使用 Step Functions 进行一些工作，我通过实施一个相当简单的工作流程供开发人员使用来做到这一点，其中涉及在 AWS 上使用他们自己的私有组件（SQS 队列）前置通过他们的$USERNAME 变量。这应该和设置一些环境变量一样简单。
但是决定使用什么编排框架应该取决于许多因素：
虽然实现编排框架可能具有挑战性，但这并不是最困难的部分，YMMV。我发现最具挑战性的是让企业决定做出不同的权衡。以恢复为例，如果某事失败，也许应该在 5 分钟内再次尝试任务，这在 Step Function 上实现非常简单。但这可能意味着在您实施此操作之前，一项工作失败所需的时间比其他情况要长，而失败的工作现在通过第二次尝试成功。我发现非技术人员不理解或不想理解这一点，并且会告诉您，事情应该快速失败，并在这些配置相互竞争时同时恢复。谁也拥有这个过程？如果它影响的不仅仅是您的团队，那将再次变得棘手，并且您可能会有不同的团队具有相互竞争的优先级。
【讨论】：