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