第三方接口宕机，我们的服务会不会受到影响？一、由来与大坑很多时候，业务需要跨公网调用第三方服务提供的接口，为了避免每个调用者都依赖第三方服务，往往会抽象出一个服务：将调用者与第三方接口解耦当第三方接口发生变化时，只需要修改服务，而不是所有调用者1此时的接口调用流程是怎样的？如上图所示：业务调用者调用内部服务内部服务跨公网调用第三方接口第三方接口返回结果给内部服务内部服务返回结果给业务调用者2.这个过程中存在哪些潜在的陷阱？内部服务可能会为上游业务提供很多服务接口。当某个接口跨公网第三方调用超时时，即使大部分接口不依赖跨公网第三方调用，也可能导致所有接口不可用。3.为什么会出现这种情况？内部服务提供给业务方的N个接口，会共享服务容器中的工作线程（假设有100个工作线程）。假设N个接口中有一个依赖跨公网的第三方接口，出现网络抖动，或者接口超时（超时时间可以设置为5秒）。潜台词就是这个工作线程会被占用5秒，超时后返回给业务调用者。假设这个请求的吞吐量是20qps，言下之意就是在短时间内，100个工作线程都会卡在这个第三方超时等待上，而其他一开始没有问题的N-1个接口都会也会被封锁。不能由工作线程处理。4.潜在的优化方案？增加工作线程数（不能从根本上解决问题）减少超时时间（不能从根本上解决问题）垂直拆分，将N个接口拆分成几个服务，这样当出现问题时，牵连的接口少到可能（还是没有从根本上解决问题，一个服务只提供一个接口吗？）跨公网调用的稳定性优化是本文要讨论的问题。2、异步代理方式业务场景：通过OpenID实时获取微信用户基本信息解决方案：添加代理屏蔽服务是“本地实时”还是“异步远程”获取返回结果。本地实时流程如上图所示：（1）业务调用者调用内部服务（2）内部服务调用异步代理服务（3）异步代理服务通过OpenID在本地取数据（4）异步代理服务将数据返回给内部服务(5)内部服务将结果返回给业务调用者异步远程流程如上图6-8中粗箭头部分所示：(6)异步代理服务定时跨公网调用微信服务（7）微信服务返回数据（8）刷新本地数据优点：公网抖动，第三方接口超时，不影响内部接口调用不足：本地返回不***数据（很多服务可以接受数据延迟）有时候，内部服务和异步代理服务可以合并为一个服务。3、第三方接口备份切换方式业务场景：调用第三方短信网关，或者电子合同等方案：同时使用（或备份）多个第三方服务进程如上图：（1）业务调用者调用内部服务（2）内部服务调用第一个三方接口（3）超时后，调用第二个备份服务，以后直接调用备份服务，直到超时服务恢复（4）内部服务返回结果给业务调用方优点：公网抖动，第三方接口超时，不影响内部接口调用（开始时少数请求会超时）不足：不是所有公网网络调用可以像短信网关和电子合同服务一样有备份接口，比如微信、支付宝等，这是唯一的4.异步调用方式的业务场景：本地结果，同步third方服务。例如，当用户在58到家平台下单时，58到家平台需要通知平台商户为用户提供服务。解决方法：如果本地调用成功，则返回success，异步调用第三方接口同步数据（与异步代理略有区别）。本地流程如上图所示：（1）业务调用者调用内部服务（2）内部服务写入本地数据（3）内部服务成功异步返回结果给业务调用者流程如图上图4-5粗箭头部分：（4）异步服务定时取本地数据（或者通知也可以，实时性好）（5）异步调用第三方接口同步数据优点：公网抖动，第三方接口超时不影响内部接口调用不足：不是所有业务场景都能异步同步数据5.总结跨公网调用第三方可能出现的问题：公网抖动，第三方服务是unstable，影响自身服务某个接口超时，占用worker线程影响其他接口减少影响优化方案：增加workerthr数量eads减少超时时间服务垂直拆分业务需要确定技术方案，结合业务方案：业务可以接受旧数据：读取本地数据，异步代理定时更新数据。存在多个第三方服务商：多个第三方相互准备与第三方同步数据：本地写入成功就算成功，异步数据同步给第三方。希望第三方的服务挂掉，不再影响大家。服务。【本文为专栏作者《58神剑》原创稿件，转载请联系原作者】点此阅读更多该作者好文
