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调用模块核心功能是发起一个远程方法的调用并顺利拿到返回结果,其体系组成如下:
- 透明代理:通过动态代理技术,屏蔽远程调用细节以提高编程友好性。
- 负载均衡:当有多个提供者是,如何选择哪个进行调用的负载算法。
- 容错机制:当服务调用失败时采取的策略
- 调用方式:支持同步调用、异步调用
10.1、负载均衡
Dubbo 目前官方支持以下负载均衡策略:
- 随机(random):按权重设置随机概率。此为默认算法.
- 轮循 (roundrobin):按公约后的权重设置轮循比率。
- 最少活跃调用数(leastactive):相同活跃数的随机,活跃数指调用前后计数差。
- 一致性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 官方目前支持以下容错策略:
- 失败自动切换:调用失败后基于retries=“2” 属性重试其它服务器
- 快速失败:快速失败,只发起一次调用,失败立即报错。
- 勿略失败:失败后勿略,不抛出异常给客户端。
- 失败重试:失败自动恢复,后台记录失败请求,定时重发。通常用于消息通知操作
- 并行调用: 只要一个成功即返回,并行调用指定数量机器,可通过 forks=“2” 来设置最大并行数。
- 广播调用:广播调用所有提供者,逐个调用,任意一台报错则报错
设置方式支持如下两种方式设置,优先级由低至高
<dubbo:service interface="…" cluster=“broadcast” />
<dubbo:reference interface="…" cluster=“broadcast”/ >
<–
Failover 失败自动切换 retries=“1” 切换次数
Failfast 快速失败
Failsafe 勿略失败
Failback 失败重试,5秒后仅重试一次
Forking 并行调用 forks=“2” 最大并行数
Broadcast 广播调用
–>
10.4、调用方式:
- 同步等待结果返回(默认)
- 异步等待结果返回
- 不需要返回结果
Dubbo 中关于异步等待结果返回的实现流程如下图:
(异步有两个线程,UserThread执行到调用远程接口时交给IOThread去执行,然后自己接着执行下面的代码,等到IOThread接收到远程服务的返回值再交给UserThread,所以这个返回值变量必须volatile,线程可见)
11、令牌验证
通过令牌验证在注册中心控制权限,以决定要不要下发令牌给消费者,可以防止消费者绕过注册中心访问提供者,另外通过注册中心可灵活改变授权方式,而不需修改或升级提供者
<–随机token令牌,使用UUID生成–>
<dubbo:provider interface=“com.foo.BarService” token=“true” />