dubbo常用配置总结

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/wu1226419614/article/details/78009248

1)连接控制

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

<dubbo:provider protocol="dubbo" accepts="10" />//服务提供者方的配置。
或者:<dubbo:protocol name="dubbo" accepts="10" /> //最多在同一时刻接受10个连接

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

<dubbo:reference interface="com.foo.BarService" connections="10" /> //消费方的配置
或者<dubbo:service interface="com.foo.BarService" connections="10" />  //最多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 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" /> //loadbalance参数决定了负载均衡的策略

可选参数有:
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" threadpool="fixed" threads="100" />

其中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" />


+















展开阅读全文

没有更多推荐了,返回首页