Dubbo-注册中心

前言

本文对 Dubbo 注册中心的工作流程等进行介绍，主要关注下面3个问题。

1. 注册中心的工作流程；
2. Zookeeper；
3. Dubbo 注册中心的缓存机制；

注册中心的工作流程

注册中心对于 Dubbo 而言，是对服务提供者和服务消费者的整体把控，最后的服务调用是直接发生在消费者和提供者之间的，但是如何找到提供者，如果能动性更强的选择服务，都是需要注册中心实现的。总的而言，注册中心具备以下几个能力：动态注册、动态发现、动态调整、统一管理。

Dubbo 中实现的注册中心有：zookeeper、redis、内存、广播。我们一般的分析也就基于 zk 就可以了。

上图是 Dubbo 中注册中心相关的的使用过程。我们以 Dubbo 默认的注册中心 zk 为例，具体介绍下其使用流程：

1. provider 启动时向注册中心注册自己的元数据信息，并订阅配置(configurators)节点，并和 zk 建立长连接；
2. consumer 启动时向注册中心注册自己的元数据信息，并订阅配置(configurators)、路由(routers)、服务提供者(providers)节点，并和 zk 建立长连接；
3. 服务治理中心启动时会订阅注册中心所有节点的信息，包括配置、服务提供者、服务消费者、路由节点。

zookeeper

zk 的节点有4种类型：持久节点、持久顺序节点、临时节点、临时顺序节点。在 Dubbo 中使用的只有持久节点和临时节点。

• 持久节点。节点创建之后只会在删除命令之后被删除；
• 临时节点。节点会随着会话消失被删除。

上文说到 服务提供者/消费者启动之后会创建节点，并且注册服务的元数据，下图1就是创建的节点，2就是元数据示例。

发布

发布就是服务提供者/消费者在启动之后，把自己的元数据信息注册到zk节点上，发布很简单，就是在zk上创建节点。

订阅

提供者订阅配置(configurators)节点；消费者订阅配置(configurators)、路由(routers)、提供者(providers)节点。

他们会在第一次注册到 zk 的时候把对应订阅的目录的数据全部拉(pull)过来，并注册 watcher 监听节点变化，建立长连接；当节点发生变化时，zk 首先会主动通知对应的客户端，然后客户端在全量拉一次节点数据。

Dubbo 注册中心的缓存机制

Dubbo 注册中心的缓存机制可以不用每次服务调用都去访问注册中心，获取可调用的服务列表，这样注册中心压力太大了，所以消费者会在获取到注册中心节点信息之后，在内存和本地文件缓存一份。