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

Question

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

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

流量到达Nginx，代理传递到Facade，facade调用服务(通过负载均衡器)。我们没有使用服务发现。这是HAProxy服务的Nginx/Ips的It外观的静态映射。

现在我想使用限流器/断路器。我们应该在架构中的哪个点执行此操作？我的意思是，我们应该再增加一跳或其他任何东西吗？

为此，我们计划使用resilience4j

Answer 1

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

速率限制器非常愚蠢(它们可能很复杂，但通常是愚蠢的)。有一个门槛，任何超过门槛的东西都是有限的。阈值是根据底层服务的容量或您的应用程序需求(如SLA:假设1个用户每分钟最多进行5次API调用)决定的。有时甚至是为了阻挠DoS。

与速率限制器相比，断路器更具弹性模式，也更智能。它们通过后退一段时间来确保系统的一个组件发生故障不会导致整个系统停机，前提是回退间隔足以满足修复/恢复故障的要求。当第三方没有响应时，你在一定百分比的故障上断开电路，并在一定的退避间隔后继续尝试。当第三方再次开始响应时，您关闭电路。帮助您的系统响应，而不是在下游没有工作时占用大量资源。

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

断路器-当您在下游进行不可靠的呼叫时，当下游可能花费比您预期的时间更长的时间，或者您希望您的服务在一段时间内正常工作而不考虑第三方的可用性时，请使用断路器。您也可以使用它来使您的应用程序响应，但代价是第三方的结果。例如，如果您的下游没有在100ms内响应实时结果，您将以100ms的速度跳闸电路，并显示使用较旧的缓存/默认结果。