微服务架构中的断路器

Question

在微服务架构中添加断路器模式的最佳方法是什么？它应该在微服务端（每个微服务内部），ELB内部还是内部Api网关？什么是最好的设计模式？

Answer 1

我认为不是在每个微服务中使用，而是在使用微服务的BFF（前端后端）中使用。您可以在本书https://pragprog.com/book/mnee/release-it中找到一个好的实现并举例说明。使用API​​ Gateway的解决方案很好，请参阅Kong https://getkong.org/。

Answer 2

我建议您将断路问题委托给类似Hystrix的外部库，而不要自己实现。 Hystrix公开了许多属性，可让您完全控制调试电路的功能。

Answer 3

至少有 3 个选项（如下图所示）。在一般情况下，断路器“保护”对 http 服务的调用。如果我们认为该服务是微服务，那么断路器从不在微服务本身中。

API 网关

在这种情况下，您使用具有熔断支持的 API 网关产品。大使和 Axway 就是例子。另一种方法是在 BFF 服务中提供熔断机制，以获取对后端服务的调用。

服务网格

在这种情况下，您使用支持断路的服务网格产品。带有 Envoy 的 Istio 就是一个例子。在此示例中，insurance quote 服务调用 customer history 服务。代理 sidecar 容器负责断路器。

断路器库

这里使用了一个提供断路器支持的库。 Resilience4J 是我们在工作中使用的（在一些调用 http 服务的 Spring Boot 应用中）。

您的设计

哪个最好？这取决于您的应用程序要求和基础设施限制。需要记住的事情：

• 并非所有服务交互都需要断路。
• 看看是否可以在电路打开时使用回退机制（例如，默认响应）。
• 记录/监控电路变化以检测有问题的连接和服务。