注册中心简介

首先在微服务的体系中，注册中心是其核心组件之一。Dubbo通过注册中心的方式实现了分布式环境中各个服务的注册与发现，同时还管理着各个服务之间调用关系，起到了各个服务之间的纽带作用。而它的主要作用有如下一些。

• 动态加入：服务提供者通过注册中心可以动态的将自己的服务暴露给其他的调用者，而不需要一个一个的去更新服务调用者的配置文件。
• 动态发现：与动态加入类似，服务消费者可以动态地感知配置的更新，路由的规划等等，而不需要等待服务重启之后才会生效。
• 动态调整：注册中心支持对于有些配置参数的动态调整，并且动态调整之后的参数可以动态自动更新到每个节点上。
• 统一配置：为了避免服务本身与配置中心的配置不一致的问题，通过心跳检测机制来实现统一配置效果。

Dubbo的注册中心代码在dobbo-registry 模块中，其中还包含了如下的五个子模块

其中可以看到Dubbo主要提供了四种注册中心的实现方式，分别对应Zookeeper、Redis、Simple、Multicast。

其中Zookeeper是官方比较推荐的一个注册中心，在生产环境中被广泛的使用。在阿里内部并没有以Redis作为注册中心使用，也就是说Redis作为服务注册中心并没有得到实践的检验。同样使用Redis 作为注册中心，其稳定性其实更多的在于Redis本身的性能。随着Redis的不断升级迭代，在不久的将来一定会有大面积的使用。

Dubbo有着很好的扩展性，如果现有的注册中心不能满足要求，那么开发者可以通过RegistryFactory 和Registry进行扩展。

工作流程

注册中心的总体流程还是比较简单的，Dubbo官网上也有比较详细的说明，总体的流程图如下。

1. 服务提供者启动的时候，会向服务注册中心写入自己的元数据信息，同时也会订阅配置的元数据信息。
2. 当服务消费者启动的时候，会向注册中心写入自己的元数据信息，同时订阅服务提供者、路由、配置元信息等等。
3. 服务管理中心启动的时候，会同时订阅所有消费者的信息、服务提供者的信息、路由信息、配置信息等等。
4. 当有服务提供者掉线或者是有新的服务提供者加入的时候，注册中心服务提供者的目录会发生变化，变化信息会动态通知到消费者、服务治理中等等。
5. 当消费者发起服务调用的时候，会异步将调用、统计信息等上报到控制中心。

数据结构

注册中心的总体设计是相同的，只是不同的注册中心有着不同的实现方式，既然实现方式不同，那么对应的数据结构也就是不一样的了。Zookeeper、Redis等注册中心都是实现了上面的流程，但是由于两者的数据结构不相同，所以实现方式也有所不同。

Zookeeper原理简述

Zookeeper是一种树形结构存储的注册中心，在Zookeeper中有四类节点，分别是持久节点、持久顺序节点、临时节点、临时顺序节点。

• 持久节点：服务注册之后，保证节点不会丢失，注册中心重启之后还会存在
• 持久顺序节点：在持久节点的特性上加上了顺序的特点。
• 临时节点：服务注册之后丢失或者Session超时的时候，注册的节点会被自动删除。
• 临时顺序节点：在临时节点的基础上增加了先后顺序能力

Dubbo在使用Zookeeper作为注册中心的时候，会创建持久节点和临时节点两种，对于创建节点的顺序其实没有太多的要求。

树结构关系

1. 树的根节点是注册中心分组，默认是/dubbo
2. 服务接口包括4个子类目，分别是provider、consumer、routers、configuration。
3. 服务提供者目录，包括了多个服务提供者的url元数据信息等等
4. 服务消费者目录，包括服务消费者的url元数据信息等等
5. 路由配置目录，包括了多个服务消费者的路由策略元数据信息等
6. 动态配置目录，包括用于服务提供者和服务消费者等的动态配置元数据信息。

Redis原理概述

Redis作为注册中心在实际的开发中并不是太常用，也是沿用了Dubbo抽象出来的Root、Service、Type、URL四层结构来进行存储，但是由于Redis是非关系型数据库，数据都是通过键值对的方式进行保存，也不能像是Zookeeper一样直接采用树状结构来存储，所以Redis采用了K/Map的形式来实现存储。Root、Service、Type组合形成Key，Redis的value是一个Map结构。Url作为Map的Key，超时时间作为Map的Value。