很抱歉，如果这个问题不适合 SO。
但我试图寻找很多答案。
我正在研究断路器设计模式，据我所知，它用于使您的 API 容错。现在我困惑的是，
假设我有调用支付 API 的 API，假设我将电路配置为在 5 个调用连续失败时打开。
现在根据断路器设计，我将在打开电路后路由后续调用以回退方法。让我们说接下来的 5 次调用，如果 api 在线，我将在第 6 次调用时调用支付 API，我将关闭电路。
但我没有发现这种模式的任何优势，比如 catch block 和断路器之间的区别。
我们可以在回退方法中做什么？这有什么帮助？
最佳答案
我们的同事已经展示了断路器的优势，所以我将专注于实际示例。
因此，查看您的示例，您有一个必须调用支付 API 的流程> 让我们假设它是一个“外部”组件。如果没有这个电话，整个流程可能不能被视为“成功完成”(我知道您有一些在线流程，将付款作为其基本步骤之一)。
在这种情况下，断路器确实可能不会那么有用，除非作为后备，您将支付命令存储在某种中间存储中，然后“重新应用”支付逻辑。
断路器的全部意义在于提供合理的回退，以便在应用回退逻辑时不会将流程视为失败。
这是断路器更有意义的另一个例子。
如果您构建了一个“类似 netflix”的门户，并且在 UI 中会有一个显示“推荐”电影的小部件。推荐引擎会考虑您之前看过/喜欢的电影。从技术上讲，这是一个“外部系统”/微服务。
现在，如果填充 UI 数据的流程无法获得推荐(例如，如果推荐服务关闭)，您会“失败”整个流程吗？
可能不是，也许最好显示一些推荐电影的“通用列表”并让用户继续使用该应用程序。
在这种情况下，断路器可能是实现对外部推荐服务的调用的不错选择。
现在，这个流程和异常处理有什么区别？
如果那个推荐系统失败的原因是一些临时网络中断/数据库缓慢，可能最好给这个服务一些时间而不是一遍又一遍地调用它，我们应该给它一个“恢复”的机会'。
当我们应用断路器时，在“开路”期间，我们的代码甚至不会尝试调用服务器，直接路由到回退方法。
另一方面，常规的 try/catch 块将 始终 调用推荐服务。
所以总结一下，正如问题中所述，断路器是一种容错模式；它是一种可以在某些情况下适用而在其他情况下无关紧要的工具。