详解微服务编排

你的组织是否使用微服务风格的体系结构来实现其业务功能？你使用什么方法来实现微服务的通信和编排？在过去的几年中，微服务一直是一个相当占主导地位的应用程序架构，通常与云平台（例如，容器、K8s、FaaS（功能即服务）、临时云服务）结合在一起使用。这些服务类型之间的通信模式差别很大。

微服务体系结构强调独立性和频繁更改的能力，但这些服务通常需要共享数据，并在它们之间发起复杂的交互，以完成它们的功能。在本文中，我们将研究微服务通信的模式和策略。

一、网络中的问题

通过网络进行通信会带来可靠性问题。数据包可能被丢弃、延迟或重复，所有这些都可能导致服务到服务通信的异常和不可靠。在最基本的情况下-服务A打开到服务B的连接-我们非常信任应用程序库和网络本身，以打开连接并向目标服务（在本例中是服务B）发送请求。

图1：服务A调用服务B的简单示例

但如果连接需要很长时间才能打开，会发生什么呢？如果连接超时无法打开该怎么办？如果连接成功，但随后在处理请求之后、响应之前关闭该连接怎么办？

我们需要一种快速检测连接或请求问题并决定如何处理的方法。如果服务A无法与服务B通信，可能会有一些合理的返回（如，返回错误消息、响应固定内容、使用缓存值进行响应）。

图2：调用多个服务的更复杂的示例

在稍微复杂一些的情况下，服务A可能需要调用服务B，从服务B的响应中检索一些值，然后使用它调用服务C。如果对服务B的调用成功，但对服务C的调用失败，那么返回选项可能会稍微复杂一些。

也许我们可以回退到一个预定义的响应，重试请求，根据服务B响应的一些数据从缓存中提取数据，或者调用一个不同的服务？

网络中导致连接或请求失败的问题可能会间歇性地发生，应用程序必须处理这些问题。

随着从给定服务编排的服务调用越多，这些问题就越有可能发生，也越复杂，如图3所示。

图3：尝试编排跨读/写API的多个服务调用示例

当这些服务间的调用不仅仅是“读”调用时，这些问题将变得更加麻烦。

例如，如果服务A调用服务B，服务B执行某种必须与下一次对服务C的调用需使用的数据变更(例如，服务A告诉服务B客户Joe的地址已更新，但还必须告诉服务C由于地址更改而更改运输)，那么这些失败的调用是重要的。

这可能会导致不同服务之间的数据不一致和状态不一致。

这样的网络错误会影响微服务的弹性、数据一致性以及可能的服务级别目标(SLOs)和服务级别协议(SLAs)。

我们需要一种方法来处理这些网络问题，同时考虑在尝试解释故障时突然出现的其他问题。

二、有用的网络弹性模式

构建API和服务来抵御网络的不可靠性并不总是那么容易。服务(包括用于构建服务的框架和库)可能会因为网络而失败，有时会以不可预测的方式发生。这里介绍了一些有助于构建弹性服务通信的模式，但肯定不是唯一的模式。

这三种模式可以根据需要使用，也可以结合使用来提高通信的可靠性（但每种模式都有自己的缺点）：

重试/回退重试-如果调用失败，重新发送请求，可能会等待一段时间再尝试。

幂等请求处理-对一个请求进行多次处理并得到相同结果的能力（可能涉及对写操作的重复删除处理）。

异步请求处理-消除两个服务之间的时间耦合，以确保请求传递成功。

让我们来仔细看看这些模式。

三、具有回退处理的重试

网络的不可靠性随时可能发生，如果请求失败或无法建立连接，最简单的方法之一就是重试。通常，我们需要某种有限的重试次数（例如，“重试两次”VS“无限重试”），并且可能需要一种回退重试的方法。

有了回退机制，我们可以错开调用失败和重试所花费的时间。

关于重试的一个简短说明：我们不能永远重试，也不能将每个服务配置为重试相同次数。重试可能会对“重试风暴”事件产生负面影响，在这些事件中，服务降级，调用服务多次重试，从而对降级的服务施加压力，并最终关闭（或在尝试恢复时将其关闭）。一开始可以在调用链的较高位置使用少量固定的重试次数（例如，两次），并且不要在调用链的较深处重试。

四、幂等请求处理

对于基于传入请求对数据进行更改的服务，服务提供者实现幂等请求处理。一个简单的例子是计数器服务，它保持运行的总计数，并根据传入的请求增加计数。

例如，可能传入一个值为“5”的请求，计数器服务将使当前计数增加5。但是，如果服务处理请求(以5为增量)，但不知何故返回给客户机的响应丢失了（网络丢包、连接失败等），该怎么办？

客户端可能会重试请求，但这将使计数再次增加5，而这可能不是所希望的状态。我们希望服务知道它已经看到了一个特定的请求，然后要么忽略它，要么应用一个“no-op”。如果服务被构建为幂等处理请求，那么客户机可以放心地重试失败的请求，因为服务能够过滤掉那些重复的请求。

五、异步请求处理

对于前面示例中的服务交互，我们已经假设了某种类型的请求/响应交互，但是我们可以通过依赖某种队列或日志机制来在传递中持久化消息并将其交付给使用者，从而减轻网络的一些麻烦。在这个模型中，我们去掉了请求的发送方和接收方在同一时间同时可用的可能性。

我们可以信任消息日志或队列在未来的某个时刻保存和传递消息。重试和幂等请求处理也适用于异步场景。如果消息使用者能够正确地应用可能在“至少一次交付”保证中发生的更改，那么我们就不需要更复杂的事务协调。

六、服务到服务通信的基本工具和考虑事项

为了将弹性构建到服务到服务的通信中，团队可能依赖于额外的平台基础设施，例如，像Kafka这样的异步消息日志或像Istio服务网格这样的微服务弹性框架。可以对具有服务网格的应用程序透明地配置和执行诸如重试、断路和超时等任务。因为你可以从外部控制和配置行为，所以这些行为可以应用于任何/所有应用程序—无论它们是用什么编程语言编写的。此外，可以对这些弹性策略进行快速更改，而无需强制代码更改。

在微服务体系结构中，帮助进行服务编排的另一个工具是GraphQL引擎。GraphQL引擎允许团队跨多个服务展开和编排服务调用，同时负责身份验证、授权、缓存和其他访问机制。GraphQL还允许团队更多地关注特定客户端或服务调用的数据元素。GraphQL最初主要用于表示层客户端(Web、移动端等)，但现在也越来越多地用于服务到服务的API调用。

图4：使用GraphQL引擎编排跨多个服务的服务调用

如上所述，GraphQL还可以与API 网关技术甚至服务网格技术相结合。不管服务之间使用什么协议进行通信（REST、gRPC、GraphQL等），这些都可以提供一个通用且一致的弹性策略层。

七、结论

大多数团队都希望通过云基础设施和微服务架构来实现围绕服务交付和规模的重大承诺。我们可以建立CI/CD、容器平台和一个强大的服务架构，但如果我们不考虑运行时微服务编排和随之而来的弹性挑战，那么微服务实际上只是一个过于复杂的部署架构，具有所有的缺点，没有任何好处。如果你正在使用微服务的路上（或者已经在这条路上走得很好了），请确保服务通信、编排、安全性和可观察性被放在首位，并在你的服务中一致地实现。