Dubbo原理分析
角色区分:
- Provider: 暴露服务的服务提供方（生产者）。
- Consumer: 调用远程服务的服务消费方（消费者）。
- Registry: 服务注册与发现的注册中心。
- Monitor: 统计服务的调用次数和调用时间的监控中心。
调用流程:
- 服务容器负责启动，加载，运行服务提供者。
- 服务提供者在启动时，向注册中心注册自己提供的服务。
- 服务消费者在启动时，向注册中心订阅自己所需的服务。
- 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
- 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
- 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。
通俗易懂的话总结：
- 提供者把自己的完整类路径注册到Zookeeper注册中心。
- Zookeeper会推送变更信息给消费者，消费者会更新内容提供者服务列表到JVM。
- 消费者远程调用提供者，使用Dubbo协议（其实就是Netty的封装），注意SpringCloud的RPC调用提供者使用的是HTTP协议。
Zookeeper注册中心上，创建一个持久节点为service,在service持久节点下面创建多个不同的临时节点存放服务列表信息，临时节点内容存放服务调用地址。客 户 端从Zookeeper节点上获取最新service持久节点下面服务节点信息，让后在本地使用负载均衡算法，随机分配调用远程服务。客户端采用事件监听service持久节下面节点是否发生变化，如果发生变化Zookeeper服务器端会及时的将最新的数据推送给Zookeeper客户端。
RPC框架中负载均衡设计
在RPC远程调用框架中负载均衡大多数都采用本地负载均衡器，比SpringCloud中Ribbon组件直接从注册中心上获取服务列表信息，让后在本地实现RPC远程调用，同样的到底Dubbo框架中的负载均衡也是采用本地负载均衡器。
也许会有疑问，为什么不引入Nginx作为SpringCloud和Dubbo负载均衡中间件呢?
- 如果引入Nginx，是否考虑过Nginx要出所有的请求，压力是否会很大？为什么不平分到每个消费者？
- Dubbo消费者使用过Dubbo协议去通信的，Nginx是不支持Dubbo协议的。
- 。。。。。。
其实结论很明确了：如果使用RPC框架，一般是不会使用Nginx实现负载均衡的，而是使用RPC框架的本地负载均衡，如SpringCloud使用Ribbon。
说到负载均衡，会提到软负载和硬负载：
软负载:
- 软件负载均衡通过服务器端上安装的负载均软件或者使用本地负载算法实现负载均衡功能，例如:LVS、 Nginx 、 Haproxy。
硬负载:
- F5负载均衡是硬件负载均衡的一种。硬件负载均衡，顾名思义，在服务器节点之间安装专门的硬件进行负载均衡的工作。
