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，因为集群中的服务节点可以增加、减少)。