「微服务架构」编曲与编舞——让系统协同工作的不同模式

介绍

Krzysztof（采访者）：商业组织是由专家组成的，他们在他们最了解的领域提供产品或服务，以获得共同的商业成果。例如，营销团队努力争取新客户，销售团队向这些客户销售产品，客户关系团队负责积极的客户体验和保留。只有当这些团队一起工作时，才能实现共同的业务目标和利润。如何组合和安排他们的服务以实施业务流程管理的问题是定义整个组织如何运作的关键部分。今天我们将讨论这样做的最佳方法。我们有编排模式和编排模式——我们在辩论中的演讲者。你能介绍一下自己吗？

编曲模式：感谢您组织本次辩论。我是Orchestration Pattern，我相信只有一个集中且组织良好的组件才能为业务流程管理提供稳定性和跟踪。这就像一场管弦乐队音乐会——我们有一位指挥向每组音乐家展示何时发挥他们的作用。没有他，音乐家将演奏混乱而不是交响乐。同样的事情也适用于 IT 系统——如果我们在系统通信中使用 Orchestrator，我们将能够管理我们的流程并轻松验证其状态。

编舞模式：我很高兴被邀请参加这个演讲。谢谢你有我。我是编排模式，我对系统通信规则的观点与编排模式相反。我认为，在我们的 IT 生态系统中间添加一个额外的决策组件是多余的。更重要的是，我认为组件应该是自主的并且耦合松散，以提供业务价值本身，而不会影响其他组件。这就像一支爵士乐队，当音乐家正在等待其他人停止演奏，并继续他们与另一支球队介绍的旋律相关的自由泳时。使用这种方法，我们可以少维护一个组件，并且我们没有一个难以管理的大单点。

第 1 轮：IT 系统设计

Krzysztof（采访者）：感谢您的快速介绍。现在，我们将开始第一轮，我们将首先从技术角度讨论您的想法。这里的问题是——你不只是同步和异步通信的不同名称吗？

编曲模式：不！我可以实现这两种通信模式。这就是我的 Orchestrator 组件如此重要的原因。让我详细说明一下您在开始时介绍的示例。当营销团队获得新客户时，客户关系和销售团队应该意识到这一点并更新客户信息——以便当销售人员想要致电客户时，他们可以立即获得有关他们的信息，发生的所有通信以及所有 客户进行的购买。以下是我将如何实现这两个功能。

• Async Client Synchronization with Orchestration Pattern

• 使用编曲模式同步客户端详细信息响应

编舞模式：在名称方面我同意编排模式——我也可以实现同步和异步通信。我只是不同意 Orchestrator 组件至关重要。让我重新设计一个编排模式的想法，因为我仍然可以提供相同的业务功能，而中间没有一个全能的元素。

• Async Client Synchronization with Choreography Pattern

• 将客户端详细信息响应与编排模式同步

正如你所看到的，我可以做同样的业务逻辑，但使用更少的业务逻辑组件，更灵活的设计。

编曲模式：您的设计看起来非常复杂！而且，我可以在中间看到一个元素——这个事件系统。所以，我不能同意业务逻辑组件更少。不只是 Orchestrator 而是另一个名字？而且，老实说，我在这里看不到这种灵活性……

编舞模式：首先，您错过了这样一个事实，即如果您在 Orchestrator 中进行错误处理，您的设计看起来会非常复杂。如果 CRM 系统在客户端同步中没有响应，您将如何反应？您需要围绕通知在线商店有关情况来实现重复和业务逻辑。让我用这个缺失的部分重新表述你的设计。

• Orchestrator 需要处理错误和系统不可用。使用 Choreography，组件只需等待适当的事件

同时，我的组件只是等待一个适当的事件——不需要在那里进行任何更改，也不会因为一个系统的不可访问性而由第三方处理错误。这样一来，您的设计看起来并不那么简单，因为您需要处理所有“假设”。

其次——我的事件系统不是业务逻辑组件。这是系统发布有关其处理的事件的空间。不包含任何业务逻辑——它就像一个论坛，每个人都分享他们所做的事情。这给了我刚才所说的灵活性——如果我不希望在客户注册过程中由通信系统发送电子邮件，我只需禁用此通信系统中的侦听器。对于其他组件，这种变化是不可见的。在您的设计中，您需要在 Orchestrator 中进行业务逻辑更改。

编曲模式：只要过程没有因错误或意外行为而中断，这一切听起来都很好。那会发生什么？如果您的元素之一失败，或者根本没有发布适当的事件，整个业务流程就会挂起。而且我们没有地方可以触发这样一个过程的结束。

编舞模式：这就是我们需要监控和跟踪工具的目的。那些轻量级的技术应用程序应该对未使用的事件或没有结束事件的卡住进程发出警报。我们可以通过这些工具自动生成最终事件，或者让人类决定做什么，就像编排模式一样，但不是在一个大而全能的元素中。然而，你说得有道理——与我一起计划和管理比与 Orchestration 更难。

第 2 轮：变更管理

Krzysztof（采访者）：感谢您在第一轮中进行的激动人心的讨论。您已经提到了我们现在要讨论的一个主题——变革管理。在这一轮中，我们将着眼于改变和影响您提出的解决方案的变化的灵活性。那么，您可以用您的方法以多快的速度交付新功能和流程？改变现有的会有多困难？最后，如果您在一个组件中引入更改，那么其他组件会发生什么？

编舞模式：编排模式指责我架构的每次更改都需要对多个组件进行大量调整。这并不完全正确。是的，我同意更改流程本身需要更改负责该流程的协调器组件。但这样的变化并不总是会产生巨大的影响。将 ESB 作为集成平台，我们减少了 Orchestrator 中数据映射部分的更改次数。最重要的是，将 BPM 引擎用作协调器，简化了业务流程本身的变更交付。如果我们在一个组件中更改数据的结构，我们将需要在组件中使用类似的结构来使用数据。我怀疑我们可以通过编排模式避免这种情况，所以在变更管理的情况下，我相信我们已经接近了。

• 使用 Orchestration，很多变化都需要在 Orchestrator Element 中进行一些调整

编舞模式：我强烈不同意我们很接近。为了证明这一点，我想参考我们概念的基础知识。管弦乐就像一场管弦音乐会。如果我们想改变小提琴部分，我们需要每次都为小提琴手写一个新的旋律，有时要求指挥家进行一点不同的指挥。正如我所提到的，我更像是一支爵士乐队——如果我的一位音乐家想要扮演不同的角色，我就允许他这样做。当然，他可以完全改变旋律，其他音乐家也会想对它做出反应——但我只是让他们自己决定。在最坏的情况下，即不同步的变化，他们将完全停止播放，等待老旋律出现。对于管弦乐队来说，最坏的情况是他们演奏的一团糟，会伤到你的耳朵。老实说，我更喜欢沉默……但是好吧，现在让我回到一些例子，参考第一轮的处理。我已经提供了第一个——如果我们想删除发送电子邮件，我们只需禁用通信系统。当然，稍后，我们可能还会删除事件 #3 的 CRM 侦听器，该侦听器负责同步通信历史记录——但不这样做不会导致任何错误。第二个例子是数据映射。在 Orchestration Pattern 中，Orchestrator 负责跟踪数据结构的变化。即使是数据结构的微小变化也需要在 Orchestrator 中进行调整。我的设计也不是没有这样的问题——但我希望我的事件是用仅描述业务对象基本属性的简单数据模型创建的。当然，Orchestrator Pattern 总是可以使用这样的模型，但是在我的设计中，我们还有一个组件需要改变——Orchestrator Element。

• 使用 Choreography，多于两个组件的更改数量更小

第三轮：业务流程跟踪和数据管理

Krzysztof（采访者）：现在，让我们进入第三轮，我们将讨论数据管理和跟踪流程执行。正如 Sam Newman 在构建微服务中所说：“随着我们开始对越来越复杂的逻辑进行建模，我们必须处理管理跨越单个服务边界的业务流程的问题”。这里有几个问题——您如何看待多个组件之间的共享和维护数据？您有什么计划来验证流程实例的状态？

编曲模式：就我的设计而言，这个主题非常简单。让我从数据管理开始。所有信息都被分类并存储在我的组件中，没有任何不必要的重复。如果一个组件需要更多数据，它只需询问 Orchestrator——它会收集并提供所需的数据，并带有适当的数据映射（例如，由 ESB 平台处理）。现在我的最大优势出现了——跟踪流程直接整合到我的 Orchestrator 中。一个端到端的过程发生并由这个元素管理。只需访问一个组件，您就可以准确地知道自己目前处于流程中的哪个位置。我怀疑 Choreography Pattern 的想法和我的一样简单。

• Orchestration Pattern 中的 Process Tracing 集中在 Orchestrator 组件中

编舞模式：这个话题也可以用我的设计来解决。我也会从数据管理开始。对我来说，数据正在组织中与事件和相关标识符（由业务流程发起者生成）共享。可以在组件中复制数据以供进一步使用，并根据组件业务功能调整模型。再看一下 Synch Client Details Response with Choreography Pattern 序列图。在我的设计中，不需要调用第三方来获取数据，因为它正在组件之间同步，以防业务处理需要。下一个主题是跟踪——在这里我同意它对我来说可能比使用 Orchestrator 更复杂。但是，有了流程发起者生成的相关标识符，我们仍然可以轻松地连接组成更大业务流程的子流程。

• Choreography Pattern 中的流程更加分散，因此跟踪可能是一个挑战

编曲模式：所以，看起来我是对的，而且跟踪过程对我来说更容易。编排需要有额外的专用工具来实现这一目的——我也可以使用我的 Orchestrator 来扮演那个角色。更重要的是，使用存储在我的 Orchestrator 中的数据，我可以轻松地做出报告和关键决策。Choreography 提出的这种分布式逻辑可能是一个真正的挑战。

编舞模式：我同意——这很有挑战性。但是如果没有集中式决策引擎，我们可以使用更轻量级的工具进行跟踪，而不是使用 Orchestrator 来完成所有工作。报告也是如此——我可以拥有一个专门为此而设计的系统或微服务。这种方法广泛用于微服务生态系统。我只是喜欢我的架构组件是自主的和独立工作的，提供特定的、定义明确的业务功能——而不是一个复杂的 Orchestrator，很容易成为组织的中央 IT 系统。

第 4 轮：组织影响

Krzysztof（采访者）：哇，我们在第三轮进行了非常激动人心的讨论。在他们的最后一句话中，Choreography 提到了组织的影响。现在，让我们讨论一个高层次的观点。当组织选择你作为一种广泛使用的模式时，你认为组织会如何改变？您是否认为 IT 系统设计会影响公司的运作方式？或者可能是其他情况——公司结构反映在 IT 生态系统中？

编舞模式：这实际上是一个非常有趣的问题。这位首席执行官兼编舞师会对他的董事们说：“我的愿景是成为欧洲最大的卫生口罩生产商。我现在全神贯注于你的想法”。然后，营销总监会想出一个新市场的活动，营销总监会立即开始计算他当前的销售水平，工厂总监会等待营销总监对销售的预测，这样他们就可以调整他们要购买的产品数量。需要创建。这种方法有两大优势。首先，这些董事对他们的想法和意见负全部责任。他们知道，公司的成长也是他们的功劳。第二个好处是CEO的工作量少了很多，他的责任负担也更小了。

编曲模式：确实，这是一个相关的问题。编排在组织中引入了严格的顺序，这是编排的一个关键弱点，该顺序可能没有明确定义。CEO-Orchestrator 会对他的董事们说：“我的愿景是成为欧洲最大的卫生口罩生产商。为此，我希望营销总监为新市场创建活动，销售总监专注于当前的销售水平，以免不必要的财务问题困扰我们，工厂总监将产量翻倍”。这位 CEO 考虑周全，整个公司都知道他会带领他们走向成功。也许他的负担更大——但至少他知道组织是如何运作的。当然，在某种抽象层面上——因为他的主管考虑他们的任务，并在他们的单位中编排流程以实现低级流程。如果您问这是否对 IT 系统设计有任何影响，我会说“是的”。Melving E. Conway 也有同样的观点，这就是他引入康威定律的证据：“任何设计系统（定义广泛）的组织都会产生一个其结构是组织通信结构副本的设计。”就我而言，Orchestrator 将反映组织中强大的管理地位和秩序。

编舞模式：编排不涉及组织中的任何顺序——它只是在多个自主团队之间划分。如果 CEO-Orchestrator 生病了怎么办？如果他错了怎么办？有了编排，我们不仅有更多的讨论空间，还有更多自主、负责任的团队分享他们的投入和改进。我同意编排模式，即 IT 系统设计反映了组织的通信结构。但我会更进一步——我相信在 IT 系统中实施编排模式将使小团队开始以同样的方式工作。然后，编排正在更大的组织单位中传播，最后——它会传到 CEO 身上。明智的人会注意到，他不再孤单地做决定，他可以委派更多的工作，并且他可以依靠团队对他们的业务职能完全负责。归根结底，他的工作会更少，操心的事情也会更少，他的员工也会对组织更有责任感。总结一下——我同意康威定律有效，但对我来说，它也可以反过来起作用。在这种情况下，微服务和编排将导致小型、敏捷、面向业务的团队。

编曲模式：有了我，这位 CEO 会立即知道他错了。通过简单的流程跟踪和监控结果，很容易在流程中发现错误。使用 Choreography Pattern，您可能知道某些事情运行不正常，但您将花费更多时间进行调试并寻找负责的单元。我可以同意的是，康威定律也适用于相反的情况——拥有一个或几个业务规则实施系统，我们很快就会提出一个类似的管理结构来制定关键的业务决策。

结论

Krzysztof（采访者）：感谢您的参与、见解和分享的想法。我希望这场辩论会在接下来的几周、几个月和几年内非常有帮助，届时数十个组织将投票选出在他们的项目中使用的最佳模式。就个人而言，我会投票给编舞模式。我不认为编曲模式是一个糟糕的模式——但是使用编舞设计的解决方案更加灵活，与技术无关，并且可以量身定制以满足客户的要求。 Choreography Pattern 还帮助我们构建了 Starboost——微服务画布，它被证明是可靠的、可扩展的和可调整的，适用于真实案例的业务场景。我相信 Choreography 将使 IT 系统再次变得伟大，它在当前和即将到来的项目中拥有我的投票权。亲爱的读者，你呢？

谢谢大家关注，转发，点赞和点在看。