共计 5448 个字符，预计需要花费 14 分钟才能阅读完成。
本篇次要是基于 2.7.1 对罕用的 dubbo 配置进行整顿以及介绍 dubbo 配置是如何集成 spring 的。
前言
对于 dubbo 配置，我这里就讲目前我的项目里用的多的两种形式，property 文件配置以及 xml 配置，其实配置的项都一样。property 文件形式的配置对立前缀 dubbo.，xml 形式的配置的配置对立前缀 dubbo:，下文配置项不写前缀了。
罕用配置
application
利用级别的配置，用于配置利用信息
| 配置项 | 作用 |
|---|---|
| name | 利用的名称，用于标识哪个 dubbo 利用 |
| version | 利用的版本 |
| owner | 利用的维护者 |
| logger | 指定日志框架，可选：slf4j, jcl, log4j, log4j2, jdk，默认 log4j |
| compiler | 指定字节码解决类，可选：jdk, javassist，默认 Javassist |
| environment | 指定所属环境，可选：develop, test, product |
module
用于配置以后模块信息，可选，用途不大，只是为了配置补充
| 配置项 | 作用 |
|---|---|
| name | 模块名称 |
| version | 模块的版本 |
| owner | 模块的维护者 |
| isDefault | 是否默认配置，如果配置多个 module 则须要指定 default |
registry
注册核心配置
| 配置项 | 作用 |
|---|---|
| address | 注册核心服务器地址，如果地址没有端口缺省为 9090，同一集群内的多个地址用逗号分隔，如：ip:port,ip:port，不同集群的注册核心，请配置多个 <<dubbo:registry>> 标签 |
| username | 登录注册核心用户名 |
| password | 登录注册核心明码 |
| port | 注册核心缺省端口，当 address 没有带端口时应用此端口做为缺省值，默认 9090 |
| protocol | 注册核心地址协定，反对 dubbo, multicast, zookeeper, redis, consul(2.7.1), sofa(2.7.2), etcd(2.7.2), nacos(2.7.2)等协定 |
| transporter | 网络传输方式，可选 mina,netty，默认 netty |
| check | 注册核心不存在时，是否报错，默认 true |
| timeout | 注册核心申请超时工夫(毫秒)，默认 5000 |
| register | 是否向此注册核心注册服务，如果设为 false，将只订阅，不注册，默认 true |
| subscribe | 是否向此注册核心订阅服务，如果设为 false，将只注册，不订阅，默认 true |
| group | 服务注册分组，跨组的服务不会相互影响，也无奈互相调用，实用于环境隔离。 |
protocol
服务提供者协定配置
| 配置项 | 作用 |
|---|---|
| name | 协定名称，默认 dubbo |
| host | 主动查找本机 IP，多网卡抉择或指定 VIP 及域名时应用，为空则主动查找本机 IP |
| port | 服务端口，dubbo 协定缺省端口为 20880，rmi 协定缺省端口为 1099，http 和 hessian 协定缺省端口为 80；如果没有配置 port，则主动采纳默认端口，如果配置为 -1，则会调配一个没有被占用的端口 |
| threadpool | 线程池类型，可选：fixed/cached，默认 fixed |
| threads | 服务线程池大小(固定大小)，默认 200 |
| iothreads | io 线程池大小(固定大小)，默认 cpu 个数 +1 |
| accepts | 服务提供方最大可承受连接数，默认 0 |
| payload | 申请及响应数据包大小限度，单位：字节，默认 8388608(=8M) |
| codec | 协定编码方式，默认 dubbo |
| serialization | 协定编码方式，协定序列化形式，当协定反对多种序列化形式时应用，比方：dubbo 协定的 dubbo,hessian2,java,compactedjava，以及 http 协定的 json 等，dubbo 协定缺省为 hessian2，rmi 协定缺省为 java，http 协定缺省为 json |
| accesslog | 设为 true，将向 logger 中输入拜访日志，也可填写拜访日志文件门路，间接把拜访日志输入到指定文件 |
| transporter | 协定的服务端和客户端实现类型，比方：dubbo 协定的 mina,netty 等，能够分拆为 server 和 client 配置，dubbo 协定缺省为 netty |
| codec | 协定编码方式，默认 dubbo |
| dispatcher | 协定的音讯派发形式，用于指定线程模型，比方：dubbo 协定的 all, direct, message, execution, connection 等，默认 all |
monitor
监控核心配置
| 配置项 | 作用 |
|---|---|
| protocol | 监控核心协定，如果为 protocol=“registry”，示意从注册核心发现监控核心地址，否则直连监控核心。默认 dubbo |
| address | 直连监控核心服务器地址，address=“10.20.130.230:12080” |
| username | 用户名 |
| password | 明码 |
provider
服务提供者缺省值配置
| 配置项 | 作用 |
|---|---|
| host | 服务主机名，多网卡抉择或指定 VIP 及域名时应用 |
| port | 服务提供者端口 |
| threadpool | 线程池类型，可选：fixed/cached/limit(2.5.3 以上)/eager(2.6.x 以上)，默认 fixed |
| threads | 服务线程池大小(固定大小)，默认 200 |
| iothreads | io 线程池大小(固定大小)，默认 cpu 个数 +1 |
| timeout | 近程服务调用超时工夫(毫秒)，1000 |
| retries | 近程服务调用重试次数，不包含第一次调用，不须要重试请设为 0，默认 2 |
| loadbalance | 负载平衡策略，可选值：random,roundrobin,leastactive，别离示意：随机，轮询，起码沉闷调用，默认 random |
| stub | 设为 true，示意应用缺省代理类名，即：接口名 + Local 后缀。自定义扩大 |
| mock | 设为 true，示意应用缺省 Mock 类名，即：接口名 + Mock 后缀。降级用 |
| token | 令牌验证，为空示意不开启，如果为 true，示意随机生成动静令牌 |
| registry | 向指定注册核心注册，在多个注册核心时应用，值为 <<dubbo:registry>> 的 id 属性，多个注册核心 ID 用逗号分隔，如果不想将该服务注册到任何 registry，可将值设为 N /A |
| weight | 服务权重 |
| executes | 服务提供者每服务每办法最大可并行执行申请数 |
| proxy | 生成动静代理形式，可选：jdk/javassist，默认 javassist |
| cluster | 集群形式，可选：failover/failfast/failsafe/failback/forking，默认 failover |
| deprecated | 服务是否过期，如果设为 true，生产方援用时将打印服务过期正告 error 日志 |
| async | 是否缺省异步执行，不牢靠异步，只是疏忽返回值，不阻塞执行线程，默认 false |
consumer
服务消费者缺省值配置
| 配置项 | 作用 |
|---|---|
| timeout | 近程服务调用超时工夫(毫秒)，默认 1000 |
| retries | 近程服务调用重试次数，不包含第一次调用，不须要重试请设为 0, 仅在 cluster 为 failback/failover 时无效，默认 2 |
| loadbalance | 负载平衡策略，可选值：random,roundrobin,leastactive，别离示意：随机，轮询，起码沉闷调用 |
| async | 是否缺省异步执行，默认 false |
| generic | 是否缺省泛化接口，默认 false |
| check | 启动时查看提供者是否存在，true 报错，false 疏忽，默认 true |
| cluster | 集群形式，可选：failover/failfast/failsafe/failback/forking，默认 failover |
| filter | 服务生产方近程调用过程拦截器名称，多个名称用逗号分隔 |
| registry | 向指定注册核心注册，在多个注册核心时应用，值为 <dubbo:registry> 的 id 属性，多个注册核心 ID 用逗号分隔，如果不想将该服务注册到任何 registry，可将值设为 N /A |
| init | 是否在 afterPropertiesSet()时饥饿初始化援用，否则等到有人注入或援用该实例时再初始化，默认 false |
| cache | 以调用参数为 key，缓存返回后果，可选：lru, threadlocal, jcache 等 |
| validation | 是否启用 JSR303 规范注解验证，如果启用，将对办法参数上的注解进行校验 |
| async | 是否缺省异步执行，默认 false |
| corethreads | 线程池的外围线程数 |
| threads | 线程池的最大线程数 |
| injvm | 是否只裸露在本地 jvm |
| lazy | 是否在发动近程调用的时候初始化连贯 |
| mock | 设为 true，示意应用缺省 Mock 类名，即：接口名 + Mock 后缀。降级用 |
| stub | 设为 true，示意应用缺省代理类名，即：接口名 + Local 后缀。自定义扩大 |
config-center
配置核心配置，平时根本没用
| 配置项 | 作用 |
|---|---|
| protocol | 应用哪个配置核心：apollo、zookeeper、nacos 等。默认 zookeeper |
| address | 配置核心地址，以 zookeeper 为例 1. 指定 protocol，则 address 能够简化为 127.0.0.1:2181；2. 不指定 protocol，则 address 取值为 zookeeper://127.0.0.1:2181 |
| username | 配置核心用户名 |
| password | 配置核心明码 |
| timeout | 获取配置的超时工夫，默认 3000 |
| check | 当配置核心连贯失败时，是否终止利用启动，默认 true |
metadata-report
元数据中心配置，平时根本没用
| 配置项 | 作用 |
|---|---|
| address | 元数据中心地址 |
| username | 元数据中心用户名 |
| password | 元数据中心明码 |
| timeout | 超时工夫 |
dubbo 是如何集成到 spring 的
集成到 spring 的模块是 dubbo-config-spring。
注解形式
咱们在应用注解形式应用 dubbo 的时候通常会用到注解 @EnableDubboConfig
能够看到下面有个 @Import(DubboConfigConfigurationRegistrar.class)，进去看下
实现了接口 ImportBeanDefinitionRegistrar（这是 spring 自定义 bean 的一种形式），从上图圈进去的中央能够看到对 DubboConfigConfiguration.Multiple 或者 DubboConfigConfiguration.Single 进行了注册（Multiple 形式我也没用过），咱们拿 Single 来举例，其实实现形式是一样的。
能够看到诸如 dubbo.application 等咱们在配置文件里配置的前缀及其对应的类。进来 EnableDubboConfigBinding，能够看到又是一个 import。
间接看 registerDubboConfigBindingBeanPostProcessor 办法，咱们发现这里又去注册一个 DubboConfigBindingBeanPostProcessor 类型的 bean，再跟进去看
这里能够看到进行了数据绑定。绑定的类实际上是 DefaultDubboConfigBinder
能够看到最终是用的 spring 的 DataBinder 进行了属性文件内容和对象字段的绑定。
xml 文件形式
spring 对于 xml 的解析其实是提供了扩大的，咱们能够通过扩大来自定义本人的 xml 标签（如何自定义 xml 标签），dubbo 就是这么做的。
从 resources 文件夹下咱们能够看到这些文件，其中 dubbo.xsd 就是所有自定义标签的定义。举个例子：application 定义
<xsd:element name="application" type="applicationType">
<xsd:annotation>
<xsd:documentation><![CDATA[ The application config]]></xsd:documentation>
<xsd:appinfo>
<tool:annotation>
<tool:exports type="org.apache.dubbo.config.ApplicationConfig"/>
</tool:annotation>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>能够看到对于的类型是 applicationType，再看applicationType 定义
这样就很分明了，applicationType定义了所有属性字段。spring.schemas 文件定义了指定的标签文件门路 spring.handlers 文件定义了集成 spring 的自定义解决类，dubbo 的是 DubboNamespaceHandler。
看下图的逻辑根本就很清晰了，标签和类对应起来
最初数据绑定是在org.apache.dubbo.config.spring.schema.DubboBeanDefinitionParser#parse(org.w3c.dom.Element, org.springframework.beans.factory.xml.ParserContext, java.lang.Class<?>, boolean)
总结
这篇实用性比拟强，平时在配置的时候能够参考下。理解原理之后本人也能够实现一个集成 spring 的工具包。
配置也能够参考官网：https://dubbo.apache.org/zh/d…