第三方接口挂掉，你们的服务会受影响么？
架构要如何优化，才能避免背这口锅呢？
业务需要跨公网调用一个第三方服务提供的接口，为了避免每个调用方都依赖于第三方服务，往往会抽象一个边界服务：
解除调用方与第三方接口的耦合；
当第三方的接口变动时，只有边界服务需要修改，而不是所有调用方均修改；
如上图1-4所述：
业务调用方调用内部service；
内部service跨公网调用第三方接口；
第三方接口返回结果给内部service；
内部service返回结果给业务调用方；
内部服务可能对上游业务提供了很多服务接口，当有一个接口跨公网第三方调用超时时，可能导致所有接口都不可用，即使大部分接口不依赖于跨公网第三方调用。
内部服务对业务方提供的N个接口，会共用服务容器内的工作线程（假设有100个工作线程）；
某个接口跨公网依赖于第三方的接口发生异常，或者网络抖动，导致接口超时（不妨设超时时间为5秒），这个工作线程库可能会被占用5秒钟，然后超时返回业务调用方；
假设这个请求的吞吐量为20qps，言下之意，很短的时间内，所有的100个工作线程都会被卡在这个第三方超时等待上，而其他N-1个原本没有问题的接口，也得不到工作线程处理；
增大工作线程数（不根本解决问题）；
降低超时时间（不根本解决问题）；
垂直拆分，N个接口拆分成若干个服务，使得在出问题时，被牵连的接口尽可能少（不根本解决问题）；
跨公网调用的稳定性优化，有三种常见的方案。
业务场景：通过OpenID实时获取微信用户基本信息。
解决方案：增加一个代理，向服务屏蔽究竟是“本地实时”还是“异步远程”去获取返回结果。
本地实时流程如上图1-5：
(1) 业务调用方调用内部service；
(2) 内部service调用异步代理service；
(3) 异步代理service通过OpenID在本地拿取数据；
(4) 异步代理service将数据返回内部service；
(5) 内部service返回结果给业务调用方；
异步远程流程如上图6-8粗箭头的部分：
(6) 异步代理service定期跨公网调用微信服务；
(7) 微信服务返回数据；
(8) 刷新本地数据；
优点：公网抖动，第三方接口超时，不影响内部接口调用。
不足：本地返回的不是最新数据（很多业务可以接受数据延时）。
有时候，内部service和异步代理service可以合成一个service。
业务场景：调用第三方短信网关，或者电子合同等。
解决方案：同时使用（或者备份）多个第三方服务。
流程如上图1-4：
(1) 业务调用方调用内部service；
(2) 内部service调用第一个三方接口；
(3) 超时后，调用第二个备份服务，未来都直接调用备份服务，直到超时的服务恢复；
(4) 内部service返回结果给业务调用方；
优点：公网抖动，第三方接口超时，不影响内部接口调用（初期少数几个请求会超时）。
不足：不是所有公网调用都能够像短信网关，电子合同服务一样有备份接口的，像微信、支付宝等就只此一家。
业务场景：本地结果，同步第三方服务，例如用户在天鹅到家平台下单，天鹅到家平台需要通知平台商家为用户提供服务。
解决方案：本地调用成功就返回成功，异步调用第三方接口同步数据（和异步代理有微小差别）。
本地流程如上图1-3：
(1) 业务调用方调用内部service；
(2) 内部service写本地数据；
(3) 内部service返回结果给业务调用方成功；
异步流程如上图4-5粗箭头的部分：
(4) 异步service定期将本地数据取出（或者通知也行，实时性好）;
(5) 异步调用第三方接口同步数据;
优点：公网抖动，第三方接口超时，不影响内部接口调用。
不足：不是所有业务场景都可以异步同步数据。
跨公网调用第三方，可能存在的问题：
公网抖动，第三方服务不稳定，影响自身服务；
一个接口超时，占住工作线程，影响其他接口；
降低影响的治标优化方案：
增大工作线程数；
降低超时时间；
服务垂直拆分；
业务需求决定技术方案，治本解决方案：
业务能接受旧数据：读取本地数据，异步代理定期更新数据；
有多个第三方服务提供商：多个第三方互备；
向第三方同步数据：本地写成功就算成功，异步向第三方同步数据；
希望第三方的服务挂掉，不再影响大家的服务。
这个锅，我们不背。
知其然，知其所以然。
思路比结论更重要。
