如何使用限速器/断路器建筑问题

问题描述

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

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

流量进入Nginx，代理传递给Facade，Facade调用服务（通过负载均衡器）。 我们没有使用服务发现。这是HAProxy的Nginx /服务Ips处IP外观的静态映射。

现在，我想使用速率限制器/断路器。我们应该在架构的哪一点上做到这一点？我的意思是我们应该再增加一跳还是其他？

我们计划为此使用resilience4j

解决方法

速率限制器和断路器用于两种不同的使用情况。

速率限制器非常笨拙（它们可能很复杂，但通常很愚蠢）。有一个阈值，超过阈值的任何内容都是有限的。阈值取决于基础服务的容量或您的应用程序要求（例如SLA：假设1个用户每分钟最多进行5个API调用）。有时甚至阻止DoS。

与速率限制器相比，断路器更具有弹性，并且更智能。它们假定后退间隔足以恢复/恢复故障，从而确保系统某个组件的故障不会由于退回一段时间而导致整个系统瘫痪。当第三方不响应时，您会按一定百分比的故障跳闸以断开电路，并在经过一定的退避间隔后继续尝试。当第三方再次开始响应时，您将关闭电路。当下游无任何工作时，帮助您的系统做出响应，而不浪费资源。

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

断路器–当您在下游进行不可靠的呼叫时，下游会花费比您预期更多的时间，或者您希望服务在一段时间内起作用而与第三方的可用性无关，则使用断路器。您也可以使用它来使您的应用程序具有响应能力，但要以牺牲第三方的结果为代价。例如-如果您的下游没有在100ms内获得实时结果响应，则您将电路在100ms处跳闸并显示使用较早的缓存/默认结果。