一.背景
我们经常聊到dubbo的启动,是如何暴露接口的,如何注册到注册中心的,但是就一个完整的生命周期而言,有上线就必然有下线,而下线这一部分往往被人忽略,这次就一次线上发布问题为入口,来分析dubbo下线的过程和其中遇到的问题,从另一个方面加深dubbo整个生命周期的理解。
二.案例
某次生产发布,虽是对外停机发布,一般内部来讲,仍采用的是蓝绿发布,即先新起服务,等新的服务健康检查通过后,在杀掉原来的服务进程。开始正常,新服务健康起来,旧的容器(公司使用的是docker封装的服务)被杀掉,测试同学开始验证,然后问题来了,新的服务接口时不时出现超时,平均每三次出现俩次,这个不像是网络或者环境抖动,一开始检查业务是不是有慢查询,但是发现出问题的接口没有更新,属于原来的回归,开始还比较慌,有点摸不着头脑,后来慢慢把视线转到超时日志上,超时日志打印出来超时的provider的地址,这个地址不是新发布的服务端地址!!
不是新服务的地址,是哪的呢? 赶紧打开ZK的控制台,发现这个服务的provider的有两个,新发布的服务只是其中一个,如下图所示:
这个服务因为不是核心业务,目前是单例的,为什么会有两个provider,那另一个是从哪来的?
找了一通,然后我们在被杀死的容器里面找到了这个地址
这不是被杀死的服务吗,为什么还在ZK的列表里面? 是服务没下线,还是下线了ZK那里没有注销掉? 问题已经出来,然后我们来分析
三.分析
首先要确定到底是ZK没下线,还是服务本身就没下线(公司的容器调度平台是自研,也有出bug的可能),然后现场就联系的平台部的同事,反馈是容器确实本杀掉了,也就是进程已经不存在了,但是ZK上这个provider还存在。为什么?
1> dubbo的注册机制
要回答这个问题,我们先来看看dubbo的注册机制,在dubbo启动的时候,会进行provider的初始化,这里面包括暴露服务端口,注册服务,启动底层通信模块等一系列的动作,网上有很多资料可查,这里不在赘述,就注册服务这个环节进行分析
注册服务,即 将应用需要暴露的接口注册到注册中心(zookeeper或nacos),供消费者订阅以及控制台进行配置和管理,以ZK(zookeeper)为例,provider 注册到ZK上的节点