Dubbo :是一个RPC框架，SOA框架：

Dubbo缺省协议采用单一长连接和NIO异步通讯，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。
作为RPC：支持各种传输协议，如dubbo,hession,json,fastjson，底层采用mina,netty长连接进行传输！典型的provider和cusomer模式
作为SOA：具有服务治理功能，提供服务的注册和发现，用zookeeper实现注册中心，启动时候服务端会把所有接口注册到注册中心，并且订阅configurators,服务消费端订阅provide，configurators,routers,订阅变更时，zk会推送providers,configuators，routers,启动时注册长连接，进行通讯！proveider和provider启动后，后台启动定时器，发送统计数据到monitor（监控中心），提供各种容错机制和负载均衡策略。

Consumer：服务消费者，Provider：服务提供者。Container服务容器。消费当然是invoke提供者了，invoke这条实线按照图上的说明当然同步的意思了，多说一句，在实际调用过程中，Provider的位置对于Consumer来说是透明的，上一次调用服务的位置（IP地址）和下一次调用服务的位置，是不确定的。这个地方就是实现了软负载。

服务提供者先启动start，然后注册register服务。

消费订阅subscribe服务，如果没有订阅到自己想获得的服务，它会不断的尝试订阅。新的服务注册到注册中心以后，注册中心会将这些服务通过notify到消费者。

Monitor这是一个监控，图中虚线表明Consumer 和Provider通过异步的方式发送消息至Monitor，Consumer和Provider会将信息存放在本地磁盘，平均1min会发送一次信息。Monitor在整个架构中是可选的（图中的虚线并不是可选的意思），Monitor功能需要单独配置，不配置或者配置以后，Monitor挂掉并不会影响服务的调用。
关于netty框架可以看我的这篇文章netty 线程模型

dubbo原理

I、初始化过程细节：
上图中的第一步start，就是将服务装载容器中，然后准备注册服务。和Spring中启动过程类似，spring启动时，将bean装载进容器中的时候，首先要解析bean。所以dubbo也是先读配置文件解析服务。
解析服务：
1）、基于dubbo.jar内的Meta-inf/spring.handlers配置，spring在遇到dubbo名称空间时，会回调DubboNamespaceHandler类。
2）、所有的dubbo标签，都统一用DubboBeanDefinitionParser进行解析，基于一对一属性映射，将XML标签解析为Bean对象。
在ServiceConfig.export 或者ReferenceConfig.get 初始化时，将Bean对象转会为url格式，将Bean属性转成url的参数。
然后将URL传给Protocol扩展点，基于扩展点的Adaptive机制，根据URL的协议头，进行不同协议的服务暴露和引用。

a、 只暴露服务端口（本地暴露）

在没有使用注册中心的情况，这种情况一般适用在开发环境下，服务的调用这和提供在同一个IP上，只需要打开服务的端口即可。
即，当配置 or
ServiceConfig解析出的URL的格式为：
Dubbo：//service-host/com.xxx.TxxService?version=1.0.0
基于扩展点的Adaptiver机制，通过URL的“dubbo：//”协议头识别，直接调用DubboProtocol的export（）方法，打开服务端口。

b、向注册中心暴露服务：（远程暴露）

和上一种的区别：需要将服务的IP和端口一同暴露给注册中心。
ServiceConfig解析出的url格式为：
registry://registry-host/com.alibaba.dubbo.registry.RegistryService?export=URL.encode(“dubbo://service-host/com.xxx.TxxService?version=1.0.0”)

基于扩展点的Adaptive机制，通过URL的“registry：//”协议头识别，调用RegistryProtocol的export方法，将export参数中的提供者URL先注册到注册中心，再重新传给Protocol扩展点进行暴露： Dubbo：//service-host/com.xxx.TxxService?version=1.0.0

服务暴露和消费的详细过程

1、服务提供者暴露服务的主过程：

一个服务发布暴露首先由spring的spacehander 把相关的xml或者注解全部转化为springBean,之后通过ServiceConfig.exerp()方法把bean传化为传输所需的url和参数注册到注册中心，发布后provder端的ref(helloImpl)通过protocl(传输协议，如dubboprotocl,hessionprotocl)转化为Invoker对象，即调用信息，包括类，方法，参数等等，再通过proxy操作（代理）如jdkproxy代理转为为Exporter对象

Dubbo处理服务暴露的关键就在Invoker转换到Exporter的过程(如上图中的红色部分)，下面我们以Dubbo和RMI这两种典型协议的实现来进行说明：

Dubbo的实现：

Dubbo协议的Invoker转为Exporter发生在DubboProtocol类的export方法，它主要是打开socket侦听服务，并接收客户端发来的各种请求，通讯细节由Dubbo自己实现。

RMI的实现：

RMI协议的Invoker转为Exporter发生在RmiProtocol类的export方法，
它通过Spring或Dubbo或JDK来实现RMI服务，通讯细节这一块由JDK底层来实现，这就省了不少工作量。

2、服务消费者消费一个服务的详细过程

一个Renfence类，通过RenfenceConfig的init 调用proxy的refer方法生产一个invoker,invoker再通过proctol转化成具体的ref(hello),进行消费
首先 ReferenceConfig 类的 init 方法调用 Protocol 的 refer 方法生成 Invoker 实例(如上图中的红色部分)，这是服务消费的关键。接下来把 Invoker 转换为客户端需要的接口(如：HelloWorld)

dubbo容错机制

1、Failover Cluster

这是Dubbo中默认的容错机制，这种方式比较常用。这种方式可以进行失败自动切换，当出现失败，重试其它服务器。通常用于读操作，但重试会带来更长延迟。可通过retries="2"来设置重试次数(不含第一次)。

 <dubbo:service retries="2" />
  或：
 <dubbo:reference retries="2" />
    或：
 <dubbo:reference>
         <dubbo:method name="findFoo" retries="2" />
  </dubbo:reference>

2、Failfast Cluster（常用）

这种是 快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。

<dubbo:service cluster="failfast" />
          或：
<dubbo:reference cluster="failfast" />

3、Failsafe Cluster
失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。

  <dubbo:service cluster="failsafe" />
          或：
 <dubbo:reference cluster="failsafe" />

4、Failback Cluster
失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。

<dubbo:service cluster="failback" />
          或：
<dubbo:reference cluster="failback" />

5、Forking Cluster
并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过forks="2"来设置最大并行数。

<dubbo:service cluster=“forking" />
          或：
 <dubbo:reference cluster=“forking" />

dubbo负载策略

Dubbo中提供了4中负载的策略

1、Random LoadBalance
随机，按权重设置随机概率。
在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重

2、RoundRobin LoadBalance
轮循，按公约后的权重设置轮循比率。
存在慢的提供者累积请求问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。
解决办法 :结合权重，把第二台机(性能低的)的权重设置低一点

3、LeastActive LoadBalance
最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。
使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。

4、ConsistentHash LoadBalance
一致性Hash，相同参数的请求总是发到同一提供者。
当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。

dubbo的服务降级

降级的目的是为了保证核心服务可用

降级可以有几个层面的分类：自动降级，人工降级；按照功能可以分为：读服务降级和写服务降级；

1.对一些非核心服务进行人工降级，在大促之前通过降级开关关闭那些推荐内容，评价等对主流程序没有影响的功能

2.故障降级，比如调用的远程服务挂了，网络故障，或者RPC服务返回异常。那么可以直接降级，降级的方案比如设置默认值，采用兜底数据（系统推荐的行为广告挂了，可以提前准备静态页面做返回）等等

3.限流降级，在秒杀这种流量比较集中并且流量特别大的情况下，因为突发访问量特别大可能导致系统支撑不了。这个时候可以采用限流来限制访问量。当达到阈值时，后续的请求被降级，比如进入排队页面，比如跳转到错误页面（活动火爆，请稍后重试）

Dubbo的降级方式：Mock

实现步骤

1.在client端创建一个testmock类，实现对应的IGphello的接口（需要对哪个接口进行mock，就实现哪个）名称必须以mock结尾

2.在client端的xml配置文件中，添加如下配置，增加一个mock属性指向创建的testmock

3.模拟错误（设置timeout）模拟超时异常，运行测试代码即可访问到testmock这个类，当服务端故障解除以后，调用过程将恢复正常

dubbo和zookeeper

Dubbo的将注册中心进行抽象，使得它可以外接不同的存储媒介给注册中心提供服务，有ZooKeeper，Memcached，Redis等。
引入了ZooKeeper作为存储媒介，也就把ZooKeeper的特性引进来。首先是负载均衡，单注册中心的承载能力是有限的，在流量达到一定程度的时 候就需要分流，负载均衡就是为了分流而存在的，一个ZooKeeper群配合相应的Web应用就可以很容易达到负载均衡；资源同步，单单有负载均衡还不 够，节点之间的数据和资源需要同步，ZooKeeper集群就天然具备有这样的功能；命名服务，将树状结构用于维护全局的服务地址列表，服务提供者在启动 的时候，向ZK上的指定节点/dubbo/${serviceName}/providers目录下写入自己的URL地址，这个操作就完成了服务的发布。 其他特性还有Mast选举，分布式锁等。

· Provider: 暴露服务的服务提供方。

· Consumer: 调用远程服务的服务消费方。

· Registry: 服务注册与发现的注册中心。（ZooKeeper）

· Monitor: 统计服务的调用次调和调用时间的监控中心。

· Container: 服务运行容器。

Zookeeper 最早起源于雅虎研究院的一个研究小组。在当时，研究人员发现，在雅虎内部很多大型系统基本都需要依赖一个类似的系统来进行分布式协调，但是这些系统往往都存在分布式单点问题。

所以，雅虎的开发人员就试图开发一个通用的无单点问题的分布式协调框架，以便让开发人员将精力集中在处理业务逻辑上。
ZooKeeper 的设计目标是将那些复杂且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一系列简单易用的接口提供给用户使用。

原语： 操作系统或计算机网络用语范畴。它是由若干条指令组成的，用于完成一定功能的一个过程。具有不可分割性，即原语的执行必须是连续的，在执行过程中不允许被中断。

ZooKeeper 是一个典型的分布式数据一致性解决方案，分布式应用程序可以基于 ZooKeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。

ZooKeeper 一个最常用的使用场景就是用于担任服务生产者和服务消费者的注册中心。

服务生产者将自己提供的服务注册到 ZooKeeper 中心，服务的消费者在进行服务调用的时候先到 ZooKeeper 中查找服务，获取到服务生产者的详细信息之后，再去调用服务生产者的内容与数据。

Dubbo 架构中 ZooKeeper 就担任了注册中心这一角色。

ZAB协议

ZAB协议是专门为zookeeper实现分布式协调功能而设计。zookeeper主要是根据ZAB协议是实现分布式系统数据一致性。
zookeeper根据ZAB协议建立了主备模型完成zookeeper集群中数据的同步。这里所说的主备系统架构模型是指，在zookeeper集群中，只有一台leader负责处理外部客户端的事物请求(或写操作)，然后leader服务器将客户端的写操作数据同步到所有的follower节点中。

ZAB的协议核心是在整个zookeeper集群中只有一个节点即Leader将客户端的写操作转化为事物(或提议proposal)。Leader节点再数据写完之后，将向所有的follower节点发送数据广播请求(或数据复制)，等待所有的follower节点反馈。在ZAB协议中，只要超过半数follower节点反馈OK，Leader节点就会向所有的follower服务器发送commit消息。即将leader节点上的数据同步到follower节点之上。

ZAB协议中主要有两种模式，第一是消息广播模式；第二是崩溃恢复模式
消息广播模式
1、在zookeeper集群中数据副本的传递策略就是采用消息广播模式。zookeeper中数据副本的同步方式与二阶段提交相似但是却又不同。二阶段提交的要求协调者必须等到所有的参与者全部反馈ACK确认消息后，再发送commit消息。要求所有的参与者要么全部成功要么全部失败。二阶段提交会产生严重阻塞问题。
2、ZAB协议中Leader等待follower的ACK反馈是指”只要半数以上的follower成功反馈即可，不需要收到全部follower反馈”
图中展示了消息广播的具体流程图

4、zookeeper中消息广播的具体步骤如下：
4.1. 客户端发起一个写操作请求
4.2. Leader服务器将客户端的request请求转化为事物proposql提案，同时为每个proposal分配一个全局唯一的ID，即ZXID。
4.3. leader服务器与每个follower之间都有一个队列，leader将消息发送到该队列
4.4. follower机器从队列中取出消息处理完(写入本地事物日志中)毕后，向leader服务器发送ACK确认。
4.5. leader服务器收到半数以上的follower的ACK后，即认为可以发送commit
4.6. leader向所有的follower服务器发送commit消息
4.7 不能正常反馈的follower节点就抛弃leader，然后进入数据同步阶段，和集群达成一致。
5、zookeeper采用ZAB协议的核心就是只要有一台服务器提交了proposal，就要确保所有的服务器最终都能正确提交proposal。这也是CAP/BASE最终实现一致性的一个体现。
6、leader服务器与每个follower之间都有一个单独的队列进行收发消息，使用队列消息可以做到异步解耦。leader和follower之间只要往队列中发送了消息即可。如果使用同步方式容易引起阻塞。性能上要下降很多。

崩溃恢复
1、zookeeper集群中为保证任何所有进程能够有序的顺序执行，只能是leader服务器接受写请求，即使是follower服务器接受到客户端的请求，也会转发到leader服务器进行处理。
2、如果leader服务器发生崩溃，则zab协议要求zookeeper集群进行崩溃恢复和leader服务器选举。
3、ZAB协议崩溃恢复要求满足如下2个要求：
3.1. 确保已经被leader提交的proposal必须最终被所有的follower服务器提交。
3.2. 确保丢弃已经被leader出的但是没有被提交的proposal。
4、根据上述要求，新选举出来的leader不能包含未提交的proposal，即新选举的leader必须都是已经提交了的proposal的follower服务器节点。同时，新选举的leader节点中含有最高的ZXID。这样做的好处就是可以避免了leader服务器检查proposal的提交和丢弃工作。
5、leader服务器发生崩溃时分为如下场景：
5.1. leader在提出proposal时未提交之前崩溃，则经过崩溃恢复之后，新选举的leader一定不能是刚才的leader。因为这个leader存在未提交的proposal。
5.2 leader在发送commit消息之后，崩溃。即消息已经发送到队列中。经过崩溃恢复之后，参与选举的follower服务器(刚才崩溃的leader有可能已经恢复运行，也属于follower节点范畴)中有的节点已经是消费了队列中所有的commit消息。即该follower节点将会被选举为最新的leader。剩下动作就是数据同步过程。

数据同步
1、在zookeeper集群中新的leader选举成功之后，leader会将自身的提交的最大proposal的事物ZXID发送给其他的follower节点。follower节点会根据leader的消息进行回退或者是数据同步操作。最终目的要保证集群中所有节点的数据副本保持一致。
2、数据同步完之后，zookeeper集群如何保证新选举的leader分配的ZXID是全局唯一呢？这个就要从ZXID的设计谈起。
2.1 ZXID是一个长度64位的数字，其中低32位是按照数字递增，即每次客户端发起一个proposal,低32位的数字简单加1。高32位是leader周期的epoch编号，每当选举出一个新的leader时，新的leader就从本地事物日志中取出ZXID,然后解析出高32位的epoch编号，进行加1，再将低32位的全部设置为0。这样就保证了每次新选举的leader后，保证了ZXID的唯一性而且是保证递增的。

数据结构
ZooKeeper数据模型的结构与Unix文件系统很类似，整体上可以看作是一棵树，每个节点称做一个ZNode。每个Znode可以类似看作是一个目录，其下可以创建子目录。

很显然zookeeper集群自身维护了一套数据结构。这个存储结构是一个树形结构，其上的每一个节点，我们称之为"znode"，每一个znode默认能够存储1MB的数据，每个ZNode都可以通过其路径唯一标识

znode 有两种维度来决定种类

1、是否临时（是否持久）：所谓持久节点是指一旦这个 ZNode 被创建了，除非主动进行 ZNode 的移除操作，否则这个 ZNode 将一直保存在 ZooKeeper 上。而临时节点就不一样了，它的生命周期和客户端会话绑定，一旦客户端会话失效，那么这个客户端创建的所有临时节点都会被移除。
2、是否顺序：ZooKeeper 还允许用户为每个节点添加一个特殊的属性：SEQUENTIAL。一旦节点被标记上这个属性，那么在这个节点被创建的时候，ZooKeeper 会自动在其节点名后面追加上一个整型数字，这个整型数字是一个由父节点维护的自增数字。

所以znode有四种组合：

持久顺序：节点创建后会一直存在zookeeper服务器上，直到主动删除
持久非顺序：每个节点都会为它的一级子节点维护一个顺序
临时顺序：临时节点的生命周期和客户端的会话保持一致。当客户端会话失效，该节点自动清理
临时非顺序：在临时节点上多了一个顺序的特性

版本

Zookeeper 的每个 ZNode 上都会存储数据，对应于每个 ZNode，Zookeeper 都会为其维护一个叫作 Stat 的数据结构。
Stat 中记录了这个 ZNode 的三个数据版本，分别是：

version（当前 ZNode 的版本）

cversion（当前 ZNode 子节点的版本）

aversion（当前 ZNode 的 ACL 版本）

Watcher

Watcher（事件监听器），是 ZooKeeper 中的一个很重要的特性。

Watcher 监听机制是 Zookeeper 中非常重要的特性，我们基于 zookeeper 上创建的节点，可以对这些节点绑定监听事件，比如可以监听节点数据变更、节点删除、子节点状态变更等事件，通过这个事件机制，可以基于 zookeeper实现分布式锁（关于分布式锁可以看这篇文章ZooKeeper 分布式锁的实现原理）、集群管理等功能。

watcher 特性：当数据发生变化的时候， zookeeper 会产生一个 watcher 事件，并且会发送到客户端。但是客户端只会收到一次通知。如果后续这个节点再次发生变化，那么之前设置 watcher 的客户端不会再次收到消息。（watcher 是一次性的操作）。 可以通过循环监听去达到永久监听效果。

ACL
ZooKeeper 采用 ACL（AccessControlLists）策略来进行权限控制，类似于 UNIX 文件系统的权限控制。

ZooKeeper 定义了 5 种权限，如下图：

总体而言，zookeeper有如下特性：

dubbo和Eureka的区别

两者的区别，提一下分布式架构中的CAP理论，即一个分布式框架，只能同时满足C一致性、A可用性、P网络分区容错性这三者中的两个，不可能同时兼备三者。

    从这个角度上来看，Dubbo推荐的注册中心首选ZK，而ZK是一个满足CP的框架；Eureka由于其架构设计，更多专注于AP。

    对于容错机制，Dubbo自身实现了多个错误处理方式，比如失败切换Failover、快速失败Failfast、失败安全Failsafe等，Eureka是借助于Spring Cloud中的熔断器Hytrix实现的容错。

    对于负载均衡，Dubbo自身实现了多种负载均衡方式，比如随机权重、哈希一致性等，Eureka同样是将此功能外放，通过Ribbon等实现了负载均衡。

    服务注册及发现，Dubbo自身封装了NettyClient等通讯工具，而Eureka都是采用的应用层通讯HttpClient。

Zookeeper保证CP

当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

Eureka保证AP

Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：

1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务

2. Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)

3. 当网络稳定时，当前实例新的注册信息会被同步到其它节点中

因此， Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。

数据一致性

   ZAB 是 zookeeper 的原子广播协议，基于 Paxos 算法改的。

  Raft 是工程上使用较为广泛的强一致性、去中心化、高可用的分布式协议。

  这两个算法都没毛病，都可以实现分布式一致性，只是实现方式不同。

  Eureka 选择的是 AP，不要求强一致性，自然没有使用数据一致性算法。