https://juejin.cn/post/7283416371596558373

基础

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

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

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

亮点

同步转异步

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

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

自动替换第三方

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

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

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

压测支持

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