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

Question

目的用户在下单的时候，会调用我们的后台服务器，我们的后台服务器又会根据不同渠道调用第三方下单接口，完成整个下单流程，但是第三方下单接口可能突然出问题或者不支持，所以目前我们每一种渠道都配置了好几种备用的下单接口，尽可能提高用户下单成功率。问题想选择一种更好的方案，来实现同样的效果。方案例如： 下单时type = 1 ,后台支持该类型的第三方下单接口有A,B,C。可能A,B,C会突然出问题，或者不支持，或者不稳定等问题。每次下单轮询A,B,C 3个接口，直到成功为止，此时记录下失败的渠道 ，例如A，当A最近M分钟的失败次数大于N次，则下次下单的时候，只用轮询B,C接口。当最近X分钟内失败的渠道A又开始成功了并且成功次数大于X次，则下单的时候又可以轮询A,B,C，其中A,B,C轮询次数按照优先级排序。分析：每次都要轮询，但可以保证例如 X= 2 A失败了2次，此时我可以轮询到B去下单，而不会直接失败。每次下单前直接确定一个接口A或者B或者C，根据优先级最高且最近M分钟内失败次数没有超过N次的。分析：如果N为10次，那么第11次的时候，才会选择一个合适的渠道，例如B。之所以是N次才剔除掉，是因为避免偶然失败情况。有没更好的方式，解决多渠道(就类似上面可用的下单接口用A,B,C)下单的问题，尽可能提高下单的成功率，尽可能尝试更多的机会，尽可能让用户成功支付，尽可能预知第三方接口的问题(接口改变、服务器挂了、处理慢、业务类型不支持了等问题)求大神分享经验。。。需要同步返回给前端是否成功第三方暂时没提供 比如某个业务类型不支持的错误码其实大家的回答已经比较接近实际场景了~感谢~

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:楼上的回答大部分都没做过三方支付，不可能像楼主这样设计，三方支付不可能像分布式服务那样调用接口做的，涉及到钱的问题很敏感，一不小心公司账户上面就会出现短款，白白损失钱