RPC 开发系列八：优雅关闭

一、关闭问题

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

         拆分之后可以更方便、更快速地迭代业务。那么问题来了，更快速地迭代业务，就是经常更新应用系统，时不时还老要重启服务器。

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

        在服务重启的时候，对于调用方来说，这时候可能会存在以下几种情况：

1. 调用方发请求前，目标服务已经下线。对于调用方来说，跟目标节点的连接会断开，这时候调用方可以立马感知到，并且在其健康列表里面会把这个节点挪掉，自然也就不会被负载均衡选中。
2. 调用方发请求的时候，目标服务正在关闭，但调用方并不知道它正在关闭，而且两者之间的连接也没断开，所以这个节点还会存在健康列表里面，因此该节点就有一定概率会被负载均衡选中。

二、关闭流程