微服务如何一起工作

微服务架构 的最大特点就是可以让软件开发人员设计高度可扩展、高度容错的基于互联网的应用程序。但是平台的微服务实际上是如何通信的呢？他们如何协调他们的活动或首先知道与谁合作？在这里，我们将介绍这些问题的主要答案，以及它们最重要的特点和缺点。在深入研究此主题之前，您可以参考本系列早期发布的文章: 微服务的定义和主要应用和微服务安全性之简介。

紧密耦合 、编排和协同

当每个微服务必须直接与其所有微服务合作伙伴进行对话时，我们就有紧密耦合(Tight Coupling)。结果可能非常有效，但会使所有微服务更加复杂，并且更难更改或扩展。此外，如果其中一个微服务中断，所有的微服务都会中断。

克服紧密耦合的这个缺点的第一种方法是：使用一个中央控制器来管理平台的所有或至少部分微服务，使它们能够同步工作，就像管弦乐队的指挥一样。在这种编排 (Orchestration) ，也称为请求/响应模式，指挥者发出请求，接收他们的答案，然后决定下一步做什么 - 即是否向其他微服务发送进一步的请求，或者将该工作的结果传递给外部用户或客户端应用程序。

编排的补充方法是称为协同 (Choreography) 的分散式架构。这由多个独立工作的微服务组成，每个微服务都有自己的职责，但就像同一个芭蕾舞团中的舞者一样。在协同中，协调发生在没有中央监督的情况下，通过消息根据共同的预定义规则在多个微服务之间流动。

这种消息交换以及发现哪些微服务可用以及如何与它们对话，都是通过事件总线进行的。这些是具有明确定义的 API 的软件组件，用于订阅和取消订阅事件以及发布事件。这些事件总线可以通过多种方式实现，以使用 XML、SOAP 或 Web 服务描述语言 (WSDL) 等标准交换消息。

当一个微服务在总线上发出一条消息时，所有订阅在相应事件总线上监听的微服务都会看到它，并且知道是否以及如何异步响应它，每个微服务都有自己的响应，没有特定的顺序。在这种事件驱动的架构中，开发人员必须编写一个微服务以使其与平台的其余部分交互，也就是它应该在其上生成的事件或等待它们事件总线的订阅命令。

选择编排还是协同？这取决于什么？

微服务最流行的两种协调选择是编排和协同，它们的根本区别在于它们的控制位置：一种将控制分配给异步通信的对等微服务，另一种分配给一个中央指挥，让其他人始终保持一致。

哪个更好取决于每个平台实际使用的特征、需求和模式，可能只有两条规则适用于所有情况。首先是几乎总是应该避免实际的紧密耦合，因为它违背了微服务的理念。异步通信的松耦合 (Loose Coupling) 更符合微服务的基本优势，即独立部署和最大可扩展性。然而，现实世界要复杂一些，所以让我们再多谈谈每种方法的优点缺点。

就编排而言，它的主要缺点可能是集中控制，也通常或成為了单点故障的捷径。编排的一个更常见的缺点是，由于微服务和指挥器可能位于不同的服务器或云上，仅通过公共互联网连接，因此性能可能会受到影响，或多或少是不可预测的，除非连接性非常好。在另一个层面上，通过编排，几乎任何微服务的添加或对其工作流程的更改都可能需要更改平台的许多部分，而不仅仅是指挥。同样适用于故障：当一个编排的微服务出現故障时，一般会产生连锁效应：比如其他微服务会一直等待接收的信息，但因为指挥者出现故障，所以这里便会暂时卡住。从好的方面来说，正是因为“指挥链”和沟通是明确定义的，而且不是很灵活，所以比较容易找出发生了什么问题以及发生在哪里。出于同样的原因，编排有助于对不同功能进行独立测试。因此，只要基于微服务的平台内的通信流定义明确且相对稳定，编排就可能是可行的方法。

在许多其他情况下，协同可以在单个微服务的独立性、整体效率和开发简单性之间提供最佳平衡。

对于协同，服务必须只发出事件，即发生某事的通信（例如，接收到登录请求），并且其所有下游微服务必须只对它做出自主反应。因此，更改微服务不会对上游的微服务产生影响。即使添加或删除微服务也比编排更简单。在另一角度来看，如果在不采取任何预防措施的情况下就去做，它可能会在更多以及更难预测、测试或调试的地方及方式上创造更多出错的机会。将消息送到互联网上以及假设一切正常，但无法知道是否所有收件人都收到了消息，并且都能够以正确的方式做出反应，对于系统集成商来说，这个工作变得非常困难。

总结

某些工作流本身就具有高度同步性和可预测性，但有一些不是。这意味着许多现实世界的微服务平台会选择混合使用这两种方法，以获得性能和抗故障或峰值负载的最佳组合。这是因为临时的峰值负载，可能最好用协同来处理；而后果最严重的故障，更紧密的编排可能更安全。对于系统架构师来说，可能发生的最糟糕的情况可能是设计一个既可以是编排也可以是协同的架构，但并没有真正意识到它是哪一个，可能是因为他们只是将一个预先存在的单一平台移植到微服务中，因此，当出现问题或新需求比预期的设计或测试要困难得多时，就会出现更多的状况。这导致了上面提到的两条一般规则中的第二条：在对微服务的实际负载和通信需求进行最佳估计之前，甚至不要开始在微服务的编排或协同之间进行选择。

要了解有关微服务的更多信息，请考虑Linux基金会的一些免费培训课程，包括：

云基础设施技术之入門課程（LFS151x):

https://training.linuxfoundation.org/training/introduction-to-cloud-infrastructure-technologies/

使用 TARS 构建微服务平台 (LFS153x)：

https://training.linuxfoundation.org/training/building-microservice-platforms-with-tars-lfs153-outline/

WebAssembly 的角色：从云到边缘 (LFD134x)：

https://training.linuxfoundation.org/training/webassembly-actors-from-cloud-to-edge-lfd134x/