我是第一次构建微服务架构，尽管我已经阅读了很多文章，但我仍然对如何正确实现断路器感到困惑。
假设我有几个相互调用的微服务。所以我在它们中的每一个中都实现了断路器作为请求拦截器，它可以工作。但我不喜欢它。
首先，现在每个服务都需要在断路器打开之前分别达到失败阈值。其次，我一遍又一遍地为每个服务编写相同的功能。
所以我的第一个想法是创建断路器作为独立服务，但我找不到任何描述这种功能的模式。它是如何工作的？如果目标电路关闭，则发出请求之前的每个服务都会调用断路器服务。如果是这样，它会发送请求，当请求完成时，会向断路器服务报告请求是成功还是失败？
或者应该如何正确地将断路器放入微服务架构中？
【问题讨论】：
标签： microservices circuit-breaker
当你谈论真正的微服务架构时，断路是cross-cutting-concern
你不应该自己实现它。首先我应该说，请小心在您的微服务之间创建意大利面条，这太危险且反模式。 尽管它是一种反模式，但我强烈建议您使用云原生平台来部署您的微服务，例如 Kubernetes 或 mabye Docker。 有很多有用的工具，比如 Envoy 实现的边车、使用 Istio 的服务网格实现（不推荐）、Consul 和其他 Hashicorp 产品。 您可以使用云原生工具改进您的服务发现、可观察性、监控、断路、日志记录、微服务通信和其他有用的概念。
提示：我强烈建议您在服务之间使用 grpc 而不是 http 请求（以减少基于 http3 和 tcp 连接的延迟）
【讨论】：
其次，我为每个服务编写相同的功能，并且 重新来过。
在微服务领域解决此问题的一种方法是（正如您正确注意到的）将此功能从您的服务中移走。熔断只是一个元素，还有很多其他方面，与服务间通信相关，你必须注意，例如：处理重试、故障转移、身份验证和授权、跟踪、监控等。 如果您要在所有服务中分别处理它，您最终会一遍又一遍地编写相同的代码（或配置各种框架/插件）。
从这种需求中出现的解决方案是服务网格。您可以将其视为一个中间人，拦截您的服务之间的所有通信并处理上述所有方面。 有各种解决方案。您可以查看https://github.com/cncf/landscape 以了解现在“热门”并被视为标准的内容。 不过，我建议您熟悉 https://istio.io/latest/about/service-mesh/，因为它非常成熟且功能强大。
【讨论】：