参考：http://dubbo.apache.org/zh-cn/docs/user/references/registry/introduction.html
multicast注册中心不需要启动任何中心节点，只要广播地址一样，就可以互相发现。
1. 提供方启动时广播自己的地址
2. 消费方启动时广播订阅请求
3. 提供方收到订阅请求时单播自己的地址给订阅者，如果设置了unicast=false，则广播给订阅者
4. 消费方收到提供方地址时，连接该地址进行RPC调用。
组播受网络结构限制，只适合小规模应用或开发阶段使用。
zookeeper是一个树型的目录服务，支持变更推送，适合作为Dubbo服务的注册中心，工业强度较高，可用于生产环境，并推荐使用。
1. 服务提供者启动时，向/duboo/com.foo.BarService/providers目录下写入自己的URL地址
2. 服务消费者启动时，订阅/dubbo/com.foo.BarService/providers目录下的提供者URL地址。并向/dubbo/com.foo.BarService/consumers 目录下写入自己的URL地址
3. 监控中心启动：订阅/dubbo/com.foo.BarService目录下的所有提供者和消费者的URL地址
支持以下功能：
当提供者出现断电灯异常停机时，注册中心能自动删除提供者信息
当注册中心重启时，能自动回复注册数据，以及订阅请求
当会话过期时，能自动回复注册数据，以及订阅请求
当设置<dubbo:registry check="false" />时，记录失败注册和订阅请求，后台定时重试
可通过<dubbo:registry username="admin" password="1234" /> 设置zookeeper登录信息
可通过<dubbo:registry group="dubbo" />设置zookeeper的根节点，不设置将使用无根树
支持*通配符<dubbo:reference group="*" version="*" />，可订阅服务的所有分组和所有版本的提供者
Redis注册中心
使用Redis的Key/Map结构存储数据结构：
- 主Key为服务名和类型
- Map中的Key为URL地址
- Map中的value为过期时间，用于判断脏数据，脏数据由监控中心删除
使用Redis的Publish/Subscribe事件通知数据变更：
- 通过事件的值区分事件类型：register,unregister,subscribe,unsubscribe
- 普通消费者直接订阅指定服务提供者的Key，只会收到指定服务的register，unregister事件
- 监控中心通过psubscribe功能订阅/dubbo/*，会收到所有服务的所有变更事件
调用过程：
1. 服务提供方启动时，向Key:/dubbo/com.foo.BarService/providers下，添加当前提供者的地址
2. 并向Channel:/dubbo/com.foo.BarService/providers发送register
3. 服务消费方启动时，从Channel:/dubbo/com.foo.BarService/rpoviders订阅register和unregister事件
4. 并向Key:/dubbo/com.foo.BarService/providers下添加当前消费者的地址
5. 服务消费方收到register和unregister事件后，从Key:/dubbo/com.foo.BarService/providers下获取提供者地址列表
6. 服务监控中心启动时，从Channel:/dubbo/*订阅register和unregister，以及subscribe和unsubscribe事件
7. 服务监控中心收到register和unregister事件后，从key:/dubbo/com/foo.BarService/providers下获取提供者地址列表
8. 服务监控中心收到register和unregister事件后，从key:/dubbo/com/foo.BarService/consumers下获取提供者地址列表
Simple注册中心
Simple注册中心本身就是一个普通的Dubbo服务，可以减少第三方依赖，使整体通讯方式一致。
