简介：Dubbox是一个分布式服务框架，其前身是阿里巴巴开源项目Dubbo,后期阿里巴巴停止维护后，当当网在其基础上进行了优化，并继续维护，改名Dubbox。

一、 Dubbox的基本概念

• Dubbox是一种分布式服务架构，它除了提供服务之外，还可以实现软负载均衡。还提供了两个功能Monitor监控中心和调用中心。这两个是可选的，需要单独配置。

• Dubbox是一个远程服务调用的分布式框架,致力于提供高性能和透明化的RPC远程服务调用方案,以及SOA的服务治理

二、Dubbox的特性:

• 1.透明化远程方法调用:就像调用本地方法一样调用远程方法,只需要简单配置,没有任何API侵入

• 2.软负载均衡及容错机制,可在内网替代F5等硬件负载均衡器,降低成本,减少单点.

• 3.服务自动注册与发现,不需要写死服务提供方地址,注册中心基于接口名查询服务提供者的IP地址,并且能够平滑添加或删除服务提供者.

三、Dubbox原理

节点角色说明：

    Provider：暴露服务的服务提供方。Consumer：调用远程服务的服务消费方。Registry：服务注册与发现的注册中心。Monitor：统计服务的调用次调和调用时间的监控中心。Container： 服务运行容器。

调用关系说明：

    0. 服务容器负责启动，加载，运行服务提供者。1. 服务提供者在启动时，向注册中心注册自己提供的服务。2. 服务消费者在启动时，向注册中心订阅自己所需的服务。3. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。4. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。5. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

四、Dubbox支持的注册中心

Dubbo提供的注册中心有如下几种类型可供选择：

• Multicast注册中心

• Zookeeper注册中心

• Redis注册中心

• Simple注册中心

ZooKeeper是一个开源的分布式服务框架，它是Apache Hadoop项目的一个子项目，主要用来解决分布式应用场景中存在的一些问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置管理等，它支持Standalone模式和分布式模式，在分布式模式下，能够为分布式应用提供高性能和可靠地协调服务，而且使用ZooKeeper可以大大简化分布式协调服务的实现，为开发分布式应用极大地降低了成本。

zookeeper简介

• Zookeeper是一个高效的分布式协调服务，由雅虎创建，是 Google Chubby 的开源实现。 它暴露了一些公用服务，比如命名服务/配置管理/同步控制/群组服务等。我们可以使用ZK来实现比如达成共识/集群管理/leader选举等。 利用zookeeper的ZAB算法(原子消费广播协议)能够很好地保证分布式环境中数据的一致性，也正是基于这样的特性，使得Zookeeper成为了解决分布式一致性问题的利器

Zookeeper的数据模型

Zookeeper的数据模型是什么样子呢？它很像数据结构当中的树，也很像文件系统的目录。

树是由节点所组成，Zookeeper的数据存储也同样是基于节点，这种节点叫做Znode。
但是，不同于树的节点，Znode的引用方式是路径引用，类似于文件路径：
/ 动物 / 仓鼠
/ 植物 / 荷花
这样的层级结构，让每一个Znode节点拥有唯一的路径，就像命名空间一样对不同信息作出清晰的隔离。

---

Znode节点中包含以下数据：

• data：Znode存储的数据信息。
• ACL：记录Znode的访问权限，即哪些人或哪些IP可以访问本节点。
• stat：包含Znode的各种元数据，比如事务ID、版本号(version)、时间戳、大小等等。
• child：当前节点的子节点引用，类似于二叉树的左孩子右孩子。

这里需要注意一点，Zookeeper是为读多写少的场景所设计。Znode并不是用来存储大规模业务数据，而是用于存储少量的状态和配置信息，每个节点的数据最大不能超过1MB。

Zookeeper选举机制以及ZAB协议

Zookeeper架构中的角色

• leader：一个Zookeeper集群同一时间只会有一个实际工作的Leader，它会发起并维护与各Follwer及Observer间的心跳。所有的写操作必须要通过Leader完成再由Leader将写操作广播给其它服务器。
• Follower：一个Zookeeper集群可能同时存在多个Follower，它会响应Leader的心跳。Follower可直接处理并返回客户端的读请求，同时会将写请求转发给Leader处理，并且负责在Leader处理写请求时对请求进行投票。
• Observer：角色与Follower类似，但是无投票权。

• 原子广播（ZAB）

  为了保证写操作的一致性与可用性，Zookeeper专门设计了一种名为原子广播（ZAB）的支持崩溃恢复的一致性协议。基于该协议，Zookeeper实现了一种主从模式的系统架构来保持集群中各个副本之间的数据一致性。

  根据ZAB协议，所有的写操作都必须通过Leader完成，Leader写入本地日志后再复制到所有的Follower节点，Observer节点。

  一旦Leader节点无法工作，ZAB协议能够自动从Follower节点中重新选出一个合适的替代者，即新的Leader，该过程即为领导选举。该领导选举过程，是ZAB协议中最为重要和复杂的过程。

通过Leader进行写操作，主要分为五步：

1. 客户端向Leader发起写请求
2. Leader将写请求以(广播)Proposal的形式发给所有Follower并等待（回应）ACK
3. Follower收到Leader的Proposal后返回ACK
4. Leader得到过半数的ACK（Leader对自己默认有一个ACK）后向所有的Follower和Observer发送Commmit
5. Leader将处理结果返回给客户端

这里要注意

1. Leader并不需要得到Observer的ACK，即Observer无投票权
2. Leader不需要得到所有Follower的ACK，只要收到过半的ACK即可，同时Leader本身对自己有一个ACK。上图中有4个Follower，只需其中两个返回ACK即可，因为(2+1) / (4+1) > 1/2
3. Observer虽然无投票权，但仍须同步Leader的数据从而在处理读请求时可以返回尽可能新的数据
4. Follower/Observer均可接受写请求，但不能直接处理，而需要将写请求转发给Leader处理
5. 除了多了一步请求转发，其它流程与直接写Leader无任何区别

注意：Leader/Follower/Observer都可直接处理读请求，由于处理读请求不需要服务器之间的交互，Follower/Observer越多，整体可处理的读请求量越大，也即读性能越好。
ZooKeeper集群由一组Server节点组成，这一组Server节点中存在一个角色为Leader的节点，其他节点都为Follower。当客户端Client连接到ZooKeeper集群，并且执行写请求时，这些请求会被发送到Leader节点上，然后Leader节点上数据变更会同步到集群中其他的Follower节点。

五、Dubbo支持的远程通信协议

远程通信需要指定通信双方所约定的协议，在保证通信双方理解协议语义的基础上，还要保证高效、稳定的消息传输。Dubbo继承了当前主流的网络通信框架，主要包括如下几个：

• Mina
• Netty
• Grizzly

六、 Dubbo支持的远程调用协议

Dubbo支持多种协议，如下所示：

• Dubbo协议
• Hessian协议
• HTTP协议
• RMI协议
• WebService协议
• Thrift协议
• Memcached协议
• Redis协议

在通信过程中，不同的服务等级一般对应着不同的服务质量，那么选择合适的协议便是一件非常重要的事情。你可以根据你应用的创建来选择。例如，使用RMI协议，一般会受到防火墙的限制，所以对于外部与内部进行通信的场景，就不要使用RMI协议，而是基于HTTP协议或者Hessian协议。

七、Dubbo集群容错和负载均衡

1、集群容错

在集群调用失败时，Dubbo提供了多种容错方案，缺省为failover重试。

• Failover Cluster
  失败自动切换，当出现失败，重试其它服务器。(缺省)
  通常用于读操作，但重试会带来更长延迟。
  可通过retries=“2”来设置重试次数(不含第一次)。
• Failfast Cluster
  快速失败，只发起一次调用，失败立即报错。
  通常用于非幂等性的写操作，比如新增记录。
• Failsafe Cluster
  失败安全，出现异常时，直接忽略。
  通常用于写入审计日志等操作。
• Failback Cluster
  失败自动恢复，后台记录失败请求，定时重发。
  通常用于消息通知操作。
• Forking Cluster
  并行调用多个服务器，只要一个成功即返回。
  通常用于实时性要求较高的读操作，但需要浪费更多服务资源。
  可通过forks=“2”来设置最大并行数。
• Broadcast Cluster
  广播调用所有提供者，逐个调用，任意一台报错则报错。(2.1.0开始支持)
  通常用于通知所有提供者更新缓存或日志等本地资源信息。

2、负载均衡

• Random LoadBalance随机，按权重设置随机概率。
  在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。
• RoundRobin LoadBalance 轮循，按公约后的权重设置轮循比率。
  存在慢的提供者累积请求问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。
• LeastActive LoadBalance 最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。
  使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。
• ConsistentHash LoadBalance 一致性Hash，相同参数的请求总是发到同一提供者。
  当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。

注册中心挂掉了可以继续通信吗

可以，因为刚开始初始化的时候，消费者会将提供者的地址等信息拉取到本地缓存，所以注册中心挂了可以继续通信

Dubbo如何保证服务的安全

通过令牌验证在注册中心控制权限，可以在配置文件中决定要不要下发令牌给消费者，可以防止消费者绕过注册中心访问提供者，另外注册中心可以灵活改变授权方式，而不需修改或升级提供者