第三方接口不稳定经常超时，如何处理三方接口异常不影响自己接口？
典型回答
这种情况还挺常见的，我们经常需要调外部的服务，但是有的时候外部服务又不稳定，经常会失败或者超时，那么我们怎么避免因为他们的超时而影响到我们自己的接口呢？
有以下几种办法可以选择。
NO.1
异步处理
对于一些可以异步请求第三方的场景，我们应该尽可能用异步的方案，包括MQ，异步线程，甚至是离线文件同步等方案。这种异步的方案我们用的非常多。
异步的话至少能保证我们给上游的返回是不受影响的。但是异步的话需要注意的是，我们需要有个收单的过程，就是别人请求过来的时候，我们做一下收单，然后收单成功之后就给上游返回成功，然后再异步处理。如果异步失败了，则根据收单记录进行重试。
这样做的话，还需要引入一个回调或者反查机制，因为我们只是告诉上游收单成功了，是否真正成功他是不知道的，所以需要有个回调或者反查的机制。
很多人看完之后一定会觉得复杂，但是其实大家对接过很多第三方的话就能发现，其实他们很多接口也都是这么做的，都是先收单，然后处理结果有了之后在回调，或者需要我们主动反查。
这是一种非常常见的做法，目的就是提升整体的吞吐量，以及减少对下游的强依赖。
NO.2
设置超时机制
如果是同步调用，也不是没有办法，那就是我们设定一个超时时间，不管下游需要多少秒，我们执行的时候，如果超过我们给定的时间，就直接结束请求。避免被下游给拖垮，比如以下做：
在我们发现超时之后，可以通过一些降级手段做返回，比如如果是查询接口的话，可以返回默认值，或者上次查询结果的值都可以。如果是写操作稍微麻烦一点，就需要约定好一些超时的处理策略，以及引入幂等+重试的机制了。
但是不管怎么样，这个超时机制还是非常有必要的，可以在关键时刻救命。
NO.3
熔断机制
如果大家知道熔断的话，就会知道，我们可以借助熔断器实现当第三方接口的错误率或超时次数达到一定阈值时，停止请求该接口一段时间（熔断状态），然后逐渐恢复流量。
我们可以借助hystrix、sentinel等工具帮我们实现快速熔断，这样就能很好的避免我们自己被拖垮，也可以避免给下游造成进一部分压力。
NO.4
业务取舍
大家知道最开始余额宝被做出来主要是干嘛的吗？其实最初是为了解决支付成功率低的问题的。
大促期间就是因为银联等外部渠道支付成功率太低了，但是很多人又因为银行有收益所以把钱存在银行。
那为了解决这个问题，一个好的办法，就是在业务上给用户多一个选择，让用户减少使用银行卡支付的概率。
就假如说，高德聚合打车，发现外部服务商技术都太差了，他做了自营，是不是也能大幅度降低对外部机构的依赖问题呢？
