参考
http://dubbo.apache.org/zh-cn/docs/user/preface/architecture.html
角色
Dubbo有5个参与者：其中Monitor、Registry不是必须的
Provider 暴露服务的服务提供方
Consumer 调用远程服务的服务消费方（负载均衡）
Registry 服务注册与发现的注册中心（监控、心跳、踢出、重入）
Monitor 服务消费者和提供者在内存中累计调用次数和调用时间，主动定时每分钟发送一次统计数据到监控中心。
Container 服务运行容器：远程调用、序列化
Provider
Dubbo不像RocketMQ，并没有堆积的功能，但是Dubbo的Provider有一个 fixed Cache的线程池来缓存请求
注册中心
Dubbo注册中心仅仅只负责Provider的注册、Consumer的订阅、以及心跳和通知。这和Rocketmq的nameServer不同，nameServer除了扮演注册中心，还扮演路由器的功能。
注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外
注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表
注册中心和监控中心都是可选的，服务消费者可以直连服务提供者
注册中心实现原理
http://dubbo.apache.org/zh-cn/docs/user/references/registry/zookeeper.html
http://dubbo.apache.org/zh-cn/docs/user/references/registry/redis.html
常见的zookeeper实现、Redis实现，实现方式不一样
Zookeeper实现注册中心
image
所有的Consumer监测 /dubbo/$service/providers 节点，获取到所有的Providers的信息，并且Watch 该结点的变动，如果新加入Provider或者某个Provider宕机，会触发事件。
所有的Consumer自己也要注册在 /dubbo/service，获得提供者和消费者 URL 地址。
Redis实现注册中心
image
使用 Redis 的 Publish/Subscribe 事件通知数据变更：
通过事件的值区分事件类型：register, unregister, subscribe, unsubscribe
普通消费者直接订阅指定服务提供者的 Key，只会收到指定服务的 register, unregister 事件
监控中心通过 psubscribe 功能订阅 /dubbo/*，会收到所有服务的所有变更事件
Dubbo不依赖注册中心的配置
Dubbo绕开注册中心，直接使用Dubbo
Provider配置
Consumer配置,去除掉zk，但是要配置url