很抱歉，如果这个问题不适合。
但是我试图寻找很多答案。
我正在研究断路器的设计模式，据我了解它用于使您的API容错。现在我感到困惑的是，
假设我有调用支付api的API，并且可以说我将电路配置为在5次调用连续失败的情况下打开。
现在按照断路器设计，我将在断开电路后路由后续调用以回退方法。让我们说下5个呼叫，如果是api在线，则在第6个呼叫中我将对支付API进行呼叫。
但是我没有发现这种模式的任何优势，例如捕获块和断路器之间的区别是什么。
我们可以使用后退方法做什么？有什么帮助？
答案 0 :(得分：2)
确实，断路器的大量使用使API能够容错。
就像捕获块和断路器之间的区别是什么。
捕获块和断路器之间的主要区别在于处理故障情况。 假设我们正在调用外部系统的api。 可以说，api调用失败。
如果使用catch块，则将捕获Exception并调用一个fallback方法。 下次我们将调用相同的api，并且外部系统仍处于关闭状态。因此，同样的事件循环将再次发生。 这将不必要地轰炸受苦的外部系统，消耗系统资源，并增加您的api响应时间。
如果使用断路器模式，则我们的第一个调用失败，然后断开电路。下次我们甚至不调用外部系统，而是直接遵循后备模式。瞧，一切都已处理！
我们可以使用后退方法做什么？这有什么帮助？
后备方法的一个很好的例子如下。 我们有一个付款系统，可将付款路由到不同的付款网关。 假设我们从特定的支付网关收到错误，然后使用后备方法将其路由到其他支付网关。
您还可以浏览本文以了解有关此主题的更多信息：https://martinfowler.com/bliki/CircuitBreaker.html
答案 1 :(得分：2)
我们的同事已经展示了断路器的优点，因此我将集中在实际示例上。
因此，在您的示例中，您有一个必须调用支付API的流程>让我们假设其为“外部”组件。如果没有这个电话，整个流程可能不会被视为“已成功完成”（我了解您有一些将付款作为其基本步骤之一的在线流程）。
在这种情况下，除非作为备用，您将付款命令存储在某种中间存储器中，然后“重新应用”付款逻辑，否则断路器确实可能不会有用。
断路器的全部目的是提供一个合理的后备，这样，如果应用后备逻辑，则不会将流程视为失败。
这是断路器更具意义的另一个例子。
如果您构建“类似于netflix的”门户，并且在UI中有一个小部件显示“推荐”电影。推荐引擎会考虑您之前看过/喜欢的电影。从技术上讲，这是一个“外部系统” /微服务。
现在，如果填充UI数据的流程无法获取建议（例如，如果建议服务关闭），您将使整个流程“失败”吗？ 可能不是，最好显示一些推荐电影的“一般列表”，并让用户继续使用该应用程序。
在这种情况下，断路器是实现对外部推荐服务的呼叫的不错选择。
现在，此流程和异常处理之间有什么区别？
如果该推荐系统失败的原因是网络临时中断/数据库运行缓慢，可能是最好的做法是花一些时间而不是一遍又一遍地调用它，我们应该给它一个机会“再度”。 当我们使用断路器时，在“断路”期间，我们的代码甚至不会尝试调用服务器，而是直接路由到后备方法。
另一方面，常规的try / catch块将始终呼叫推荐服务。
最后，断路器是问题中所述的容错模式。它是一种可以在某些情况下适用，而在其他情况下无关紧要的工具。
答案 2 :(得分：0)
此设计模式的目标是封装用于处理意外的重复错误的逻辑。
此模式的wikipedia page的有用部分解释了您希望实现此逻辑以避免发出期望失败的请求的情况。
此模式的优点是什么
当您遇到一种情况，即您知道某个服务将不可用，并且您希望自定义行为直到该服务重新联机时，这种模式非常有用。例如，在数据库迁移期间，将中断请求循环到队列中直到迁移完成才有意义。
捕获块和断路器有什么区别
我认为这种差异是概念和实施之间的差异。如您的示例所示，检测到您想“断开电路”的情况的存在可能意味着检测捕获块中的错误并对其进行计数。但是，处理不仅限于错误。
在我的示例中，后端可能会通知前端即将发生迁移，从而导致前端“断路”，直到接收到迁移完成消息为止。