DUBBO

不同

dubbo RPC支持的协议更广泛，而且他最有效地特性是支持长连接，这样避免了多次重复创建TCP连接的开销。另外，HTTP因为协议的特效，会有一系列的HTTP header，这些内容往往会占用几K的数据，访问量特别巨大的时候，这些无关的数据其实也是一种负担。而使用dubboRPC，协议可以自定义，这些无关数据都可以省掉的。

至于安全，dubbo设计之初基本都是考虑内网通讯，安全上基本没什么考虑，比http的安全差远了。

rpc长连接、传输效率较高，可定制化路由，适用于内部系统互联；
http短连接，协议标准化且易读，容易对接外部系统，适用于上层业务模块

dubbo角色，关系

1. 角色说明:
   Provider 暴露服务的服务提供方
   Consumer 调用远程服务的服务消费方
   Registry 服务注册与发现的注册中心
   Monitor 统计服务的调用次数和调用时间的监控中心
   Container 服务运行容器

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

3. 常用配置，服务端

4. 常用配置，消费端

zookeeper 注册中心

1. 流程说明：
   服务提供者启动时: 向 /dubbo/com.foo.BarService/providers 目录下写入自己的 URL 地址
   服务消费者启动时: 订阅 /dubbo/com.foo.BarService/providers 目录下的提供者 URL 地址。并向 /dubbo/com.foo.BarService/consumers 目录下写入自己的 URL 地址
   监控中心启动时: 订阅 /dubbo/com.foo.BarService 目录下的所有提供者和消费者 URL 地址。

2. 支持以下功能：
   当提供者出现断电等异常停机时，注册中心能自动删除提供者信息
   当注册中心重启时，能自动恢复注册数据，以及订阅请求
   当会话过期时，能自动恢复注册数据，以及订阅请求
   当设置 时，记录失败注册和订阅请求，后台定时重试
   可通过 设置 zookeeper 登录信息
   可通过 设置 zookeeper 的根节点，不设置将使用无根树
   支持 * 号通配符 ，可订阅服务的所有分组和所有版本的提供者。

3. ZooKeeper宕机之后，consumer和provider还能否通信？
   可以。消费者从ZK获取provider地址列表后，会在本地缓存一份。当ZK注册中心所有节点全部宕掉之后，消费者可以使用本地缓存的服务列表和provider进行通信。
   ZK的意义在于为consumer和provider提供服务地址的发布/订阅服务，让消费者及时感知最新的服务列表，consumer真正调用provider是通过某种通信协议直接调用，并不依赖ZK。
   所以当zookeeper宕机之后，不会影响消费者调用服务提供者，影响的是zookeeper宕机之后如果提供者有变动，增加或者减少，zk无法把变更通知推送给consumer，consumer会因为感知不到变更时间，不去拉取最新的服务列表，导致本地缓存的服务列表有可能过时的。

Dubbo之启动时检查（check属性）

Dubbo缺省会在启动时检查依赖的服务是否可用，不可用时抛出异常，阻止Spring初始化完成，以便上线时，能及早发现问题，默认check=true。
关闭某个服务的启动时检查：（没有提供者时报错）

关闭所有服务的启动时检查：（没有提供者时报错）

关闭注册中心启动时检查：（注册订阅失败时报错）

dubbo负载均衡与集群集群容错

Dubbo 提供了多种均衡策略，缺省为 random 随机调用。

• Random LoadBalance
  随机，按权重设置随机概率。(默认值)
• RoundRobin LoadBalance
  轮询，按公约后的权重设置轮询比率。(按权重分配)
• LeastActive LoadBalance
  最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。
  一致性 Hash，相同参数的请求总是发到同一提供者。

1. 服务端服务级别

2. 客户端服务级别

1. 服务端方法级别

2. 客户端方法级别

集群容错

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

1. 各节点关系：
   　　这里的 Invoker 是 Provider 的一个可调用 Service 的抽象，Invoker 封装了 Provider 地址及 Service 接口信息
   　　Directory 代表多个 Invoker，可以把它看成 List ，但与 List 不同的是，它的值可能是动态变化的，比如注册中心推送变更
   　　Cluster 将 Directory 中的多个 Invoker 伪装成一个 Invoker，对上层透明，伪装过程包含了容错逻辑，调用失败后，重试另一个
   　　Router 负责从多个 Invoker 中按路由规则选出子集，比如读写分离，应用隔离等
   　　LoadBalance 负责从多个 Invoker 中选出具体的一个用于本次调用，选的过程包含了负载均衡算法，调用失败后，需要重选

Failover Cluster (默认值)
失败自动切换，当出现失败，重试其它服务器 。通常用于读操作，但重试会带来更长延迟。可通过 retries=“2” 来设置重试次数(不含第一次)。

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

dubbo的provider和consumer的配置文件中，如果都配置了timeout的超时时间，dubbo默认以consumer中配置的时间为准

在dubbo的用户手册中，对配置有这样的推荐用法：
在Provider上尽量多配置Consumer端属性
原因如下：

作服务的提供者，比服务使用方更清楚服务性能参数，如调用的超时时间，合理的重试次数，等等
在Provider配置后，Consumer不配置则会使用Provider的配置值，即Provider配置可以作为Consumer的缺省值。否则，Consumer会使用Consumer端的全局设置，这对于Provider不可控的，并且往往是不合理的
PS: 配置的覆盖规则：1) 方法级配置别优于接口级别，即小Scope优先 2) Consumer端配置 优于 Provider配置 优于 全局配置，最后是Dubbo Hard Code的配置值（见配置文档）

dubbo的provider有2种线程池：

IO处理线程池。（直接通过netty等来配置）
服务调用线程池。
　　如果事件处理的逻辑能迅速完成，并且不会发起新的 IO 请求，比如只是在内存中记个标识，则直接在 IO 线程上处理更快，因为减少了线程池调度。
　　但如果事件处理逻辑较慢，或者需要发起新的 IO 请求，比如需要查询数据库，则必须派发到线程池，否则 IO 线程阻塞，将导致不能接收其它请求。
　　如果用 IO 线程处理事件，又在事件处理过程中发起新的 IO 请求，比如在连接事件中发起登录请求，会报“可能引发死锁”异常，但不会真死锁。

1. Dispatcher
   all 所有消息都派发到线程池，包括请求，响应，连接事件，断开事件，心跳等。
   direct 所有消息都不派发到线程池，全部在 IO 线程上直接执行。
   message 只有请求响应消息派发到线程池，其它连接断开事件，心跳等消息，直接在 IO 线程上执行。
2. execution 只请求消息派发到线程池，不含响应，响应和其它连接断开事件，心跳等消息，直接在 IO 线程上执行。
   connection 在 IO 线程上，将连接断开事件放入队列，有序逐个执行，其它消息派发到线程池。
3. ThreadPool

• fixed 固定大小线程池，启动时建立线程，不关闭，一直持有。(缺省)
• cached 缓存线程池，空闲一分钟自动删除，需要时重建。
• limited 可伸缩线程池，但池中的线程数只会增长不会收缩。只增长不收缩的目的是为了避免收缩时突然来了大流量引起的性能问题。
• eager 优先创建Worker线程池。在任务数量大于corePoolSize但是小于maximumPoolSize时，优先创建Worker来处理任务。当任务数量大于maximumPoolSize时，将任务放入阻塞队列中。阻塞队列充满时抛出RejectedExecutionException。(相比于cached:cached在任务数量超过maximumPoolSize时直接抛出异常而不是将任务放入阻塞队列)