为什么要强调第三方服务调用治理？

因为第三方服务不在我们的控制范围内，它就像个不定时炸弹，冷不丁就炸了。

什么叫不在你的控制范围内？

举个例子，你写的维护的代码，一定在你的控制范围内，因为你想怎么写就怎么写，想怎么改就怎么改，这就叫在控制范围之内。

你同事写的代码呢，它们在你的控制范围内吗？它们不在你的控制范围内，它们属于在你的可影响范围内。

比如你同事写的代码有bug，你可以告诉他催促他修改的，它们属于你影响力可以覆盖的范围内。如果你的同事与你不在一个组或不在一个部门，那你的影响力对他就相对弱一些，出现问题沟通将会有点困难。

有个特点，距离你越远，与你就越难沟通，你的控制力就越小，而最远的距离就是莫过于第三方服务了，和你就不是一家公司。 它的一切就完全不在你的控制范围内了。一旦接口需要调整，你想让它修改，太难了。

因为它们完全不可控，所以一切与第三方打交道的地方都需要做好容错。严格意义上，你与同事打交道，甚至是自己写的代码都需要做容错。但凡代码不是你自己写的，都需要做容错，哪怕是自己写的，最好也要做一点容错。

为什么要做容错？你是否也有这样的体验？

很多时候，不管是你的合作者，还是银行、甲方、乙方、第三方服务、微信的接口，他们通常都会拍着胸脯和你讲，保证我们的接口没有问题，如果有问题也是你使用错了。其实这种保证是不作数的，不要轻易相信他们。嘿嘿，就好像我们和测试也是这样说的，接口没问题，结果一测一个不吱声。

记住血泪的教训

针对第三方服务的解决方案

既然第三方的接口是不可信的，它们迟早要崩的，那有什么应对方法呢？如何防止发生呢，或者当他发生时，如何让系统还能保持基本的稳定，实际中，一旦我依赖的服务崩溃后，系统不受影响的概率是非常小的，所以我们只能说尽量缩小它的影响范围，简短它的影响时间。

应对的核心有两点：

• 尽量不要搞崩第三方

  比如短信服务，有人可能疑问，我们怎么可能把短信接口搞崩，这感觉距离我们很遥远。其实这个很容易，需要我们将眼界放宽点，比如我们自己没有控制住，放了很多请求过去，就有可能将其冲垮。此时又来了疑问？难道短信那边没有限流吗？其实他们也有限流，也确实做了限流，但是我们不清楚他们的限流到底好不好用，即使他们是大厂。所以站在我们自己的角度，这些关键的第三方服务，我们需要考虑，不能将他们打垮。微信这些大厂技术实力还好，它们基本都会有治理措施，那如果我们和一些技术实力不是很强的第三方打交道，就要小心，不要搞崩他们的接口，找他们他们一般不会怪自己的接口有问题，反而会问我们，你们为什么要这么做，为什么要把那么多的流量打过来，你们自己为什么不做控制。

• 万一第三方崩了，你的额系统还要能够稳定运行。

  也是拿具体短信服务举例，短信服务商本身也有可能崩溃，夸张点，比如运营商的电缆被人挖断了，即使他们能做到99.99%的可用性，但是仍然会存在拿0.01的可能性不可用。除了这些服务商崩溃，还有可能网络崩溃，比如电缆被人挖断。