dubbo的一些配置
之前的文章中写了dubbo的初步使用和dubbo和springboot的使用整合,这里来总结下dubbo框架暴露接口常用的配置项。
启动时检查
dubbo提供了在服务启动时的一些检查机制,这个机制包括consumer端对服务提供者的检查、dubbo对注册中心的检查。可以看下官方文档中dubbo:reference标签中关于check属性的配置。
可以看到是默认在启动时检查服务提供者是否存在,不可用时会抛出异常,组织spring初始化。
我们这里可以将之前demo中的userService服务的消费者上配置check=true(默认就是true),来看看在不启动服务提供者时的消费者控制台的报错:
是经典的No Provider错误。这里官方文档也对这个配置做了说明:
如果在配置文件中设置了dubbo.reference.check=false
,则是强制改变所有reference的check值,就算配置中部分接口有声明,也会被覆盖。
同时,也可以在配置文件中设置dubbo.consumer.check=false
,这个是设置所有的reference的check属性默认值,当配置文件中有对单个reference的check的显式设置,会被覆盖掉
这里也可以去看下对注册中心不存在时的错误:
如果我们在reference标签和register标签中显示配置check=“false”,这些错误只有在调用时才会报错。
超时
在dubbo的service和reference标签中都有timeout设置,service标签中timeout是1000ms,代表远程服务调用时间;而reference标签中的timeout设置默认值是继承自dubbo:consumer标签中的默认值,也是1000ms。在前几篇dubbo配置中有提到,timeout的配置遵守一个规则:
- 更精准的优先。方法级别配置会覆盖接口级别的配置,接口级别的配置会覆盖全局的provider、consumer配置。
- 如果精准级别相同,消费方优先。当配置的颗粒度是相同的,如果消费方设置了超时属性,会覆盖服务提供方超时属性的配置。
比如这里设置服务提供者的超时是5000ms:
<dubbo:service interface="service.user.UserService" ref="userService" timeout="5000"
version="0.0.1" stub="service.user.UserServiceStub">
</dubbo:service>
而在消费者配置超时是2000ms:
<dubbo:reference id="userService" interface="service.user.UserService" version="0.0.1" timeout="2000"/>
在服务提供者加入一个3000ms的sleep,这里按照配置的优先级会是消费者的2000ms生效。这里会报dubbo接口调用超时的错误:(错误信息中接口调用花费了2004ms,超时生效的是2000ms配置,报错是waiting server-side response timeout)
重试次数
在dubbo:service和dubbo:reference标签中可以设置retries属性来设置接口调用失败时的重试次数,这里重试此时指的是第一次调用之后的重试次数,并且这里的重试会遵守负载均衡的策略。
service标签中的重试次数默认是2,而reference标签的默认重试次数继承consumer标签的默认次数也是2。这里去简单模拟下有三个服务提给者,调用失败的场景是依靠上边的超时设置,重试次数也尊属消费者优先的规则。
在不同的端口暴露userService服务,每个服务会打印第几个服务,并且有对应的睡眠时间模拟调用:
- 端口是20880,睡眠时间是5000ms
<dubbo:protocol name="dubbo" port="20880" />
<dubbo:service interface="service.user.UserService" ref="userService"
version="0.0.1" stub="service.user.UserServiceStub">
</dubbo:service>
- 端口是20881,睡眠时间是5000ms
<dubbo:protocol name="dubbo" port="20881" />
<dubbo:service interface="service.user.UserService" ref="userService"
version="0.0.1" stub="service.user.UserServiceStub">
</dubbo:service>
- 端口是20882,睡眠时间是2000ms
<dubbo:protocol name="dubbo" port="20882" />
<dubbo:service interface="service.user.UserService" ref="userService"
version="0.0.1" stub="service.user.UserServiceStub">
</dubbo:service>
而在消费者端配置超时时间是3000ms,所以只有端口是20882提供的服务可以不会因为超时调用失败。
消费端的配置:
<dubbo:reference id="userService" interface="service.user.UserService" version="0.0.1" timeout="3000"/>
服务启动之后,发起调用可以看到consumer端的日志:
对20880端口暴露的服务调用超时之后,因为默认的负载均衡策略是加权随机调用,这里重试调用了第三个服务接口调用成功。
这里要知道重试应该配置在幂等的接口上,比如查询、更新等,因为会进行重试进行请求。
多版本功能
同一个服务要升级时可能出现服务不稳定的情况,可以使用版本号进行过度,不同的版本号之间是隔离的。
在service标签上配置的version属性就是服务提供者的版本;而reference标签上的version则代表引用服务的版本。
我们也在上边使用了0.0.1版本,而和spring boot整合的dubbo接口版本是boot-1.0.0。
如果配置version="*" 如下,则表示的是随机引用版本。
<dubbo:reference id="barService" interface="com.foo.BarService" version="*" />
负载均衡
dubbo框架对集群环境下提供了多种负载均衡机制:
-
基于权重的随机负载均衡 Random LoadBalance (dubbo的默认的负载均衡策略)。
-
基于权重的轮询负载均衡机制。
-
最小活跃数负载均衡机制。
-
一致性hash负载均衡(注意这里是一致性hash,因为集群中的服务节点可以增加、减少)。