本文共 597 字，大约阅读时间需要 1 分钟。

假设在一个应用中，客户注册了一个新账号，而这个动作会触发以下逻辑：

1. 在客户的积分账户中创建一条积分记录；
2. 通过邮政系统派送一个欢迎礼包；
3. 向客户发送欢迎电子邮件；

创建新账号的流程图为：

考虑具体实现时 , 有两种架构可以选择 。

1 编排 (orchestration)

编排架构，会有某个中心大脑来领导并驱动整个流程 , 这个大脑就像交响乐队中的指挥。

编排架构的缺点是 , 客户服务作为中心控制点承担了太多职责 , 它会成为网状结构的中心枢纽及很多逻辑的起点 。 这种架构可能会导致出现 “老大哥 ” 服务 , 而与其打交道的其它服务会沦为仅是基于 CRUD 的 “贫血” 服务。

2 协同 (choreography)

协同架构，会预先说明清楚系统中各个部分各自的职责 , 而把具体怎么实现留给各个部分它们自己 。

在刚才的示例中，我们可以使用异步的方式从客户服务中触发一个名为“ 客户创建 ”的事件 。 积分服务、包裹服务以及邮件服务订阅这个事件 。 这种架构的好处是能够显著地消除耦合 。

这种架构的缺点是 , 不能直观地看出整体业务流程 。因此，我们必须监控整套流程 , 以确保其能正确地流转 。这需要构建一套与上图业务流程相匹配的监控系统。

总的来说，协同架构不仅可以降低系统的耦合度 , 还可以让我们以更加灵活的方式修改现有系统。

应该根据具体的实际技术，来选择最适宜的架构。

转载地址：https://deniro.blog.csdn.net/article/details/101148557 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！