一次线上问题引发的对dubbo优雅下线的思考

一.背景

       我们经常聊到dubbo的启动，是如何暴露接口的，如何注册到注册中心的，但是就一个完整的生命周期而言，有上线就必然有下线，而下线这一部分往往被人忽略，这次就一次线上发布问题为入口，来分析dubbo下线的过程和其中遇到的问题，从另一个方面加深dubbo整个生命周期的理解。

二.案例

       某次生产发布，虽是对外停机发布，一般内部来讲，仍采用的是蓝绿发布，即先新起服务，等新的服务健康检查通过后，在杀掉原来的服务进程。开始正常，新服务健康起来，旧的容器（公司使用的是docker封装的服务）被杀掉，测试同学开始验证，然后问题来了，新的服务接口时不时出现超时，平均每三次出现俩次，这个不像是网络或者环境抖动，一开始检查业务是不是有慢查询，但是发现出问题的接口没有更新，属于原来的回归，开始还比较慌，有点摸不着头脑，后来慢慢把视线转到超时日志上，超时日志打印出来超时的provider的地址，这个地址不是新发布的服务端地址！！

   不是新服务的地址，是哪的呢？ 赶紧打开ZK的控制台，发现这个服务的provider的有两个，新发布的服务只是其中一个，如下图所示：

这个服务因为不是核心业务，目前是单例的，为什么会有两个provider，那另一个是从哪来的？

找了一通，然后我们在被杀死的容器里面找到了这个地址

这不是被杀死的服务吗，为什么还在ZK的列表里面？ 是服务没下线，还是下线了ZK那里没有注销掉？ 问题已经出来，然后我们来分析

三.分析

       首先要确定到底是ZK没下线，还是服务本身就没下线（公司的容器调度平台是自研，也有出bug的可能），然后现场就联系的平台部的同事，反馈是容器确实本杀掉了，也就是进程已经不存在了，但是ZK上这个provider还存在。为什么？

    1> dubbo的注册机制

       要回答这个问题，我们先来看看dubbo的注册机制，在dubbo启动的时候，会进行provider的初始化，这里面包括暴露服务端口，注册服务，启动底层通信模块等一系列的动作，网上有很多资料可查，