本文章原始出处： https://searchapparchitecture.techtarget.com/tip/API-workflow-design-patterns-for-microservices-scenarios
原作者 Tom Nolle
工作流程是任何多组件应用程序的基础。把一些列业务步骤以流程的形式连接，最后为外部返回某种类型的响应。常用控制工作流程的方法可以被用于针对微服务应用的工作流设计模式选型。
在传统的应用程序中，工作由应用程序流程控制。由应用程序发起对一个微服务的调用然后这个微服务可能还会调用另一个微服务。应用程序工作指导的最常见模型是API代理设计模式，其中主组件（在本例中为代理）从源流程接收工作并将其传递给别的微服务以执行。
从SOA时代继承的另一个模型是服务总线设计模式。有了这种设计模式，一系列服务被附加到一条消息总线，而消息总线控制决定下一步运行何种服务的逻辑（通常以业务流程标记语言（Business Process Markup语言，简称BPML编写）。
此方法的优点是，其促进执行所需的处理逻辑服务与以BPML形式存在的工作流程逻辑分离。这使得组件重用变得更加容易，因为微服务现在只是处理单个功能的代码片段。这也是迈向第三种模式的一步：分步编配。
微服务的最佳实践要求其具有弹性和可扩展性，这意味着它们不能在跨微服务调用时保留繁重的状态数据。否则，只有处理输入的主服务才能执行下一个工作流程步骤，这使扩展或重新部署变得困难。
微服务应用中的状态控制依赖于将数据从逻辑中分离出来并提供给任何相关的微服务。1. 前端状态控制： 数据元素可以源于流程触发端并随工作流程移动，2. 后端状态控制：位于所有微服务均可访问的数据库中，并在工作到达时运行。3. 在有限状态机的编排下操作。
分步编配描述了一个工作流程中微服务的顺序，其中最基本的例子是服务总线。使用交换机/路由器设计模式，其目标是推动工作通过可预测的流程序列，需要创建服务代理逻辑的一个分布式实现。但对于复杂应用程序的更复杂的编排，引入状态控制问题至关重要。
状态机设计模式是最终的步骤编排模型。任何过程系统都可以识别为遵循由事件触发的特定状态引导序列的迁移。这种设计模式用逻辑状态和事件映射表定义每个流程序列。特定状态与事件之间的关系决定了要运行的微服务进程。两个映射表都成为状态控制数据的一部分。
状态机编排解决了有关同步和异步请求处理的问题。在同步处理中，对一个微服务的一个请求被阻塞，直到该请求的服务完成执行。对于非常简单的微服务应用程序，这是可管理的，但始终难以处理并行性和弹性。
采用状态机设计模式，所有微服务进程都是异步的。主叫微服务只需进入一个状态，等待发出停止信号的事件信号，一个统一的状态和事件管理机制处理所有事务。
状态机编排方法的最大优点是它兼顾了可扩展性和并行性。每个进程接收其数据和状态控制信息作为输入，而主进程转换所需的状态和事件信息以激活适当的服务。该模型也非常灵活，因此被用于的持久容器和虚拟机模型的部署和serveless的部署。
最后此设计模式需要配合使用最通用的微服务通信模型：ServiceMesh。ServiceMesh通常基于一个sidecar设计模式或一个来自ServiceMesh中间件（如iSito和Linked）的特定设计模式。服务网状方法是处理服务总线部署模型的一个好方法，因为所有必要的微服务通信和负载平衡可能都被隐藏在中间件的实现细节中。
API选择部分基于最佳实践，部分基于您选择以帮助实现的特定中间件工具。一般而言，使用RESTfulAPI并考虑代表服务而非操作的API是一种良好的做法。JSON和XML是编码数据值的一般机制。
最大的问题是将所有数据传递给一个进程还是仅传递该进程所需的数据。前者将使维护微服务变得更加容易，允许所有人访问工作流程数据和状态信息，但也将增加网络负担和响应时间。仅当微服务的性质本质上限制了所需信息的范围时，才应真正采用“只需所需”的方法。
当你设计微服务和API时，尝试在任何可能重用这些微服务的应用程序之间采取一致的方法。许多高级微服务开发人员会喜欢尝试使用状态机方法，因为其灵活性，并因为其创建一个数据模型，在一个地方充分描述过程状态和变量。这使得调试更加容易。但无论采用何种方法，请注意保持一致，否则稍后将遇到调试和操作问题。
其他关于响应式架构的文章
李斌：Coordinator Worker模式在AKKA集群中应用zhuanlan.zhihu.com
82
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
