从微服务迁移到工作流的经验之谈
Jet公司的订单管理系统（OMS）负责处理很多业务功能，最初是由一系列微服务组成的。随着公司的发展，这种架构所面临的挑战也越来越大，直到他们决定构建一个新的基于工作流的平台。Jet工程师James Novino在一篇博文中介绍了旧系统面临的挑战、对新平台的概述以及新平台运行一年多后所总结的经验。
OMS最初使用了发布与订阅、事件溯源和其他技术的组合。每个服务都使用相同的样板实现，包含了三个步骤：
解码——从输入流中读取领域事件，并将事件转换为输入类型。
处理——检查输入并获取任何所需的数据。
解释——执行副作用。
随着公司的发展和需求的增长，架构的复杂性也在增加，使得维护系统变得更加困难。服务的数量也增加了，并且由于功能通常分布在多个服务中，因此导致开发周期变得更长。Novino认为这是一个很复杂的过程，需要大量的样板代码。他还指出，随着系统的发展，构建和维护这种架构的复杂性对系统和团队都带来了负面影响。
因此，他们开始创建一个能够以更有效的方式处理所有业务工作流的新平台。他们决定设计和构建一个基于工作流的系统，其灵感来自Pat Helland和他的论文：Life Beyond Distributed Transactions。新系统的核心设计基于两个保证：
幂等性——避免重复事件。
一致性——支持多个不同的存储，但由于它们必须能够读取自己的写入，因此存储需要实现强一致性模型。
这些保证为系统带来了多个特性，包括：
事件溯源——所有状态变更都存储在日记中。
简单的实现，由工作流定义和相应的步骤组成。这样有助于开发人员优先考虑业务流程并强制执行系统的模块化。
工作流的幂等性保证。
工作流版本控制，可以将变更部署到工作流中，而无需担心当前正在执行的东西。
伸缩性——通过使用每个服务的多个实例，可以并行执行工作流。
Novino将新架构描述为其早期管道（解码-\u0026gt;处理-\u0026gt;解释）的抽象版本，并在每个操作之间具有明确的服务边界：
工作流触发器，对应于解码；
工作流执行器，用于处理；
副作用执行器，相应的解释。
为了定义工作流，他们创建了一个领域特定语言（DSL），用于定义所需的一系列执行步骤。他们还提供一个可视化工具，可以显示正在运行和已经运行过的工作流。
Novino指出，有一些现成的工作流编排和设计替代方案，但他们决定构建自己的方案，原因如下：
能够为工作流事件维护单独的数据存储；
能够在执行过程的任何时刻重放或可视化状态；
可扩展性和伸缩性。
在生产环境中运行了一年多后，它们创建了大约2200万个日志，完成了大约9300万个工作流。
最后，Novino指出，从基于分布式微服务的架构迁移到基于工作流的架构，在设计、开发和支持过程中对其开销产生了巨大影响。他还指出，使用DSL设计工作流并将其作为单个响应步骤实现的能力提高了他们构建复杂新系统的能力。在未来的文章中，他将更详细地介绍他们的新设计。
查看英文原文：https://www.infoq.com/news/2019/02/migrate-microservices-workflows