第三方接口挂掉，最好是不影响我们自身服务的运行，但是我们没有办法控制第三方接口稳定，所以我们需要优化我们的调用架构。

基本情况

我们以跨公网调用其他平台接口为例，很多时候，业务需要跨公网调用一个第三方服务提供的接口，为了避免每个调用方都依赖于第三方服务，往往会抽象一个服务，所以基本调用流程都是

可见基本流程

• 业务调用方调用内部service
• 内部service跨公网调用第三方接口
• 第三方接口返回结果给内部service
• 内部service返回结果给业务调用方

内部服务可能对上游业务提供了很多服务接口，当有一个接口跨公网第三方调用超时时，可能导致所有接口都不可用，即使大部分接口不依赖于跨公网第三方调用。

而且我们经常会遇到这种情况，内部服务对业务方提供的N个接口，会共用服务容器内的工作线程（假设有100个工作线程）。假设这N个接口的某个接口跨公网依赖于第三方的接口，发生了网络抖动，或者接口超时（不妨设超时时间为5秒）。

解决方案

最常想到的就是，加大调用次数，降低超时时间，或者拆分业务，但是都不能重根本上解决问题。

异步代理法

增加一个代理，向服务屏蔽究竟是“本地实时”还是“异步远程”去获取返回结果

本地实时流程

• 业务调用方调用内部service
• 内部service调用异步代理service
• 异步代理service通过OpenID在本地拿取数据
• 异步代理service将数据返回内部service
• 内部service返回结果给业务调用方

异步远程流程

• 异步代理service定期跨公网调用微信服务
• 微信服务返回数据
• 刷新本地数据

这样公网抖动，第三方接口超时，不影响内部接口调用，只会返回的不是最新的数据，很多业务场景都是适用允许的。

第三方接口备份与切换法

同时使用（或者备份）多个第三方服务。这样就可以调用第一个三方接口超时后，调用第二个备份服务，未来都直接调用备份服务，直到超时的服务恢复，这样公网抖动，第三方接口超时，不影响内部接口调用（初期少数几个请求会超时），但是不是所有公网调用都能够像短息网关，电子合同服务一样有备份接口的，像微信、支付宝等就只此一家

异步调用法

本地调用成功就返回成功，异步调用第三方接口同步数据（和异步代理有微小差别），其实就是将数据拉到本地。