在现代化架构中，如何处理长时间运行的流程

• 在软件应用中，长时间运行的流程对于各种实际场景的处理至关重要，这类流程会涉及到人工操作、外部响应或有意的延迟。

• 等待会带来各种挑战，比如管理持久化状态、了解进度、处理升级以及对长时间运行的流程进行版本化。分布式系统进一步增加了复杂性。

• 工作流引擎和流程编排平台为管理长时间运行的流程提供了有效的解决方案。

• 成功采用流程编排平台通常需要一个专门的团队来提供技术、咨询和支持。

• 采用异步通信和设计模式对于构建健壮、可扩展的系统至关重要。在不断发展的软件开发领域，新一代的工具正在改变我们处理长时间运行的流程的方式。现代化的微服务编排器或工作流引擎有助于处理大规模、高吞吐和低延迟的场景。这些功能能够让软件工程师就领域边界和整体架构设计做出更明智的决策，最终实现更高效和更具可扩展性的应用程序。

随着系统分布式程度的不断加强，我们需要解决远程通信和潜在的对等不可用的问题，挑战也就随之而来。我在 QCon London 2024 上的演讲深入探讨了流程编排器如何驾驭这些复杂性。本文介绍了我在研究中所讨论的概念。

我们以电话订购披萨为例，这是一种同步阻塞式的通信：呼叫人会被阻塞，直到接听者进行应答，它允许进行直接反馈，但是，这要求双方同时都是可用的。另外一种可选方案是采用电子邮件，它是异步和非阻塞的：发送方不会被阻塞，“消息”处于排队状态，这具有一定的灵活性，但缺乏实时的反馈。当然，你可以通过再发一封电子邮件的方式提供反馈。

更为重要的是，通信反馈循环（“我们收到了你的订单”）并不是交互想要的预期结果。你饿了，所以你实际想要达到的效果是披萨送到了你的家门口。但这需要时间，因为披萨需要在烤箱里面烤一会儿。在这里，你可以看到，无论采用哪种交流方式，订购披萨都是一项需要长时间运行的任务，存在固有的延迟。

需要注意的是，长时间运行的流程指的是等待行为，而不是长时间运行的算法。这种等待可能是由于人工操作（比如批准或决策）、外部响应（比如消费者反馈）或故意让时间流逝（比如，在我们的样例中，位于烤箱中的披萨）。这些过程可能需要数小时、数天、数周，甚至更长的时间（但愿你的比萨不会这样）。

与之不同的是，在一家小面包店点咖啡是一种与结果同步的阻塞式交互。在制作咖啡的过程中，顾客和柜员都不能做任何其他的事情。对于单次点餐来说，这可能没有什么问题，但是对于点多杯咖啡的顾客来讲，等待时间过长会导致体验不佳，而且这还会阻碍面包店处理其他小额的订单。虽然与某些任务相比，制作咖啡相对比较快，但是这种交互的同步性限制了其可扩展性，并降低了用户体验。

Gregor Hohpe 在 “星巴克不使用两阶段提交” 一文中描述了星巴克如何通过将订购流程（异步和阻塞的，以反馈循环作为结束）与咖啡准备（异步，以最终结果作为结束）分离开来以扩展咖啡制作功能。这使得咖啡师可以独立扩展，并且有可能使用基于 App 的系统来取代订单流程，从而提高效率，改善用户体验。

这种模式的第一步是同步的，而涉及等待的长时间流程则是异步的，在很多场景中这都是很典型的情况。

等待会带来一定的挑战性，因为我们需要记住自己正在等待，这需要一个持久化的状态。而这产生了后续的需求，比如，了解我们正在等待什么、对过长时间的等待进行处理升级、对长时间运行的流程进行版本化管理，以及如何处理大规模的需求。我们面临的挑战在于，如何在解决这些问题的同时，又不引入预料之外的复杂性。

在过去的几年间，我见过了太多自制的工作流引擎。最开始，这些引擎往往很简单，只需在数据库中设置一个状态标记并实现一个等待机制即可。但是，它们很快就变为带有调度器、处理升级和其他特性的复杂系统，从而产生低效且难以维护的解决方案。所以，我们应该使用现有的工具来解决这个问题。

但是，我需要在此说明一下。在我的职业生涯中，我积极推动了多个开源工作流引擎项目的开发，并共同创建了一家专注于流程编排的公司 Camunda。因此，我当然对工作流引擎有一定的偏好。

我相信工作流引擎（现在越来越倾向于将其称为编排或流程引擎）能够有效解决长期运行的流程所面临的挑战。通过定义工作流模型（蓝图）并能够执行可长时间运行的实例，这些引擎从本质上解决了等待所带来的挑战。

我们来看一个样例，它是一个简单的入职流程。入职流程在各行各业中都非常普遍，例如，你可能需要新开一个银行账户、购买新的保险或签订新的手机合同。你可以使用业务流程建模标注（Business Process Model and Notation，BPMN） 将流程可视化，BPMN 是定义流程图形化的 ISO 标准。这个流程涉及多个步骤，如客户评分和订单批准，这些步骤可能是自动完成的，也可能需要手动处理。

在 GitHub 上的这个样例中，我们使用一个 Java Spring Boot 应用程序连接到工作流引擎、部署流程并提供 Web UI 供用户交互。UI 会通过触发应用程序中的 REST 调用，在工作流引擎中启动一个流程实例。我们可以通过 UI 或其他集成方法对该实例进行监控和处理升级，并将任务分配给人工处理。

流程会继续处理，使用自定义代码或预置连接器执行相关操作，比如在 CRM 系统中创建用户或发送欢迎邮件。

现代工作流引擎还能处理 大规模的高容量流程，在地理位置分散的数据中心每秒可以处理数千个实例。因此，这项技术并不局限于小规模的应用场景，还可以用于大规模运营中的核心业务流程。

我们回到分布式系统上来，除了业务原因需要等待外，还有一些技术方面的原因，比如，异步通信延迟、消息投递失败以及分布式系统中的对等服务不可用等。如果不加以解决，这些问题可能会导致级联故障。

举例来说，不久前我在尝试办理登机手续时遇到了一个错误，导致我无法收到登机牌。多次尝试均以失败告终，我不得不创建了一个日历提醒，以便于稍后再试。这其实就阐述了有状态重试的概念，即由于临时的问题（比如，航空公司的条形码生成系统故障）导致的延迟重试。这个问题也彰显了分布式系统所面临的挑战，即组件故障是不可避免的。韧性设计可以隔离此类故障，防止它们影响整个系统，给用户带来不便。

改进后的系统设计会确认收到登机申请，同时独立解决登机牌的问题，要么承诺及时交付，要么建议使用应用程序等替代方案。这种方式可以提供更好的用户体验，并明确定义系统内的责任。但是，这种方式需要在登机服务中提供长时间运行流程的能力，以管理登机牌的延迟交付。由于需要在无状态的系统中进行状态管理，许多团队都避免出现这种情况。虽然客户习惯于即时响应，但是与需要用户进行干预的同步错误消息相比，具备清晰沟通交流的延迟结果往往是更为理想的用户体验。

我们将航班预定样例的功能扩展到收款和付款，由于依赖信用卡处理器等外部服务，这引入了更多的复杂性。这些服务可能暂时无法使用，从而导致延迟或失败。远程调用中的异常信息也可能词不达意，难以确定付款是否成功。在这种情况下，重试可能导致重复收费。工作流引擎可以通过检查付款状态并在必要的时候进行退款来帮助管理这些情况。不过，仔细考虑各种情况，并为特定场景选择最合适的解决方案依然至关重要。强大的工作流语言（如 BPMN）和图形可视化技术对于建立良好的解决方案至关重要，这便于和不同的利益相关者讨论各种方案。

在我们开始处理分布式系统的复杂性和长时间运行的流程时，就必须在 API 设计中采用异步通信了。虽然支付通常非常快捷和简单，但是假如遇到信用卡支付遭拒或服务不可用的情况，就需要采用不同的方式了。我们可以通过设计能够处理即时和延迟响应的系统，并使用 202 HTTP 代码等信号表示处理将在后台继续进行，来构建适应性更强、更健壮的支付系统。

这样，我们能够改善错误处理和恢复机制，并能更灵活地执行复杂的需求，比如，异步扣除用户的信用额度和信用卡扣款。

设计健壮的服务需要在架构中包含长时间运行的功能。例如，当预定服务要求支付服务进行付款时，可能会出现信用卡拒付的情况。要解决这种问题，比如允许顾客更新其信用卡的详细信息，往往需要长时间运行的流程来管理交互和付款重试。虽然有些服务倾向于采用无状态模式，并避免这种复杂性，但是采用长时间运行的功能能够提供更好的解决方案，从而实现更全面的错误处理和恢复机制。

这个样例还重点强调了领域概念泄露的问题。预定服务不需要了解信用卡或特定的支付方法。通过将这些问题隔离在支付服务中，设计会更加整洁，也更能适应未来的变更。但是，这要求支付服务来处理支付重试以及客户交互相关的长时间运行流程。为开发团队提供简化这一流程的工具和框架至关重要。

有时候，人们认为工作流编排会导致单体的系统。但实际上，情况恰恰相反。通过在单个微服务中启用长时间运行的功能，我们可以更好地分配责任，避免创建过于臃肿的服务来集中复杂的逻辑。这种方式能够促成更具模块化和可维护性的架构，避免单体化的倾向。

长时间运行的功能对于良好的服务设计和异步、非阻塞的操作至关重要。为了让整个企业的工程师都能使用这些功能，我们需要提供中心化的流程编排，最好是将其作为一种（自）服务。许多使用流程编排的组织都有一个专门的团队，通常被称为卓越中心（Center of Excellence，CoE），这样的团队致力于帮助他人构建解决方案，而不是直接创建解决方案。这种方式避免了以往中心化 BPM 模型的弊端，为团队提供了实施高效流程编排所需的技术和支持。

许多组织希望获得团队的自主权，避免过多的限制，因此对卓越中心这样的集中式团队望而却步。但是，团队拓扑模型提供了一个令人信服的理由来反驳这些想法。这种模式强调不同的团队类型，以实现最高的效率：产品导向（stream-aligned）团队专注于提供业务价值，赋能（enabling）团队提供咨询，平台团队提供必要的技术。专注于流程编排和和自动化的 CoE 通过提供技术和支持，将产品导向团队解放出来，使其能够专注于提供价值，这很好地适应了这种模式。该方法能够避免让每个团队独立探索技术栈的弊端，从而加快价值交付速度。

Spotify 的“Golden Path”方法就是一个很好的行业范例，它为不同类型的项目（如面向客户的 web 应用程序或长时间运行的工作流）提供了 预定义的解决方案。这些 Golden Paths 是为开发团队所设计的，易于使用且很具吸引力，但并不是强制性的。这样既能鼓励标准化和提升效率，又能保持自主性。其目标是摆脱“流言驱动的开发”，在整个组织范围内整合有效的技术。Spotify 发现，过多的权力下放拖慢了他们的速度，而“Golden Paths”有助于在自治性和效率之间保持平衡。

再举一个样例，Twilio 使用了名为“paved path”的概念来简化和规范开发流程。这包括创建团队可以轻松使用和实施的预制服务，降低搭建基础设施的复杂性，让团队更加关注于业务逻辑。

BPMN 是一个图形化的模型，是定义流程的 ISO 标准，这种图形化的模型为可视化和实现复杂的工作流提供了一种强大的方法。它们是活生生的文档，代表了运行中的代码，而不仅仅是需求。这些模型可用于各种目的，如测试用例、运维监控以及与利益相关者交流。在与利益相关者讨论长时间运行的行为时，这些模型的可视化就显得尤为重要，可以帮助他们理解异步操作背后的原理以及客户交互过程中可能发生的变化。采用图形化的模型能够让组织有效地利用现代化架构，并改善技术团队和非技术团队之间的协作。

总而言之，鉴于各个方面的原因，长时间运行的能力是至关重要的。流程编排平台和工作流引擎提供了宝贵的技术，有助于设计更好的服务边界、以更低的复杂性快速实施以及更轻松地采用异步通信。这将带来卓越的用户体验、更高的运维效率、更好的自动化、更低的风险以及更优的合规性。强烈建议成立一个中心化的赋能团队，以便在整个组织内成功采用这项技术。

Bernd Ruecker，Bernd 是一名软件开发者，他一直致力于在 T-Mobile、Lufthansa、ING 和 Atlassian 等行业领先企业的高扩展性和敏捷环境中实现部署流程的自动化。15 年来，他为各种开源工作流引擎做出过贡献，是流程编排领导者 Camunda 的联合创始人和首席技术专家。他是“Practical Process Automation”的作者，也是“Real-Life BPMN”的合著者。此外，他经常在世界各地的会议上发表演讲，并经常为技术出版物撰稿。他的研究重点是流程自动化范式，这些范式能够与面向分布式系统、微服务、领域驱动设计、事件驱动架构和反应式系统的现代化架构相匹配。

查看英文原文：

Are You Done Yet? Mastering Long-Running Processes in Modern Architectures (https://www.infoq.com/articles/mastering-long-running-processes/)

声明：本文由 InfoQ 翻译，未经许可禁止转载。