一、配置文件

1、生产者配置provider.xml

2、消费者配置consumer.xml

3、主要配置分类

标签	用途	解释
<dubbo:service/>	服务配置	用于暴露一个服务，定义服务的元信息，一个服务可以用多个协议暴露，一个服务也可以注册到多个注册中心
<dubbo:reference/>	引用配置	用于创建一个远程服务代理，一个引用可以指向多个注册中心
<dubbo:protocol/>	协议配置	用于配置提供服务的协议信息，协议由提供方指定，消费方被动接受
<dubbo:application/>	应用配置	用于配置当前应用信息，不管该应用是提供者还是消费者
<dubbo:module/>	模块配置	用于配置当前模块信息，可选
<dubbo:registry/>	注册中心配置	用于配置连接注册中心相关信息
<dubbo:monitor/>	监控中心配置	用于配置连接监控中心相关信息，可选
<dubbo:provider/>	提供方配置	当 ProtocolConfig 和 ServiceConfig 某属性没有配置时，采用此缺省值，可选
<dubbo:consumer/>	消费方配置	当 ReferenceConfig 某属性没有配置时，采用此缺省值，可选
<dubbo:method/>	方法配置	用于 ServiceConfig 和 ReferenceConfig 指定方法级的配置信息
<dubbo:argument/>	参数配置	用于指定方法参数配置

4、配置覆盖关系

以 timeout 为例，显示了配置的查找顺序，其它 retries, loadbalance, actives 等类似：

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

其中，服务提供方配置，通过 URL 经由注册中心传递给消费方。

建议由服务提供方设置超时，因为一个方法需要执行多长时间，服务提供方更清楚，如果一个消费方同时引用多个服务，就不需要关心每个服务的超时设置。

理论上 ReferenceConfig 的非服务标识配置，在 ConsumerConfig，ServiceConfig, ProviderConfig 均可以缺省配置。

二、属性配置

如果公共配置很简单，没有多注册中心，多协议等情况，或者想多个 Spring 容器想共享配置，可以使用 dubbo.properties 作为缺省配置。

Dubbo 将自动加载 classpath 根目录下的 dubbo.properties，可以通过JVM启动参数 -Ddubbo.properties.file=xxx.properties 改变缺省配置位置。

1、映射规则

将 XML 配置的标签名，加属性名，用点分隔，多个属性拆成多行

• 比如：dubbo.application.name=foo等价于<dubbo:application name="foo" />
• 比如：dubbo.registry.address=10.20.153.10:9090等价于<dubbo:registry address="10.20.153.10:9090" />

如果 XML 有多行同名标签配置，可用 id 号区分，如果没有 id 号将对所有同名标签生效

• 比如：dubbo.protocol.rmi.port=1234等价于<dubbo:protocol id="rmi" name="rmi" port="1099" />
• 比如：dubbo.registry.china.address=10.20.153.10:9090等价于<dubbo:registry id="china" address="10.20.153.10:9090" />

下面是 dubbo.properties 的一个典型配置：

dubbo.application.name=foodubbo.application.owner=bardubbo.registry.address=10.20.153.10:9090

2、覆盖策略

 

 

JVM 启动 -D 参数优先，这样可以使用户在部署和启动时进行参数重写，比如在启动时需改变协议的端口。

XML 次之，如果在 XML 中有配置，则 dubbo.properties 中的相应配置项无效。

Properties 最后，相当于缺省值，只有 XML 没有配置时，dubbo.properties 的相应配置项才会生效，通常用于共享公共配置，比如应用名。

三、核心配置示例

1、启动时检查

Dubbo 缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止 Spring 初始化完成，以便上线时，能及早发现问题，默认 check="true"。

可以通过 check="false" 关闭检查，比如，测试时，有些服务不关心，或者出现了循环依赖，必须有一方先启动。

另外，如果你的 Spring 容器是懒加载的，或者通过 API 编程延迟引用服务，请关闭 check，否则服务临时不可用时，会抛出异常，拿到 null 引用，如果 check="false"，总是会返回引用，当服务恢复时，能自动连上。

关闭某个服务的启动时检查 (没有提供者时报错)：

关闭所有服务的启动时检查 (没有提供者时报错)：

关闭注册中心启动时检查 (注册订阅失败时报错)：

2、集群容错

Failover Cluster

失败自动切换，当出现失败，重试其它服务器。通常用于读操作，但重试会带来更长延迟。可通过 retries="2" 来设置重试次数(不含第一次)。

重试次数配置如下：

或

或

 

Failfast Cluster

快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。

Failsafe Cluster

失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。

Failback Cluster

失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。

Forking Cluster

并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks="2" 来设置最大并行数。

Broadcast Cluster

广播调用所有提供者，逐个调用，任意一台报错则报错。通常用于通知所有提供者更新缓存或日志等本地资源信息。

例子：

3、负载均衡策略

Random LoadBalance

• 随机，按权重设置随机概率（默认）。

• 在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。

RoundRobin LoadBalance

• 轮询，按公约后的权重设置轮询比率。

• 存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。

LeastActive LoadBalance

• 最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。

• 使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。

ConsistentHash LoadBalance

• 一致性 Hash，相同参数的请求总是发到同一提供者。

• 当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。

• 算法参见：

• 缺省只对第一个参数 Hash，如果要修改，请配置 <dubbo:parameter key="hash.arguments" value="0,1" />

• 缺省用 160 份虚拟节点，如果要修改，请配置 <dubbo:parameter key="hash.nodes" value="320" />

配置

服务端服务级别
      客户端服务级别
      服务端方法级别
      
       
      客户端方法级别
      
       
     

4、线程模型

需要通过不同的派发策略和不同的线程池配置的组合来应对不同的场景:

 

Dispatcher

• all 所有消息都派发到线程池，包括请求，响应，连接事件，断开事件，心跳等。
• direct 所有消息都不派发到线程池，全部在 IO 线程上直接执行。
• message 只有请求响应消息派发到线程池，其它连接断开事件，心跳等消息，直接在 IO 线程上执行。
• execution 只请求消息派发到线程池，不含响应，响应和其它连接断开事件，心跳等消息，直接在 IO 线程上执行。
• connection 在 IO 线程上，将连接断开事件放入队列，有序逐个执行，其它消息派发到线程池。

ThreadPool

• fixed 固定大小线程池，启动时建立线程，不关闭，一直持有。(缺省)
• cached 缓存线程池，空闲一分钟自动删除，需要时重建。
• limited 可伸缩线程池，但池中的线程数只会增长不会收缩。只增长不收缩的目的是为了避免收缩时突然来了大流量引起的性能问题。
• eager 优先创建Worker线程池。在任务数量大于corePoolSize但是小于maximumPoolSize时，优先创建Worker来处理任务。当任务数量大于maximumPoolSize时，将任务放入阻塞队列中。阻塞队列充满时抛出RejectedExecutionException。(相比于cached:cached在任务数量超过maximumPoolSize时直接抛出异常而不是将任务放入阻塞队列)

5、多协议

1、dubbo

• 连接个数：单连接
• 连接方式：长连接
• 传输协议：TCP
• 传输方式：NIO 异步传输
• 序列化：Hessian 二进制序列化
• 适用范围：传入传出参数数据包较小（建议小于100K），消费者比提供者个数多，单一消费者无法压满提供者，尽量不要用 dubbo 协议传输大文件或超大字符串。
• 适用场景：常规远程服务方法调用

2、rmi

• 连接个数：多连接
• 连接方式：短连接
• 传输协议：TCP
• 传输方式：同步传输
• 序列化：Java 标准二进制序列化
• 适用范围：传入传出参数数据包大小混合，消费者与提供者个数差不多，可传文件。
• 适用场景：常规远程服务方法调用，与原生RMI服务互操作

3、hessian

• 连接个数：多连接
• 连接方式：短连接
• 传输协议：HTTP
• 传输方式：同步传输
• 序列化：Hessian二进制序列化
• 适用范围：传入传出参数数据包较大，提供者比消费者个数多，提供者压力较大，可传文件。
• 适用场景：页面传输，文件传输，或与原生hessian服务互操作

4、redis

在RedisProtocol中同样提供了export和refer两个方法

（1）export方法：目前redis协议不支持对外提供服务的操作

（2）refer方法：在refer方法中redisProtocol完成了数据的设置、查询和删除操作，这样是否几个服务消费者就可以共享数据。

redis协议中没有服务提供者，简单来说更像是消费者将增删数据放到redis中，这样消费者自己及其他消费者可以通过接口进行获取数据，并设置数据的超时时间。

6、多版本

当一个接口实现，出现不兼容升级时，可以用版本号过渡，版本号不同的服务相互间不引用。

可以按照以下的步骤进行版本迁移：

0. 在低压力时间段，先升级一半提供者为新版本
1. 再将所有消费者升级为新版本
2. 然后将剩下的一半提供者升级为新版本

老版本服务提供者配置：

新版本服务提供者配置：

老版本服务消费者配置：

新版本服务消费者配置：

如果不需要区分版本，可以按照以下的方式配置 ：

7、服务分组

当一个接口有多种实现时，可以用 group 区分。

服务

引用

任意组 ：

8、隐式传参

有些参数需要RPC带着传递，但是又不想写入到业务代码里。比如实现dubbo调用链。可是使用dubbo的隐式传参，可以通过 RpcContext 上的 setAttachment 和 getAttachment 在服务消费方和提供方之间进行参数的隐式传递。

 

 1、在服务提供方端获取隐式参数

setAttachment 设置的 KV 对，在完成下面一次远程调用会被清空，即多次远程调用要多次设置。RpcContext.getContext().setAttachment("index", "1"); // 隐式传参，后面的远程调用都会隐式将这些参数发送到服务器端，类似cookie，用于框架集成，不建议常规业务使用xxxService.xxx(); // 远程调用// ...

2、在服务提供方端获取隐式参数

public class XxxServiceImpl implements XxxService {     public void xxx() {        // 获取客户端隐式传入的参数，用于框架集成，不建议常规业务使用        String index = RpcContext.getContext().getAttachment("index");     }}