为什么要java有注册中心_为什么推荐Zookeeper作注册中心

Zookeeper的数据模型很简单，有一系列被称为ZNode的数据节点组成，与传统的磁盘文件系统不同的是，zk将全量数据存储在内存中，可谓是高性能，而且支持集群，可谓高可用，另外支持事件监听。这些特点决定了zk特别适合作为注册中心(数据发布/订阅)。

Zookeeper注册中心

(+) (#)

建议使用dubbo-2.3.3以上版本的zookeeper注册中心客户端

Zookeeper说明

Zookeeper是Apacahe Hadoop的子项目，是一个树型的目录服务，支持变更推送，适合作为Dubbo服务的注册中心，工业强度较高，可用于生产环境，并推荐使用，参见：http://zookeeper.apache.org

Zookeeper安装

安装方式参见: Zookeeper安装手册，只需搭一个原生的Zookeeper服务器，并将Quick Start中Provider和Consumer里的conf/dubbo.properties中的dubbo.registry.addrss的值改为zookeeper://127.0.0.1:2181即可使用

可靠性声明

阿里内部并没有采用Zookeeper做为注册中心，而是使用自己实现的基于数据库的注册中心，即：Zookeeper注册中心并没有在阿里内部长时间运行的可靠性保障，此Zookeeper桥接实现只为开源版本提供，其可靠性依赖于Zookeeper本身的可靠性。

兼容性声明

因2.0.8最初设计的zookeeper存储结构不能扩充不同类型的数据，2.0.9版本做了调整，所以不兼容，需全部改用2.0.9版本才行，以后的版本会保持兼容2.0.9。

2.2.0版本改为基于zkclient实现，需增加zkclient的依赖包，2.3.0版本增加了基于curator的实现，作为可选实现策略。

流程说明：

服务提供者启动时

向/dubbo/com.foo.BarService/providers目录下写入自己的URL地址。

服务消费者启动时

订阅/dubbo/com.foo.BarService/providers目录下的提供者URL地址。

并向/dubbo/com.foo.BarService/consumers目录下写入自己的URL地址。

监控中心启动时

订阅/dubbo/com.foo.BarService目录下的所有提供者和消费者URL地址。

支持以下功能：

当提供者出现断电等异常停机时，注册中心能自动删除提供者信息。(临时节点？会话失效，自动删除)

当注册中心重启时，能自动恢复注册数据，以及订阅请求。

当会话过期时，能自动恢复注册数据，以及订阅请求。

当设置时，记录失败注册和订阅请求，后台定时重试。

可通过设置zookeeper登录信息。

可通过设置zookeeper的根节点，不设置将使用无根树。

支持*号通配符，可订阅服务的所有分组和所有版本的提供者。

在provider和consumer中增加zookeeper客户端jar包依赖：

支持zkclient和curator两种Zookeeper客户端实现：

ZKClient Zookeeper Registry

从2.2.0版本开始缺省为zkclient实现，以提升zookeeper客户端的健状性。

ZKClient是Datameer开源的一个Zookeeper客户端实现，开源比较早，参见：https://github.com/sgroschupf/zkclient

缺省配置：

或：

或：

需依赖：

Curator Zookeeper Registry

从2.3.0版本开始支持可选curator实现。

Curator是Netflix开源的一个Zookeeper客户端实现，比较活跃，参见：https://github.com/Netflix/curator

如果需要改为curator实现，请配置：

或：

或：

需依赖：

Zookeeper单机配置:

Or:

Zookeeper集群配置:

Or:

同一Zookeeper，分成多组注册中心:

Redis注册中心

(+) (#)

Redis说明

Redis是一个高效的KV存储服务器，参见：http://redis.io

Redis安装

安装方式参见: Redis安装手册，只需搭一个原生的Redis服务器，并将Quick Start中Provider和Consumer里的conf/dubbo.properties中的dubbo.registry.addrss的值改为redis://127.0.0.1:6379即可使用

Redis过期数据

通过心跳的方式检测脏数据，服务器时间必须相同，并且对服务器有一定压力。

可靠性声明

阿里内部并没有采用Redis做为注册中心，而是使用自己实现的基于数据库的注册中心，即：Redis注册中心并没有在阿里内部长时间运行的可靠性保障，此Redis桥接实现只为开源版本提供，其可靠性依赖于Redis本身的可靠性。

从2.1.0版本开始支持

数据结构：

使用Redis的Key/Map结构存储数据。

主Key为服务名和类型。

Map中的Key为URL地址。

Map中的Value为过期时间，用于判断脏数据，脏数据由监控中心删除。(注意：服务器时间必需同步，否则过期检测会不准确)

使用Redis的Publish/Subscribe事件通知数据变更。

通过事件的值区分事件类型：register, unregister, subscribe, unsubscribe。

普通消费者直接订阅指定服务提供者的Key，只会收到指定服务的register, unregister事件。

监控中心通过psubscribe功能订阅/dubbo/*，会收到所有服务的所有变更事件。

调用过程：

服务提供方启动时，向Key:/dubbo/com.foo.BarService/providers下，添加当前提供者的地址。

并向Channel:/dubbo/com.foo.BarService/providers发送register事件。

服务消费方启动时，从Channel:/dubbo/com.foo.BarService/providers订阅register和unregister事件。

并向Key:/dubbo/com.foo.BarService/providers下，添加当前消费者的地址。

服务消费方收到register和unregister事件后，从Key:/dubbo/com.foo.BarService/providers下获取提供者地址列表。

服务监控中心启动时，从Channel:/dubbo/*订阅register和unregister，以及subscribe和unsubsribe事件。

服务监控中心收到register和unregister事件后，从Key:/dubbo/com.foo.BarService/providers下获取提供者地址列表。

服务监控中心收到subscribe和unsubsribe事件后，从Key:/dubbo/com.foo.BarService/consumers下获取消费者地址列表。

选项：

可通过设置redis中key的前缀，缺省为dubbo。

可通过设置redis集群策略，缺省为failover。

failover: 只写入和读取任意一台，失败时重试另一台，需要服务器端自行配置数据同步。

replicate: 在客户端同时写入所有服务器，只读取单台，服务器端不需要同步，注册中心集群增大，性能压力也会更大。

Config redis registry:

Or:

Or:

Or:

Simple注册中心

(+) (#)

Dogfooding

注册中心本身就是一个普通的Dubbo服务，可以减少第三方依赖，使整体通讯方式一致。

适用性说明

此SimpleRegistryService只是简单实现，不支持集群，可作为自定义注册中心的参考，但不适合直接用于生产环境。

Export simple registry service:

Reference the simple registry service:

Or: