在近期于伦敦 Skills Matter 举行的 DDD eXchange 2018 会议上,Martin Schimak 认为在最近几年间,领域事件引发了越来越多的讨论,但是我们对命令也应如此,在这次会议上他讨论了微服务领域的事件、命令以及长周期的服务,以及流程管理器和类似的工具如何有助于运行核心的业务逻辑。
Schimak 是奥地利的一名独立咨询顾问,他认为,事件最好的一点在于,它们代表了已经发生过的事情。我们正在处理越来越多的分布式系统,通过来自服务本身的保证能够让我们更加相信最终一致性。事件还有助于我们解耦服务,并且能够回过头去看过去发生了什么。
事件的优势是事件驱动架构越来越流行的原因之一,有时候,设计只依赖事件就能实现集成服务。有时这种简化是合理的,但是 Schimak 指出,这也可能会带来一些危险。以简单订单处理为例,在处理过程中,只包含 _order placed_、payment received、_goods fetched_ 和 _goods shipped_ 事件,它们会被支付、存储和运输服务所使用。一个简单的变更,比如在跟客户收费之前就将货物提取出来,就会改变消息流,从而要求所有涉及到的服务都要进行变更,对于 Schimak 来说,服务之间的这种耦合是一个次优的方案。
因为事件仅仅是已发生的事实,它们本身并不会触发任何的操作。在监听事件的时候,我们需要一定形式的策略,该策略能够决定当特定的事件接收到的时候,应该发生些什么。在纯粹的基于事件的系统中,这种策略始终要位于事件消费服务之中。在基于命令的方式中,这个策略可以位于事件发布服务中,但是 Schimak 认为,有时候这两个服务都不是合适的选择。对他来讲,第三种方案是新增一个中介者(mediator),它监听特定的事件并决定后续的步骤。
以上面的订单服务为例,这个服务可能会监听相关的事件并发送命令,因此当客户下单时协调流程并完成该订单。在样例中发生这样的变化时,不仅订单服务需要变更。Schimak 指出,在这个过程中运行的逻辑通常是属于业务核心领域中的逻辑。
对 Schimak 而言,命令是一些意图,针对的是未来要发生的事情,他定义了命令执行的两种类型:
- 原子性事务执行,一般的意图是变更一个模型;例如,下单命令会创建一个订单并发布下单事件;
- 复合的、长周期执行,其意图是更加业务级别的结果,可能需要多个步骤才能实现。样例可以是相同的下单命令,但是这里的最终结果是完成订单或取消订单的事件。
在请求支付的场景中,我们应该努力实现有价值的业务结果。支付服务可能会发布 payment received 或 payment cancelled 事件。在 Schimak 的经验中,我们往往会采取相反的措施,暴露一些临时的问题,比如信用卡收费失败,并委托客户端来对其进行处理。这意味着我们要强迫客户端来处理策略方面的问题,而这些问题显然是支付相关的——可能稍后进行重试,有可能使用新的信用卡数据。如果客户端是订单服务的话,那么它不仅要处理订单,还要处理支付,这样就将支付领域的知识扩展到了支付服务之外。这同时也会增加订单服务的规模和复杂性。
将我们的问题委托给客户端并强迫它们处理各种问题,那么它们就变成了上帝服务。
相反,我们应该将支付视为长周期的服务,它要处理支付相关的所有内部问题,并且只发布最终结果相关的事件,即 payment received 或 payment cancelled。Schimak 强调,这并不是要创建一个中心化的协调器(coordinator)来处理 整个业务,它指的是更好的 API 设计,保护不同的限界上下文。
在使用长周期服务时,一个通用的工具是 Process Manager 。流程管理的常见需求是处理时间和超时、重试以及流程失败时的补偿。我们可以自己实现所有这些功能,但 Schimak 更喜欢使用 Axon 消息和 Saga 管理或 Lagom 这样的框架。他还建议使用某种形式的业务流程执行引擎,但他强调工具必须是轻量级的,并且可以在单个服务中使用。开源的过程引擎框架包括 Activiti 、 Camunda 和 Zeebee (也来自 Camunda)。在 serverless 领域, AWS 创建了 Step Functions ,其他云供应商也在朝着这个方向发展。
Schimak 个人在长周期服务和业务处理引擎方面的经验包括多年在Zalando 的订单处理流程中使用Camunda。他和联合来自Camunda 的 Bernd Rücker 在 InfoQ 上撰写了两篇文章:事件、流程和长期运行的服务:工作流自动化的现代解决方案和洞悉流程!微服务与事件协同。
查看英文原文: Business Processes, Long-Running Services and Microservices
评论