7 调用第三方：下游的接口不稳定性能又差怎么办？

基础
对于自己系统内这样一个第三方模块或者第三方服务来说，它要解决的问题也很直观。

提供一个一致性抽象，屏蔽不同第三方平台 API 之间的差异。
提供客户端治理，即提供调用第三方平台 API 的重试、限流等功能。
提供可观测性支持。
提供测试支持。

在任何跟第三方打交道的场景之下，都要考虑好第三方崩溃的时候自己的系统怎么容错。公司或者部门内部的调用出现问题了，还可以推动同事快速修复。但是第三方是推不动的，所以只能是我们调用者考虑容错。

亮点
同步转异步
在一些不需要立刻拿到响应的场景，如果你发现第三方已经崩溃了，你可以将业务方的请求临时存储起来。等后面第三方恢复了再继续调用第三方处理。这种方案一般用于对时效性要求不高的业务。

我们这种容错机制其实完全可以做成利用消息队列来彻底解耦的形式。在这种解耦的架构下，业务方不再是同步调用一个接口，而是把消息丢到消息队列里面。然后我们的服务不断消费消息，调用第三方接口处理业务。等处理完毕再将响应通过消息队列通知业务方。

自动替换第三方
调用一个第三方的接口失败的时候，你可以考虑换一个第三方。

为了进一步提高可用性，降低因为第三方故障引起事故的概率，我在调用第三方这里引入了自动替换机制。我们本来有多个第三方，相互之间是可以替换的，于是我就做了一个简单的自动切换机制。当我发现第三方接口出现故障的时候，就会切换到一个新的第三方。

你怎么知道第三方出问题了？这个问题可以参考我们前面讲过多次的判断服务健康与否的方式，比如说用响应时间、错误率、超时率。那么自然可以将话题引导到熔断、降级、限流那边。
如果全部可用的第三方都崩溃了怎么办？这种问题直接认怂就可以。因为一家出故障是小概率，多家同时出故障那就更是小概率事件了，在这种情况下你除了告警也没有别的办法了。也就是所谓的尽人事，听天命。

压测支持
考虑通过 mock 来提供压测支持。和正常的测试支持比起来，压测你需要做到三件事。

模拟第三方的响应时间。
模拟触发你的容错机制。如果你采用了同步转异步这种容错机制，那么你需要确保在流量很大的情况下，你确实转异步了；如果你采用的是自动切换第三方，那你也要确保真的如同你设想的那样真的切换了新的第三方。
流量分发。如果是在全链路压测的情况下，压测流量你会分发到 mock 逻辑，而真实业务请求你是真的调用第三方。

早期为了弄清楚服务的吞吐量和响应时间瓶颈，我搞过一些压测。但这些流量不能真的调用第三方，所以我为了解决压测这个问题，设计了两个东西。

一个是模拟第三方的响应时间。不过这种模拟是比较简单的，就是在代码里面睡眠一段时间，这段时间是第三方接口的平均响应时间加上一个随机偏移量计算得出的。另一个是在并发非常高的情况下，会触发我的容错机制。

而且我这里留好了接口，万一我们公司要做全链路压测了，我这边也可以根据链路元数据将压测流量转发到 mock 逻辑，而真实业务请求则会发起真实调用。

内容来源于极客时间《后端工程师的高阶面经》