具有长等待状态的批处理与 BPMN 处理

Question

我正在开发一个 Java 项目 (Spring)，我需要为一个相当复杂的场景创建批处理。有些步骤必须等待相当长的时间，例如20天。我不太确定，我应该如何处理这种情况。

我的第一个想法是在 BPMN 引擎（如 Camunda）中执行此操作，其中等待状态是建模元素的一部分。考虑到需要处理的数据量，我最终会在一次运行中得到大约 250.000 个流程实例，并且在基于 BPMN 的处理的情况下，从性能角度来看，这个数据量涉及到问题。

另一种解决方案是采用专为批处理而设计的框架，例如春季批次。在这种情况下，我的问题是漫长的等待状态。据我了解，Spring Batch 不支持等待状态。然而，我提出的每个草案解决方案都有一些限制。

我是否会大批量进行，可能会发生等待的步骤将停止，直到 20 天结束。这将阻止处理其余要处理的数据。我想我可以将给定的数据项标记为稍后处理，然后重新运行批处理，直到处理完每个项目。这意味着我需要以线性方式布置处理的每个分支，并且这些步骤本身将只接受为它们标记的数据项。

我是否会为每个要处理的项目启动一个新的批处理作业，我需要一种机制来在给定点停止，然后从给定步骤恢复作业/步骤。一个自然的解决方案是创建一个更细粒度的作业系统，但这样我会丢失有关处理的上下文信息。

在这两种情况下，我最终都会将自己的 BPMN 解决方案实现为数据库中的状态机...

如果您能给我任何帮助或提示，我将不胜感激。提前致谢。

Answer 1

使用 BPM 处理它可以为您提供透明度、灵活性、更快的实施、开箱即用的持久性和错误处理，最重要的是支持长时间运行的流程。我不同意性能问题。 250,000（每天？每月或每 20 天？）对于 Camunda 来说并不多。您编写的流程实例可能会运行大约 20 天，但我看不到您启动这些 250,000 个作业的频率。如果是业务日常运行，您每月仍然只能获得 5,500,000 个实例。没什么大不了。你应该考虑

• 您需要什么历史级别。此处可能不需要完整，审核可能就足够了。
• 批次项目有多大以及它们将存储在哪里。将大型业务对象作为流程数据持久化并不是一个好的设计。为业务对象提供一个简单的 CRUD 服务会更好。从引擎访问瞬态过程数据时，您可以使用它们。 （好吧...如果对象不大，而且我们每月只讨论 250k 个实例，即使是简单的 JSON 序列化作为流程数据也可以。）
• 您希望将审核数据存储多长时间？相应地设置进程的 TTL。似乎

Answer 2

我还与我的技术主管讨论了这个问题，并且有几个反对 BPMN (Camunda) 的论点。

1. 在仍有实例处于等待状态（例如正在运行的进程）的情况下，潜在进程更新的难度级别。
2. 使用 BPMN 并可能解决扩展和性能问题可能与我们最初打算使用它的目的（简单的消息编排）相矛盾。

由于这些原因，我们决定使用 Spring Batch，我们将业务批次（如活动图中所述，具有等待状态等）和技术批次（Spring Batch 实现）分开。在这种情况下，每一步都可以获取当前上下文，执行操作并更新它。一个技术批次可能会处理当前计划处理的每个业务批次（例如，新创建的批次的数据以及所有等待状态今天到期的数据）。这也需要我们创建一个状态机；可能也支持并行执行（例如 Petri 网）。