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

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)下单的问题，尽可能提高下单的成功率，尽可能尝试更多的机会，尽可能让用户成功支付，尽可能预知第三方接口的问题(接口改变、服务器挂了、处理慢、业务类型不支持了等问题)

求大神分享经验。。。

========================================update 2016-7-7============================

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

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

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

感谢~

Answer 1

I don’t quite understand the difference between channels A, B, C and interfaces A, B, C you described. I’ll just treat it as the same thing.

The problem you encountered is closer to the service degradationproblem that is often encountered in current Internet services, that is: when a service depends on another service that is unavailable, the fallback alternative logic is called.

This fuse mode may meet your needs:

• When the service is unavailable (the error rate reaches a certain threshold), it will automatically be downgraded to the alternative service.

• After a certain time window, re-call the previously unavailable service. If the continuous call is successful, it will be restored. If the call fails, the failed service will no longer be called within the time window.

You need a fuse component to implement automatic downgrade and automatic recovery functions:

1. Define the downgrade strategy, for example: start downgrading when the call error rate reaches more than 50%

2. Define the length of the time window for error rate collection. For example: every 1 minute, re-evaluate the error rate of the request.

3. Define the service timeout to prevent blocked requests from occupying thread resources for longer.

4. Define the use of thread pools to isolate service calls to avoid service avalanche, where one interface is unavailable and all resources are blocked by it, causing all other interfaces to be unavailable

5. Collect the call success rate of alternative interfaces, and dispatch requests based on the success rate when calling the service.

You can use Netflix’s Hystrix to achieve it. The above 1,2,3,4 are quite simple.

Point 5 needs to be implemented by yourself.

Answer 2

The poster’s business scenario has indeed never been encountered in daily work, but it can be compared to a distributed service system.

1. A,B,C can be compared to three ordering services. The backend server will call the ordering service

2. According to the order failure rate of the three interfaces, it is the same as A > B > C,那么就可以把请求先路由到A下单服务上,如果下单失败自动重试N次,N次以后还是失败的话,将A服务降级(下一个订单过来会先路由到B),然后将请求转至B,B的策略和A

3. Start a background thread to regularly explore activities, such as finding A被降级了,就不定期的去尝试调用A接口下单(需要A接口提供一个单独的探活接口),如果发现A通了(也可以按照失败率来判断),那么可以将A上线,那么接下来的请求被再次首先会路由到A on the server

4. Maybe my plan has similar ideas to the poster’s plan 1 or plan 2, but the poster’s plan 1 and plan 2 look very vague (not very understandable)

5. This kind of interface is connected to a third-party interface, and the interface is unstable. It is recommended that the user places an order and calls the server. The server can first store some parameters of the request (put MQ or database), and the background You can start a thread to slowly push these orders through the MQ或者数据库),后台可以启动线程慢慢把这些订单,通过A,B,C interface, and the prompt returned to the user can indicate that the order is being placed. The asynchronous method is used here. One of the main benefits is that if all the interfaces hang up, the synchronous method will give the user the same feeling. If the order continues to fail, you can try again asynchronously after a period of time. When the third party has problems with the third-party interface (interface changes, server hangs, slow processing, business type is not supported, etc.), the fault tolerance rate is even higher.

6. There is a pitfall in the retry mechanism. The order may be placed successfully, but the interface returns a failure, so you may need to rely on the duplication strategy of the third-party merchant

Answer 3

Laxative.
If you think about this problem from another angle, it is actually nothing more than a load balancing problem. The difference is that the factors here are relatively random and you cannot intuitively obtain the load situation. In this case, you can only do it yourself Let’s set up the ranking mechanism. 负载均衡的问题，不同的是，这里的因素比较随机，并不能直观的去获得负载情况，这种情况下只能自己去设置rank机制了。
机制如下，假设保存最近100次的下单成功队列The mechanism is as follows, assuming that the last 100 Order Success Queues are saved
The availability of A is 53%, the availability of B is 30%, and the availability of C is 17%. Then poll them in order with the priority of A>B>C. Suppose A fails this time and B succeeds. The availability becomes 52%, 31%, and 17%.
Until B's availability exceeds A, B will be given priority. This method can implement an automatic ranking mechanism and automatically balance usage to adjust the optimal strategy.

Answer 4

The questioner also knows that no matter what method is used, there is no way to avoid the problem of call failure. You can also see from most of the answers that if you want to call successfully with the minimum number of calls, you need to compare A B C based on the previous call results. Assign priorities and apply strategies when calling. There are quite a lot of answers above. Let me give you some ideas. The questioner can artificially analyze the distribution of interface call failures. For example, for a certain interface, does it fail once and then continue to fail, or does it only happen occasionally? Point failure, for example, is it easy to fail when you make a certain call too frequently. Based on these, you can make a reasonable strategy and estimate the effect will be closer to what you want.

Answer 5

I think using activemq should satisfy you

Answer 6

If the customer has very high requirements for the response to the order, you can follow the first method, but you can place three orders at the same time. As long as one is successful, the other two will be canceled accordingly. However, this method is not suitable for the third order. There are requirements for third-party interfaces, and various problems with third-party interfaces may affect your business services. For example, if the interface does not respond, your business service processing capabilities will decrease exponentially.
If the customer is not very sensitive to the order response time, you can use MQ to do it, and leave the order task to MQ. MQ consumers can place the order, and after success, the result will be called back to the business service.

Answer 7

Original, except for the second option, other options will cause problems. Users will definitely be deducted repeatedly. For example, if you call channel A, if channel A has a timeout or other errors at this time, but in this case, the user may The money has been deducted, commonly known as Order Drop, (sometimes you can't get a refund even if you make a correction, you can only initiate a return request), you can only check whether the user has paid successfully through the replenishment order query, there is a certain delay, you When the user is distributed to channel B, the user is deducted again. This is a problem that often occurs in third-party payments. Our approach is to make statistics on downstream channels and give priority to channels with good quality for distribution. I would like to post this It’s easy to go wrong with this design

ps: Most of the answers above have never done three-party payment. It is impossible to design it like the poster. Three-party payment cannot be done by calling interfaces like distributed services. Issues involving money are very sensitive. If you are not careful, you can use company accounts. Short payment will appear on it and you will lose money in vain