本文转载自https://blog.csdn.net/ggjlvzjy/article/details/46725115
https://blog.csdn.net/ichsonx/article/details/39008519
介绍
Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。简单的说，dubbo就是个服务框架，如果没有分布式的需求，其实是不需要用的，只有在分布式的时候，才有dubbo这样的分布式服务框架的需求。
上图是传统方式的，假如我有四台服务器，每台服务器都提供相同的服务，如果我消费者去掉用的时候，肯定要在四个当中选择某一个去调用，可是选择哪一个就是一个难题，当然这就涉及到负载均衡问题
我们在消费者和服务提供者之间加了一层服务路由。服务路由提供F5功能同时还提供代理服务的地址，代理地址是稳定的，这样就算服务提供者地址改变了，消费者直接调用代理服务器地址给 服务器路由，让服务器路由自己去查询，减小开销
最终方案
我们利用zookeeper生成的节点树，服务器提供者在启动的时候，将提供的服务名称和地址以节点的方式注册都服务器zookeeper服务器配置中心，消费者通过服务器配置中心获取需要的服务名称节点下的服务地址。
消费者只有在启动时，向注册中心订阅自己所需的服务。然后把服务提供者地址缓存到本地，随后每次调用时，按照本地缓存的地址进行调用，直到服务器地址列表有变化（机器下线或者上线），变更触发消费者watcher（主动通知的意思）进行服务地址的重新查询。正是因Dubbo无中心化（不强依赖注册中心）的结构，使得服务消费者在服务信息没变更时候，几乎不依赖配置中心，解决了负载均衡设备导致的单点故障的问题，大大降低了服务配置中心的压力。
dubbo的架构
Dubbo是阿里巴巴SOA服务化治理方案的核心框架，是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。
dubbo架构图如下所示：
节点角色说明：
Provider: 暴露服务的服务提供方。
Consumer: 调用远程服务的服务消费方。
Registry: 服务注册与发现的注册中心。
Monitor: 统计服务的调用次调和调用时间的监控中心。
Container: 服务运行容器。
调用关系说明：
- 服务容器负责启动，加载，运行服务提供者。
- 服务提供者在启动时，向注册中心注册自己提供的服务。
- 服务消费者在启动时，向注册中心订阅自己所需的服务。
- 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
- 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
- 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心
服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外，注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表注册中心和监控中心都是可选的，服务消费者可以直连服务提供者。
连通性：
- 注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小
- 监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示
- 服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销
- 服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，同时汇报调用时间到监控中心，此时间包含网络开销
- 注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外
- 注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者
- 注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表
- 注册中心和监控中心都是可选的，服务消费者可以直连服务提供者
dubbo健壮性
（1）监控中心宕掉不影响使用，只是丢失部分采样数据
（2）数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务
（3）注册中心对等集群，任意一台宕掉后，将自动切换到另一台
（4）注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯
（5）服务提供者无状态，任意一台宕掉后，不影响使用
（6）服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复
dubbo伸缩性
（1）注册中心为对等集群，可动态增加机器部署实例，所有客户端将自动发现新的注册中心
（2）服务提供者无状态，可动态增加机器部署实例，注册中心将推送新的服务提供者信息给消费者
Dubbo的负载均衡策略
在集群负载均衡时，Dubbo 提供了多种均衡策略，缺省为 random 随机调用。
负载均衡策略有：
- Random LoadBalance——随机，按权重设置随机概率。
在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。
- RoundRobin LoadBalance——轮循，按公约后的权重设置轮循比率。
存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。
- LeastActive LoadBalance——最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。
使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。
- ConsistentHash LoadBalance——一致性 Hash，相同参数的请求总是发到同一提供者。
当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。
Dubbo在安全机制方面是如何解决的
Dubbo通过Token令牌防止用户绕过注册中心直连，然后在注册中心上管理授权。Dubbo还提供服务黑白名单，来控制服务所允许的调用方。
Dubbo中zookeeper做注册中心，如果注册中心集群都挂掉，发布者和订阅者之间还能通信么？
可以的，启动dubbo时，消费者会从zk拉取注册的生产者的地址接口等数据，缓存在本地。每次调用时，按照本地存储的地址进行调用 。
zookeeper是如何保证事务的顺序一致性的
zookeeper采用了递增的事务Id来标识，所有的proposal都在被提出的时候加上了zxid，zxid实际上是一个64位的数字，高32位是epoch用来标识leader是否发生改变，如果有新的leader产生出来，epoch会自增，低32位用来递增计数。当新产生proposal的时候，会依据数据库的两阶段过程，首先会向其他的server发出事务执行请求，如果超过半数的机器都能执行并且能够成功，那么就会开始执行