API架构中断路器设计模式的优势是什么?

我们的同事已经展示了断路器的优点,所以我将集中介绍一些实际的例子。

因此,看看您的示例,您有一个必须调用支付API的流>假设它是一个“外部”组件。如果没有这个调用,整个流程可能就不能被认为是“成功完成的”(我知道您有一些在线流程,其中付款是其基本步骤之一)。

在这种情况下,断路器确实可能没有那么有用,除非作为后备,您将支付命令存储在某种中间存储中,然后“重新应用”支付逻辑。

断路器的关键是提供

这是另一个断路器更有意义的例子。

如果你建立了一个“类似netflix”的门户网站,并且在UI中有一个显示“推荐”电影的小部件。推荐引擎会考虑您以前看过/喜欢的电影。从技术上讲,这是一个“外部系统”/微服务。

在这种情况下,断路器是实现对外部推荐服务的调用的一个很好的选择。

如果该推荐系统失败的原因是某个临时网络中断/数据库缓慢,那么最好给这个服务一点时间,不要试图反复调用它,我们应该给它一个“休养”的机会。 当我们应用断路器时,在“断路”期间,我们的代码甚至不会尝试调用服务器,直接路由到回退方法。

总是 打电话给推荐服务。

总之,断路器是一种容错模式,正如问题中所述;它是一种工具,在某些情况下适用,在其他情况下不适用。

的确,大量使用断路器是为了使API具有容错性。

比如说挡块和断路器的区别。

挡块和断路器之间的主要区别在于故障情况的处理。 假设我们正在调用一个外部系统的api。 比方说,api调用失败了。

1. 如果我们使用catch块,我们将捕获异常并调用fallback方法。 下一次我们将调用相同的api,而外部系统仍处于关闭状态。所以同样的事件循环会再次发生。 这将对外部系统造成不必要的轰击,消耗系统资源,并增加api响应时间。

2. 如果我们使用断路器模式,那么我们的第一个呼叫失败,然后我们打开电路。下一次我们甚至不会调用外部系统,而是直接遵循回退模式。瞧,一切都搞定了!

我们有一个支付系统,将支付路由到不同的支付网关。 假设我们从一个特定的支付网关得到一个错误,那么在回退方法中,我们可以将它路由到不同的支付网关。

您还可以阅读本文以了解有关此主题的更多信息: https://martinfowler.com/bliki/CircuitBreaker.html

这个 wikipedia page 对于此模式,有一些有用的部分解释了您希望实现此逻辑以避免发出预期失败的请求的情况类型。

这种模式的优点是什么

挡块和断路器有什么区别

我认为这个区别就是概念和实现的区别。检测到您想要“打开电路”的情况可能意味着检测catch块中的错误并对其进行计数,如您的示例所示。然而,处理不仅仅限于错误。