Dubbo基础知识

1、Dubbo核心功能：

Dubbo是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。

2、Dubbo框架图：

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

3、引入Dubbo依赖默认的其他依懒：

4、Dubbo配置的关系图：

Dubbo配置的整体说明：

标签	用途
dubbo:application/	公共 用于配置当前应用信息，不管该应用是提供者还是消费者
dubbo:registry/	公共 用于配置连接注册中心相关信息
dubbo:protocol/	服务 用于配置提供服务的协议信息，协议由提供方指定，消费方被动接受
dubbo:service/	服务 用于暴露一个服务，定义服务的元信息，一个服务可以用多个协议暴露，一个服务也可以注册到多个注册中心
dubbo:provider/	服务 当 ProtocolConfig 和 ServiceConfig 某属性没有配置时，采用此缺省值，可选
dubbo:consumer/	引用 当 ReferenceConfig 某属性没有配置时，采用此缺省值，可选
dubbo:reference/	引用 用于创建一个远程服务代理，一个引用可以指向多个注册中心
dubbo:method/	公共 用于 ServiceConfig 和 ReferenceConfig 指定方法级的配置信息
dubbo:argument/	公共 用于指定方法参数配置

5、先来看一个简单配置测试

<dubbo:service interface=“tuling.dubbo.server.UserService” timeout=“2000”>

通过字面了解 timeout即服务的执行超时时间。但当服务执行真正超时的时候 报的错跟timeout并没有半毛钱的关系，其异常堆栈如下：

可以看到错误表达的意思是 因为Channel 关闭导致 无法返回 Response 消息。
出现这情况的原因在于 虽然timeout 配置在服务端却用在客户端，其表示的是客户端调用超时间，而非服务端方法的执行超时。当我们去看客户端的日志时候就能看到timeout异常了

类似这种配在服务端用在客户端的配置还有很多，如retries(重试次数)、async（是否异步）、loadbalance(负载均衡)等。

6、配置的优先级问题：

dubbo:provider与dubbo:service ，dubbo:consumer与dubbo:reference分不清楚 ?

在服务端配置timeout 之后 所有客户端都会采用该方超时时间，其客户端可以自定义超时时间吗？通过 <dubbo:reference timeout=“2000”> 可以设定，或者在<dubbo:consumer timeout=“2000”> 也可以设定 ，甚至可以设定到方法级别 <dubbo:method name=“getUser” timeout=“2000”/>。加上服务端的配置，超时总共有6处可以配置。如果6处都配置了不同的值，最后肯定只会有一个超时值生效，其优先级如下：

7、接口暴露与引用：

暴露接口的通常做法是 接口与实现分离，服务端将 接口、模型、异常 等统一放置于一个模块，实现置于另一个模块。调用方通过Maven进行引用。

8、Dubbo所推荐的注册中心Zookeeper

Zookeeper 是 Apacahe Hadoop 的子项目，是一个树型的目录服务，支持变更推送，适合作为 Dubbo 服务的注册中心，工业强度较高，可用于生产环境，并推荐使用

9、失败重连

提供者突然断开：基于Zookeeper 临时节点机制实现，在客户端会话超时后 Zookeeper会自动删除所有临时节点，默认为40秒。

问题：在zookeeper 断开的40秒内 如果 有客户端加入 会调用 已失效的提供者连接吗？

答：不会，提供者宕机后 ，其与客户端的链接也随即断开，客户端在调用前会检测长连接状态。

10、Dubbo调用模块概述：

dubbo调用模块核心功能是发起一个远程方法的调用并顺利拿到返回结果，其体系组成如下：

1. 透明代理：通过动态代理技术，屏蔽远程调用细节以提高编程友好性。
2. 负载均衡：当有多个提供者是，如何选择哪个进行调用的负载算法。
3. 容错机制：当服务调用失败时采取的策略
4. 调用方式：支持同步调用、异步调用
   

10.1、负载均衡

Dubbo 目前官方支持以下负载均衡策略：

1. 随机(random)：按权重设置随机概率。此为默认算法.
2. 轮循 (roundrobin):按公约后的权重设置轮循比率。
3. 最少活跃调用数(leastactive):相同活跃数的随机，活跃数指调用前后计数差。
4. 一致性Hash(consistenthash ):相同的参数总是发到同一台机器

设置方式支持如下四种方式设置，优先级由低至高

• 1 <-- 服务端级别–>
  <dubbo:service interface="…" loadbalance=“roundrobin” />
• 2 <-- 客户端级别–>
  <dubbo:reference interface="…" loadbalance=“roundrobin” />
• 3 <-- 服务端方法级别–>
  <dubbo:service interface="…">
  <dubbo:method name="…" loadbalance=“roundrobin”/>
  </dubbo:service>
• 4 <-- 客户端方法级别–>
  <dubbo:reference interface="…">
  <dubbo:method name="…" loadbalance=“roundrobin”/>
  </dubbo:reference>

10.2、一至性hash 算法图解：

（计算结果落在哪个区间就顺时针找第一个节点访问，为了防止几个节点距离太近导致分配不均匀，它内部默认虚拟创建160个节点，使得访问分配均匀）

10.3、容错

Dubbo 官方目前支持以下容错策略：

1. 失败自动切换：调用失败后基于retries=“2” 属性重试其它服务器
2. 快速失败：快速失败，只发起一次调用，失败立即报错。
3. 勿略失败：失败后勿略，不抛出异常给客户端。
4. 失败重试：失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作
5. 并行调用: 只要一个成功即返回，并行调用指定数量机器，可通过 forks=“2” 来设置最大并行数。
6. 广播调用：广播调用所有提供者，逐个调用，任意一台报错则报错
   设置方式支持如下两种方式设置，优先级由低至高
   <dubbo:service interface="…" cluster=“broadcast” />
   <dubbo:reference interface="…" cluster=“broadcast”/ >

<–
Failover 失败自动切换 retries=“1” 切换次数
Failfast 快速失败
Failsafe 勿略失败
Failback 失败重试，5秒后仅重试一次
Forking 并行调用 forks=“2” 最大并行数
Broadcast 广播调用
–>

10.4、调用方式：

1. 同步等待结果返回（默认）
2. 异步等待结果返回
3. 不需要返回结果

Dubbo 中关于异步等待结果返回的实现流程如下图：
(异步有两个线程，UserThread执行到调用远程接口时交给IOThread去执行，然后自己接着执行下面的代码，等到IOThread接收到远程服务的返回值再交给UserThread,所以这个返回值变量必须volatile,线程可见)

11、令牌验证

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

<–随机token令牌，使用UUID生成–>
<dubbo:provider interface=“com.foo.BarService” token=“true” />