API 架构中断路器设计模式的优势是什么? [英] What is advantage of circuit breaker design pattern in API architecture?
问题描述
很抱歉，如果这个问题不适合 SO.
So sorry if this question is not fit for SO.
但我试图寻找很多答案.
But I tried looking lot for answer.
我正在研究断路器设计模式，据我所知，它用于使您的 API 容错.现在我感到困惑的是，
I was studying Circuit Breaker design pattern, As I understand its used for making you API fault tolerance. Now what I am confuse is,
假设我有调用支付 API 的 API，假设我将电路配置为在 5 个调用连续失败时打开.
Let say I have API which calls payment api, and lets say I configured my circuit to open if 5 calls fail continuously.
现在根据断路器设计，我将在打开电路后路由后续调用以回退方法.假设接下来的 5 次调用，如果 api 在线，我将在第 6 次调用时调用支付 API，我将关闭电路.
Now as per circuit breaker design, I will route subsequent calls after opening circuit to fall back method. lets say next 5 calls, and on 6th call I will make a call to payment API if api is online I will close circuit.
但我没有发现这种模式的任何优势，比如 catch block 和断路器之间的区别.
But I dont find any advantage of this pattern, Like what is difference between catch block and circuit breaker.
我们可以在回退方法中做什么?这有什么帮助?
And what can we do in fall back method? How can this help?
推荐答案
我们的同事已经展示了断路器的优势，所以我将专注于实际示例.
Our colleagues have already shown the advantages of a circuit breaker, so I'll concentrate on practical examples.
因此，看看您的示例，您有一个必须调用支付 API 的流程> 让我们假设它是一个外部"组件.如果没有这个电话，整个流程可能不能被视为成功完成"(我知道您有一些在线流程，将付款作为其基本步骤之一).
So, looking at your example, you have a flow that has to call a payment API> Let's assume its an "external" component. Without this call, the whole flow probably can't be considered as "successfully completed" (I understand you have some online process that has a payment as one of its essential steps).
在这种情况下，断路器确实可能不会那么有用，除非您将支付命令存储在某种中间存储中作为后备，然后重新应用"支付逻辑.
In this case Circuit Breaker indeed probably won't be that useful unless as a fallback you store the payment command in some kind of intermediate storage and then "re-apply" the payment logic.
断路器的全部意义在于提供一个合理的回退，这样如果应用回退逻辑，流程就不会被视为失败.
The whole point of a circuit breaker is to provide a reasonable fallback so that the flow won't be considered as failed if the fallback logic gets applied.
这是断路器更有意义的另一个例子.
Here is another example where Circuit breaker has much more sense.
如果您构建了一个类似 netflix"的门户，并且在 UI 中会有一个显示推荐"电影的小部件.推荐引擎会考虑您之前看过/喜欢的电影.从技术上讲，这是一个外部系统"/微服务.
If you build a "netflix-like" portal and in UI there is a widget that shows "recommended" movies. The recommendation engine takes into consideration the movies you've seen / liked before. Technically this is an "external system"/microservice.
现在，如果填充 UI 数据的流程无法获得推荐(例如，如果推荐服务关闭)，您会失败"整个流程吗?可能不是，也许最好显示一些推荐电影的通用列表"并让用户继续使用该应用程序.
Now, what if the flow that populates the data for the UI, is not able to get the recommendations (for example, if the recommendation service is down), will you "fail" the whole flow? Probably not, maybe its better to show some "generic list" of recommended movies and let the user proceed to work with the application.
在这种情况下，断路器可能是实现对外部推荐服务调用的不错选择.
In this case, the Circuit breaker can be a good choice for implementing the call to external recommendation service.
现在，这个流程和异常处理有什么区别?
Now, what's the difference between this flow and exception handling?
如果推荐系统失败的原因是临时网络中断/数据库缓慢，可能最好给这个服务一些时间而不是一遍又一遍地调用它，我们应该给它一个机会来恢复".当我们应用断路器时，在开路"期间，我们的代码甚至不会尝试调用服务器，直接路由到回退方法.
If the reason for the failure of that recommendation system is some temp network outage / Database slowness, probably its the best to give this service some time and not to try to call it over and over again, we should give it a chance to 'recuperate'. When we apply a circuit breaker, during the "open-circuit" period our code won't even try to call the server, directly routing to the fallback method.
另一方面，常规的 try/catch 块将总是调用推荐服务.
A regular try/catch block, on the other hand, will always call the recommendation service.
总而言之，断路器是问题中所述的容错模式；它是一种工具，在某些情况下适用，而在其他情况下则无关紧要.
So to wrap up, a circuit breaker is a pattern for fault tolerance as was stated in the question; its a tool which can be applicable in some situations, and irrelevant in other cases.
这篇关于API 架构中断路器设计模式的优势是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
