参考

http://dubbo.apache.org/zh-cn/docs/user/preface/architecture.html

角色

Dubbo有5个参与者：其中Monitor、Registry不是必须的

1. Provider 暴露服务的服务提供方
2. Consumer 调用远程服务的服务消费方（负载均衡）
3. Registry 服务注册与发现的注册中心（监控、心跳、踢出、重入）
4. Monitor 服务消费者和提供者在内存中累计调用次数和调用时间，主动定时每分钟发送一次统计数据到监控中心。
5. Container 服务运行容器：远程调用、序列化

Provider

1. Dubbo不像RocketMQ，并没有堆积的功能，但是Dubbo的Provider有一个 fixed Cache的线程池来缓存请求

注册中心

1. Dubbo注册中心仅仅只负责Provider的注册、Consumer的订阅、以及心跳和通知。这和Rocketmq的nameServer不同，nameServer除了扮演注册中心，还扮演路由器的功能。
2. 注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外
3. 注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表
4. 注册中心和监控中心都是可选的，服务消费者可以直连服务提供者

注册中心实现原理

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实现，实现方式不一样

1. Zookeeper实现注册中心

   
   image

• 所有的Consumer监测 /dubbo/$service/providers 节点，获取到所有的Providers的信息，并且Watch 该结点的变动，如果新加入Provider或者某个Provider宕机，会触发事件。
• 所有的Consumer自己也要注册在 /dubbo/service，获得提供者和消费者 URL 地址。

2. Redis实现注册中心

   
   image
   

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

• 通过事件的值区分事件类型：register, unregister, subscribe, unsubscribe
• 普通消费者直接订阅指定服务提供者的 Key，只会收到指定服务的 register, unregister 事件
• 监控中心通过 psubscribe 功能订阅 /dubbo/*，会收到所有服务的所有变更事件

Dubbo不依赖注册中心的配置

Dubbo绕开注册中心，直接使用Dubbo
Provider配置

    <dubbo:application name="hello-world-app-provider" />
    <dubbo:registry address="N/A"/>
    <dubbo:protocol name="dubbo" port="20880"/>     
    <dubbo:service interface="com.mor.server.dubbo.service.DemoServer" ref="demoService"  loadbalance="consistenthash"/>
    <bean id="demoService" class="com.mor.server.dubbo.service.DemoServerImpl"  />

Consumer配置,去除掉zk，但是要配置url

    <dubbo:application name="consumer-of-helloworld-app" />
    <dubbo:reference  id="demoService"  interface="com.mor.server.dubbo.service.DemoServer" url="dubbo://127.0.0.1:20880">
        <dubbo:method name="sayHello" loadbalance="consistenthash"/>
    </dubbo:reference>