断路器作为独立服务

如何解决断路器作为独立服务

我是第一次构建微服务架构，尽管我已经阅读了很多文章，但我仍然对如何正确实现断路器感到困惑。

假设我有几个相互调用的微服务。因此，我将断路器作为请求拦截器实现到它们中的每一个中，并且它可以工作。但我不喜欢。

首先，每个服务现在需要在断路器打开之前分别达到失败阈值。其次，我一遍又一遍地为每个服务编写相同的功能。

所以我的第一个想法是创建断路器作为独立服务，但我找不到任何描述这种功能的模式。它将如何运作？如果目标电路关闭，则在发出请求之前的每个服务都会首先调用断路器服务。如果是，它发送请求，当请求完成时，向断路器服务报告请求是成功还是失败？

或者说熔断器应该如何正确放入微服务架构中？

解决方法

当您谈论真正的微服务架构时，熔断是cross-cutting-concern

你不应该自己实现它。首先我应该说请小心在你的微服务之间创建意大利面条，这太危险和反模式。 尽管它是一种反模式，但我强烈建议您使用云原生平台来部署您的微服务，例如 Kubernetes 或 mabye Docker。 有很多有用的工具，比如 Envoy 实现的 side-cars、使用 Istio 的服务网格实现（不推荐）、Consul 和其他 Hashicorp 产品。 您可以使用云原生工具改进服务发现、可观察性、监控、断路器、日志记录、侧微服务通信和其他有用的概念。

提示：我强烈建议您在服务之间使用 grpc 而不是 http 请求（减少基于 http3 和 tcp 连接的延迟）

,

其次，我为每个服务编写相同的功能，并且 再来一遍。

在微服务领域解决此问题的一种方法是（正如您正确注意到的）将此功能从您的服务中移除。断路只是一个要素，还有许多其他方面与服务间通信相关，您必须注意，例如：处理重试、故障转移、身份验证和授权、跟踪、监控等。 如果您要在所有服务中单独处理它，您最终会一遍又一遍地编写相同的代码（或配置各种框架/插件）。

从这种需求中产生的解决方案是服务网格。您可以将其视为拦截服务之间所有通信并处理上述所有方面的中间人。 有各种解决方案。您可以检查 https://github.com/cncf/landscape 以找出现在“热门”并被视为标准的内容。 不过，我建议您熟悉 https://istio.io/latest/about/service-mesh/，因为它非常成熟且功能强大。