你好，我是何小锋。上一讲我们讲了“异常重试”，总结来说，异常重试就是为了尽最大可能保证接口可用率的一种手段，但这种策略只能用在幂等接口上，否则就会因为重试导致应用系统数据“写花”。

接着昨天的内容，今天我们再来聊聊 RPC 中的关闭流程。

关闭为什么有问题？

我们知道，在“单体应用”复杂到一定程度后，我们一般会进行系统拆分，也就是时下流行的微服务架构。服务拆分之后，自然就需要协同，于是 RPC 框架就出来了，它用来解决各个子系统之间的通信问题。

我再倒回来问你一个非常基础的问题？你觉得系统为啥非要拆分呢？从我的角度，如果只说一个原因，我觉得拆分之后我们可以更方便、更快速地迭代业务。那么问题来了，更快速地迭代业务，说人话不就是我会经常更新应用系统，时不时还老要重启服务器吗？

那具体到我们的 RPC 体系里，你就要考虑，在重启服务的过程中，RPC 怎么做到让调用方系统不出问题呢？

要想说明白这事，我们先要简述下上线的大概流程：当服务提供方要上线的时候，一般是通过部署系统完成实例重启。在这个过程中，服务提供方的团队并不会事先告诉调用方他们需要操作哪些机器，从而让调用方去事先切走流量。而对调用方来说，它也无法预测到服务提供方要对哪些机器重启上线，因此负载均衡就有可能把要正在重启的机器选出来，这样就会导致把请求发送到正在重启中的机器里面，从而导致调用方不能拿到正确的响应结果。