在介绍Dubbo的内部逻辑的时候提到很多次注册中心的概念.实现注册中心的有很多,主要是以下四个注册中心分别是:
Multicast注册中心
Zookeeper注册中心
Redis注册中心
Simple注册中心
这里将对注册中心的一个实现Zookeeper跟大家分享,因为Zookeeper是应用比较多,也是我们项目中实际用到的注册中心.
ZooKeeper 是一个为分布式应用所设计的分布的、开源的协调服务。分布式的应用可以建立在同步、配置管理、分组和命名等服务的更高级别的实现的基础之上。 ZooKeeper 意欲设计一个易于编程的环境，它的文件系统使用我们所熟悉的目录树结构。 ZooKeeper 使用 Java 所编写，但是支持 Java 和 C 两种编程语言。
协调服务是非常容易出错的， 同时也很难恢复正常，例如，协调服务很容易处于竞态以至于出现死锁。 ZooKeeper 的目的是为了减轻分布式应用程序所承担的协调任务。
ZooKeeper命名空间
提供的命名空间与标准的文件系统非常相似。一个名称是由通过斜线分隔开的路径名序列所组成的。ZooKeeper中的每一个节点是都通过路径来识别。
下图是Zookeeper中节点的数据模型，这种树形结构的命名空间操作方便且易于理解。
图:ZooKeeper层次命名空间
接着上图中,我们需要了解一下ZooKeeper中的节点和临时节点
ZooKeeper的节点是通过像树一样的结构来进行维护的，并且每一个节点通过路径来标示以及访问。除此之外，每一个节点还拥有自身的一些信息，包括：数据、数据长度、创建时间、修改时间等等。
从这样一类既含有数据，又作为路径表标示的节点的特点中，可以看出，ZooKeeper的节点既可以被看做是一个文件，又可以被看做是一个目录，它同时具有二者的特点。为了简单我们可以Znode来表示所讨论的ZooKeeper节点。
具体地说，Znode维护着数据、ACL（access controllist，访问控制列表）、时间戳等交换版本号等数据结构，它通过对这些数据的管理来让缓存生效并且令协调更新。每当Znode中的数据更新后它所维护的版本号将增加，这非常类似于数据库中计数器时间戳的操作方式。
另外Znode还具有原子性操作的特点：命名空间中，每一个Znode的数据将被原子地读写。读操作将读取与Znode相关的所有数据，写操作将替换掉所有的数据。除此之外，每一个节点都有一个访问控制列表，这个访问控制列表规定了用户操作的权限。
ZooKeeper中同样存在临时节点。这些节点与session同时存在，当session生命周期结束，这些临时节点也将被删除。临时节点在某些场合也发挥着非常重要的作用。
了解了Zookeeper的命名空间和节点之后我们需要跟上一篇文章中提到的内部逻辑联系起来.在上篇介绍到的内部流程中,拿到这里看看Zookeeper是如何处理的,流程如下图:
1 当服务提供者启动时,Zookeeper向/dubbo/com.foo.BarService/providers目录下写入自己的URL地址。
2 当服务消费者启动时,这时候有两个动作:
订阅/dubbo/com.foo.BarService/providers目录下的提供者URL地址。
并向/dubbo/com.foo.BarService/consumers目录下写入自己的URL地址。
3当监控中心启动时,订阅/dubbo/com.foo.BarService目录下的所有提供者和消费者URL地址。
以上内容算是对Zookeeper进行了一个入门级的了解,如果想深入对其了解的话可以参考一下文章:
官方文档
分布式服务框架 Zookeeper -- 管理分布式环境中的数据