如何使用速率限制器/断路器（架构问题）

Question

我们的微服务后端具有以下架构。

< Nginx> -----> <Facade Layer(built in JAVA/Springboot> -------Load Balancer(HAProxy) --- <Service Layer(built in JAVA/Springboot)>

流量到达 Nginx，代理传递到 Facade，Facade 调用服务（通过负载均衡器）。我们没有使用服务发现。它是 Nginx 的 IP Facades/HAProxy 的服务 IPs 的静态映射。

现在我想使用速率限制器/断路器。我们应该在架构中的哪个点执行此操作？我的意思是我们应该再添加一跳还是其他什么？

我们计划为此使用resilience4j

Answer 1

速率限制器和断路器适用于 2 种不同的用例。

速率限制器非常愚蠢（它们可能很复杂，但通常是愚蠢的）。有一个门槛，超过这个门槛就受到限制。阈值是根据底层服务的容量或应用程序要求决定的（例如 SLA：假设 1 个用户每分钟最多进行 5 次 API 调用）。有时甚至是为了阻止 DoS。

断路器比速率限制器更具弹性模式并且更智能。它们通过回退一段时间来确保系统某个组件的故障不会导致整个系统瘫痪，假设回退间隔足以修复/恢复故障。当第 3 方没有响应时，您会因一定比例的故障而跳闸，并在一定的退避间隔后继续尝试。当第三者再次开始响应时，您关闭电路。帮助您的系统做出响应，并且在下游未完成任何工作时不会占用资源。

您需要在什么级别拥有它们 - 像往常一样，这取决于。一般来说，速率限制器是 DDoS 的第一道防线，并在负载均衡器/反向代理级别实施。可以在外观层放置更多应用程序感知阈值。尝试将它们从应用程序中抽象出来。

断路器 - 当您向下游进行不可靠的调用时，或者下游可能花费比您预期更多的时间，或者您希望服务运行一段时间（无论第 3 方是否可用）时，请使用 then。您还可以使用它来使您的应用程序响应，但会牺牲第 3 方的结果。例如，如果您的下游未在 100 毫秒内响应实时结果，则您的电路会在 100 毫秒时跳闸，并显示使用旧的缓存/默认结果。