当其中一个微服务宕机时如何处理微服务交互

Question

我是微服务架构的新手。目前我正在为我的微服务使用 Spring Boot，如果其中一个微服务出现故障，故障转移机制应该如何工作？

对于前。如果我们有 3 个微服务 M1,M2,M3 。M1 与 M2 交互，M2 与 M3 交互。如果M2微服务集群宕机了，我们该如何处理？

Answer 1

当任何一个微服务出现故障时，服务之间的交互就变得非常重要，因为故障隔离、弹性和容错是任何基于微服务的架构的一些关键特征。

完全同意 @jayant 的回答，在您的情况下，实现适当的后备机制更有意义，您可以根据用例以及 M1、M2 和 M3 之间的依赖关系实现您想要编写的所需逻辑。如果需要，您还可以在后备中引发事件。

由于您是微服务新手，因此您需要了解以下常见技术和架构模式，以针对您在问题中提出的情况实现弹性和容错。在这里，您使用 Spring-Boot，您可以轻松地将 Netflix-OSS 添加到您的微服务中。

Netflix 发布了Hystrix，这是一个旨在控制远程系统、服务和第 3 方库的访问点的库，提供更大的延迟和故障容忍度。

它包括以下重要特征：

• 断路器和回退机制的重要性：

Hystrix 实现了断路器模式，当服务故障可能导致级联故障一直到用户时，该模式非常有用。当对特定服务的调用超过 circuitBreaker.requestVolumeThreshold（默认：20 个请求）并且失败百分比大于 circuitBreaker.errorThresholdPercentage（默认：> 50%）（默认：10 秒）定义的滚动窗口时metrics.rollingStats.timeInMilliseconds，电路将打开，并且不会进行进一步的调用。

如果出现错误和开路，开发人员可以提供后备方案。后备可能会被链接起来，以便第一个后备会进行其他业务调用。查看Hystrix 的后备实现

• 重试：

当请求失败时，您可能希望自动重试该请求。Ribbon为我们完成了这项工作。 在分布式系统中，一个微服务系统重试可以触发多个其他请求或重试并启动级联效应

这是 Ribbon 的一些属性

sample-client.ribbon.MaxAutoRetries=1

下一个重试服务器的最大数量（不包括第一个服务器）

sample-client.ribbon.MaxAutoRetriesNextServer=1

是否可以重试该客户端的所有操作

sample-client.ribbon.OkToRetryOnAllOperations=true

从源刷新服务器列表的时间间隔

sample-client.ribbon.ServerListRefreshInterval=2000

更多细节 ：-色带属性

• 舱壁图案：

一般来说，舱壁模式的目标是避免系统某一部分出现故障而导致整个系统瘫痪。舱壁图案

Hystrix 中的舱壁实现限制了组件的并发调用数量。这样，等待组件回复的资源（通常是线程）的数量就受到限制。

假设您有一个基于请求的多线程应用程序（例如典型的 Web 应用程序），该应用程序使用三个不同的组件：M1、M2 和 M3。如果对组件 M3 的请求开始挂起，最终所有请求处理线程都将挂起，等待来自 M3 的答复。

这将使应用程序完全无响应。如果对 M3 的请求处理缓慢，并且负载足够高，我们也会遇到类似的问题。实施细节可见实施细节可以在这里

因此，当其中一个微服务发生故障时，在处理微服务交互时需要考虑以下一些因素。