断路器作为独立服务

Question

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

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

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

因此，我的第一个想法是创造断路器作为独立的服务，但我找不到任何模式描述这样的功能。它是如何工作的？当目标电路关闭时，请求前的每个业务都呼叫断路器服务。如果是这样，它发送请求，当请求完成，然后报告给断路器服务，该请求是成功还是失败？

或者断路器应该如何正确地投入微业务体系结构？

Answer 1

当您谈论真正的微服务体系结构时，电路中断是一个横切关注点。

你不应该自己实现它。首先，我要说的是，请小心在您的微型服务之间创建意大利面，这是太危险和反模式。虽然这是一种反模式，但我强烈建议您使用云本地平台来部署您的微服务，如Kubernetes或mabye Docker。有许多有用的工具，如特使实现的侧车，使用Istio (不推荐)的服务网格实现，领事和其他Hashicorp产品。您可以使用云本地工具改进您的服务发现、可观察性、监视、中断电路、日志记录、侧微服务通信和其他有用的概念。

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

Answer 2

其次，我一遍又一遍地为每个服务编写相同的功能。

在微服务世界中解决这一问题的方法之一是(正如您正确地注意到的)将此功能移除您的服务。断路仅仅是一个因素，还有许多其他方面，涉及到服务间的通信，你必须处理，例如:处理重试、故障转移、身份验证和授权、跟踪、监视等等。如果要在所有服务中单独处理它，您最终会一次又一次地编写相同的代码(或配置各种框架/插件)。

由此产生的解决方案是一个服务网格。您可以认为它是一个中间人，它拦截您的服务之间的所有通信，并处理上述所有方面。有各种各样的解决方案。您可以检查https://github.com/cncf/landscape，找出什么是现在的“热门”，并被认为是一个标准。不过，我建议您熟悉https://istio.io/latest/about/service-mesh/，因为它非常成熟和强大。