本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：translation-feedback@oreilly.com
Tuesday, February 15, 14:34
午饭刚过，奥斯汀就冲进了洛根的办公室。"我一直在看 新的建筑设计，我想帮忙。你需要我写一些 ADR 还是帮你弄一些尖顶？我很乐意写 ADR，说明我们在新架构中只使用编排来保持解耦。"
"哇，你这个疯子。"罗根说。"你从哪儿听来的？你怎么会有这种印象？"
"我读了很多关于微服务的书，每个人的建议似乎都是保持高度解耦。当我查看通信模式时，似乎编排是最解耦的，所以我们应该一直使用它，对吗？
在软件架构中，"始终 "是一个棘手的术语。我有一位导师对此有一个令人难忘的观点，他总是说：在谈论架构时，永远不要使用绝对，除非是在谈论绝对的时候。换句话说，永远不要说 "永远"。我想不出有多少架构决策适用于'永远'或'从不'"。
"好的，"奥斯汀说。"那么，建筑师如何决定不同的交流模式呢？"
作为我们对 现代分布式架构相关权衡分析的一部分，我们达到了量子耦合的动态部分，实现了我们在第 2 章中描述和命名的许多模式。事实上，即使是我们命名的模式，也只是触及了现代架构可能存在的多种排列组合。因此，架构师应了解各种作用力，以便进行最客观的权衡分析。
在第 2 章中，我们指出了分布式架构中考虑交互模型时的三种耦合力： 通信、一致性和协调，如图 11-1 所示。
在本章中，我们将讨论协调问题：在分布式架构中将两个或更多 服务结合起来，形成一些特定领域的工作，以及随之而来的许多问题。
分布式 架构中存在两种基本协调模式：协调和编排。图 11-2 说明了这两种模式在拓扑结构上的基本区别。
协调是通过使用协调器来区分的，而编排解决方案则不使用协调器。
编排模式使用一个编排器（有时也称为调解器）组件 来管理工作流状态、可选行为、错误处理、通知和大量其他工作流维护工作。它的名称来源于音乐管弦乐队的显著特征，即利用指挥来同步总乐谱中不完整的部分，从而创造出一首统一的乐曲。图 11-3 是管弦乐队最通用的示意图。
在本例中，服务 A-D 都是领域服务，每个服务都负责自己的边界上下文、数据和行为。协调器组件一般不包括其所调解的工作流之外的任何领域行为。请注意，微服务架构的每个工作流都有一个协调器，而不是像企业服务总线（ESB）那样的全局协调器。微服务架构风格的主要目标之一是解耦，而使用 ESB 等全局组件会产生一个不理想的耦合点。因此，微服务倾向于为每个工作流配备一个协调器。
当架构师必须为一个复杂的工作流建模时，协调模式就非常有用，因为这个工作流不仅包括单一的 ...