在dubbo中我们会看到许多标签属性,如常见的timeout,version,group,这些属性都有自己代表的意义,这次属性的不同配置也会对我们的项目产生不同的影响。

几种配置的介绍

配置名称

配置应用

RegistryConfig

注册中心配置,用于配置连接注册中心相关信息

ProtocolConfig

协议配置,用于配置提供服务的协议信息

ApplicationConfig

用于配置当前应用信息

ServiceConfig

服务配置,用于暴露服务

ProviderConfig

提供方的缺省值,当ProtocolConfig和ServiceConfig某属性没有配置时,采用此缺省值

ReferenceConfig

引用配置,用于创建一个远程服务代理

ConsumerConfig

消费方缺省配置,当ReferenceConfig某属性没有配置时,采用此缺省值

读取配置优先级

dubbo3 配置nacos dubbo.properties参数配置_java


我们可以看到,虚拟机的参数的优先级最高,在虚拟机启动时我们通过-D配置的dubbo属性会覆盖掉我们xml的配置与properties文件的配置。优先级其次为xml配置,也就是我们之前写在dubbo-provider.xml和dubbo-consumer.xml中的相关属性,最后则是xxx.properties,对比我们之前项目该配置文件为application.properties。

当公共配置很简单,没有多注册中心,多协议等情况,或者想多个 Spring 容器想共享配置的情况下可以用dubbo.properties作为缺省配置;需要注意的是我们采用的方法是新建xml文件,在xml中进行配置,所以我们要注意不要忘了在springboot的启动类中添@ImportResource(locatinotallow="xml路径")注解来引入。

配置类型

所有配置项分为三大类,如下表所示:

配置类型

作用

服务发现

表示该配置项用于服务的注册与发现,目的是让消费方找到提供方

服务治理

表示该配置项用于治理服务间的关系,或为开发测试提供便利条件。

性能调优

表示该配置项用于调优性能,不同的选项对性能会产生影响

注意:只有group,interface,version是服务的匹配条件,三者决定是不是同一个服务,其它配置项均为调优和治理参数。所有配置最终都将转换为URL表示,并由服务提供方生成,经注册中心传递给消费方

常用设置

  • 启动时检查(check)
    默认情况下dubbo是开启自动检查的,即当项目启动时会自动检查其依赖的服务是否开启,如果没开是会阻止spring的初始化的,即check=true;我们可以将check置为false来关闭启动时检查,如我们在测试或者对其他服务没有依赖的时候可以关闭检查;
  1. 关闭某个服务的启动检查
    在引用该服务的@Reference注解上添加check=false,如下:
<dubbo:reference id="dubboService" 
     interface="SpringBootDemo.api.DubboService" check="false"  />
  1. 关闭所有服务的启动时检查
    可以在application.properties中添加
    dubbo.consumer.check=false,或者在consumer服务消费者缺省值配置中配置check=false,如下:
<dubbo:consumer  check="false"  />
  • 超时(timeout,默认为1000)
    超时:当消费者调用提供者时由于网络等原因有可能会造成长时间拿不到响应,而请求还在不断的发送这就有可能造成线程阻塞,使用timeout设置超时时间当超过该时间就会抛出异常;设置如下:
    当只针对某个服务时:@Reference(timeout=XXX)  
    当针对所有服务时:dubbo.consumer.timeout=XXX
  • 重试次数(retries)
    当调用失败或超时后重新尝试调用的次数,其值不包含第一次;设置如下:
    当只针对某个服务时:@Reference(retries=XXX)
    当针对所有服务时:dubbo.consumer.retries=XXX
  • 多版本(version)
    当出现系统版本升级时,新版本有可能不够稳定,这时候可以通过设置version来进行平滑的过渡。
    而新旧版本我们可以通过version来定义,假设老版本的version=1.0.0新版本的version=2.0.0;
        老版本服务提供者:@Service(version=‘1.0.0’)
        新版本服务提供者:@Service(version=‘2.0.0’)
        老版本服务消费者:@Reference(version=‘1.0.0’)
        新版本服务消费者:@Reference(version=‘2.0.0’) 
    这样新旧版本就完美错开,只会调用version对应的服务,如果调用的时候不需要区分版本号,则进行如下配置:@Reference(version=’*’),这样dubbo会默认在新老版本中随机调用。

一些需要注意的小问题

以timeout为例,我们来看一下配置的查找(优先级)顺序

dubbo3 配置nacos dubbo.properties参数配置_xml_02

从图中我们可以看到:

  • 方法级优先,接口级次之,全局配置再次之。
  • 如果级别一样,则消费方优先,提供方次之。

在具体的生产中,我们常会考虑超时的设置时间问题,我们看到如果在consumer方也配置了超时时间,那么该设置便会覆盖provider设置的超时时间,但是一个方法需要执行多长时间,服务提供方更清楚,所以在这里建议大家可以将timeout这类属性的配置写在provider当中,这样的话,如果一个消费方同时引用多个服务,也可以不需要关心每个服务的超时设置,减少项目的报错。