dubbo常用配置总结

1）连接控制

服务器端连接数(并发)控制的配置方式：

<dubbo:provider protocol="dubbo" accepts="10" />//服务提供者方的配置。

或者：<dubbo:protocol name=“dubbo” accepts=“10” /> //最多在同一时刻接受10个连接

客户端连接数控制的配置方式：

<dubbo:reference interface="com.foo.BarService" connections="10" /> //消费方的配置

2）并发控制

服务器端并发执行的限制的配置：

<dubbo:service interface="com.foo.BarService" executes="10" /> //接口中的每个方法在并行执行中的线程数不超过10个


<dubbo:service interface="com.foo.BarService">
    <dubbo:method name="sayHello" executes="10" />  //知对其中的sayHello方法的并行执行线程数控制在10个以内
</dubbo:service>

客户端并发执行的限制的配置：

<dubbo:service interface="com.foo.BarService" actives="10" /> //接口中每个方法并行连接数不超过10个


<dubbo:reference interface="com.foo.BarService" actives="10" />

对接口中指定方法的配置：

<dubbo:reference interface="com.foo.BarService">
    <dubbo:method name="sayHello" actives="10" />
</dubbo:service>

如果 <dubbo:service> 和 <dubbo:reference> 都配了 connections， <dubbo:reference> 优先.

3）负载均衡的配置load balance

配置服务的客户端的loadbalance属性为leastactive，此 Loadbalance 会调用并发数最小的 Provider（Consumer端并发数）。

<dubbo:reference interface="com.foo.BarService" loadbalance="leastactive"

可选参数有：

random:随机，按权重设计随机概率

roundRobin：轮询，按公约后的权重设置轮询比率

leastActive：最少活跃调用数，相同活跃数的随机，使慢的处理者收到更少的请求

consistentHash：一致性哈希，使得相同参数的请求总是发到同一提供者

4）异步调用客户端的配置；

基于 NIO 的非阻塞实现并行调用，客户端不需要启动多线程即可完成并行调用多个远程服务，相对多线程开销较小。配置方式如下：

<dubbo:reference id="fooService" interface="com.alibaba.foo.FooService">
      <dubbo:method name="findFoo" async="true" /> //async参数表明findFoo方法的调用方式是异步调用
</dubbo:reference>
<dubbo:reference id="barService" interface="com.alibaba.bar.BarService">
      <dubbo:method name="findBar" async="true" /> //async参数表明findBar方法的调用是异步调用。
</dubbo:reference>

接口使用代码调用如下：

// 此调用会立即返回null
fooService.findFoo(fooId);
// 拿到调用的Future引用，当结果返回后，会被通知和设置到此Future
Future<Foo> fooFuture = RpcContext.getContext().getFuture(); 

// 此调用会立即返回null
barService.findBar(barId);
// 拿到调用的Future引用，当结果返回后，会被通知和设置到此Future
Future<Bar> barFuture = RpcContext.getContext().getFuture(); 

// 此时findFoo和findBar的请求同时在执行，客户端不需要启动多线程来支持并行，而是借助NIO的非阻塞完成

// 如果foo已返回，直接拿到返回值，否则线程wait住，等待foo返回后，线程会被notify唤醒
Foo foo = fooFuture.get(); 
// 同理等待bar返回
Bar bar = barFuture.get(); 

// 如果foo需要5秒返回，bar需要6秒返回，实际只需等6秒，即可获取到foo和bar，进行接下来的处理

5）分组聚合客户端的配置；

按组合并返回结果，比如菜单服务，接口一样，但有多种实现，用group区分；

<dubbo:reference interface="com.xxx.MenuService" group="aaa,bbb" merger="true" /> //group表示要查找的分组，如果全部

分组都要查找则用*表示。而merger表示合并查询结果。

6）多版本服务的配置；

服务端的配置：

<dubbo:service interface="com.foo.BarService" version="1.0.0" />//服务提供者的老版本


<dubbo:service interface="com.foo.BarService" version="2.0.0" /> //服务提供者的新版本

客户端的配置：

<dubbo:reference id="barService" interface="com.foo.BarService" version="1.0.0" /> //消费的是老版本的服务


<dubbo:reference id="barService" interface="com.foo.BarService" version="2.0.0" /> //消费的是新版本的服务，全部版本用*表示

7）服务线程模型的配置：

<dubbo:protocol name="dubbo" dispatcher="all" 

其中Dispatcher参数和threadpool参数分别配置了请求转发的处理模式，和处理请求的线程池模型；

Dispatcher 可选配置参数：

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

ThreadPool 可选择线程池模型参数

• fixed固定大小线程池，启动时建立线程，不关闭，一直持有。(缺省)
• cached缓存线程池，空闲一分钟自动删除，需要时重建。
• limited可伸缩线程池，但池中的线程数只会增长不会收缩。(为避免收缩时突然来了大流量引起的性能问题)。

8）集群容错配置：

在集群调用失败时，Dubbo 提供了多种容错方案，缺省为 failover 重试。

Failover Cluster（默认选择）

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

重试次数配置如下：

<dubbo:service retries="2" /> //全部请求错误重试次数，不包含第一次。

或

<dubbo:reference retries="2" /> 

或

<dubbo:reference>
    <dubbo:method name="findFoo" retries="2" /> //findFoo方法的调用重试次数是2
</dubbo:reference>

Failfast Cluster

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

Failsafe Cluster

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

Failback Cluster

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

Forking Cluster

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

Broadcast Cluster

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

参数配置方式如下：

<dubbo:service cluster="failsafe" />

或者：

<dubbo:reference cluster="failsafe" />