调用多个第三方接口哪一种方案更好？

Question

目的

用户在下单的时候，会调用我们的后台服务器，我们的后台服务器又会根据不同渠道调用第三方下单接口，完成整个下单流程，但是第三方下单接口可能突然出问题或者不支持，所以目前我们每一种渠道都配置了好几种备用的下单接口，尽可能提高用户下单成功率。

问题

想选择一种更好的方案，来实现同样的效果。

方案

例如： 下单时type = 1 ,后台支持该类型的第三方下单接口有A,B,C。可能A,B,C会突然出问题，或者不支持，或者不稳定等问题。

1. 每次下单轮询A,B,C 3个接口，直到成功为止，此时记录下失败的渠道 ，例如A，当A最近M分钟的失败次数大于N次，则下次下单的时候，只用轮询B,C接口。当最近X分钟内失败的渠道A又开始成功了并且成功次数大于X次，则下单的时候又可以轮询A,B,C，其中A,B,C轮询次数按照优先级排序。
   分析：每次都要轮询，但可以保证例如 X= 2 A失败了2次，此时我可以轮询到B去下单，而不会直接失败。

2. 每次下单前直接确定一个接口A或者B或者C，根据优先级最高且最近M分钟内失败次数没有超过N次的。
   分析：如果N为10次，那么第11次的时候，才会选择一个合适的渠道，例如B。之所以是N次才剔除掉，是因为避免偶然失败情况。

3. 有没更好的方式，解决多渠道(就类似上面可用的下单接口用A,B,C)下单的问题，尽可能提高下单的成功率，尽可能尝试更多的机会，尽可能让用户成功支付，尽可能预知第三方接口的问题(接口改变、服务器挂了、处理慢、业务类型不支持了等问题)

求大神分享经验。。。

1. 需要同步返回给前端是否成功

2. 第三方暂时没提供 比如某个业务类型不支持的错误码

其实大家的回答已经比较接近实际场景了~

感谢~

Answer 1

这个问题你换种角度考虑其实无非就是个负载均衡的问题，不同的是，这里的因素比较随机，并不能直观的去获得负载情况，这种情况下只能自己去设置rank机制了。机制如下，假设保存最近100次的下单成功队列其中A的可用性为53%，B的可用性为30%，C的可用性为17%。那么就以A>B>C的优先级来依次轮询。假如此次A失败了，而B成功了。则可用性变为52%,31%,17%。直至B的可用性超越A，则优先B，此方法可实现自动rank机制，自动平衡使用情况来调整最优策略。

Answer 2

题主也知道不管用什么方法都没法避免调用失败的问题，从大部分的回答里面也能看到，如果要在最少的调用次数下调用成功的话，就需要根据以往的调用结果对A B C分配优先级，在调用时采用策略。上面回答的也挺多的，我再提点思路，题主可以人为的分析一下接口调用失败是呈什么分布，比如对于某个接口而言是不是失败一次之后会连续失败，还是只是偶尔呈点状失败，又比如是不是你对某个调用太频繁的时候才容易出现失败。根据这些再做出来合理的策略估计效果会更接近你所希望的。

Answer 3

如果客户对下单的响应有非常高的要求的话，你就按照第一种方法，但是可以三个同时下单，只要有一个成功了，另外两个就相应取消，不过这种方法对第三方接口有要求，而且第三方接口的各种问题可能影响你也业务服务，比如接口没响应的话会导致你的业务服务处理能力指数级下降。如果客户对下单响应的时间不是非常敏感的话，可以用MQ来做，把下单任务丢给MQ，MQ的消费者可以去下单，成功后将结果回调业务服务。

Answer 4

楼主你除了第二种那个方案，其他的方案做要出问题啊，用户绝对要被重复扣款，比如说你调用A渠道，这个时候A渠道如果出现超时等错误，但是这个情况有可能用户已经被扣款了，俗称掉单，（有时你冲正都退不了款，只能发起退货请求），你只能通过补单查询看看用户是否付款成功，有一定的延迟，你这个时候再把用户分发到B渠道，用户又被扣款一次了，这在三方支付中经常出现的问题，我们的做法是对下游的渠道做个统计，优先选择渠道质量好的进行分发，想楼主这样设计很容易出问题ps:楼上的回答大部分都没做过三方支付，不可能像楼主这样设计，三方支付不可能像分布式服务那样调用接口做的，涉及到钱的问题很敏感，一不小心公司账户上面就会出现短款，白白损失钱