关键词：
Dubbo3中的并发控制
XML方式配置
限制类的线程隔离控制（服务端）
限制com.xxx.ApiService的每个方法，服务器端并发执行（或占用线程池线程数）不能超过 10 个：
<dubbo:service interface="com.xxx.ApiService" executes="10" />
Annotation方式配置
限制类的线程隔离控制（服务端）
限制com.xxx.ApiService的每个方法，服务器端并发执行（或占用线程池线程数）不能超过 10 个：
@DubboService(version = "1.0.0",executes=10)
public class DefaultRpcOrderProcessApi implements RpcOrderProcessApi
限制方法的线程隔离控制（服务端）
限制com.xxx.ApiService的sayHello 方法，服务器端并发执行（或占用线程池线程数）不能超过 10 个：
<dubbo:service interface="com.xxx.ApiService">
<dubbo:method name="sayHello" executes="10" />
</dubbo:service>
Annotation方式配置
限制方法的线程隔离控制（服务端）
限制com.xxx.ApiService的sayHello 方法，服务器端并发执行（或占用线程池线程数）不能超过 10 个：
@DubboService(version = "1.0.0",
methods =
@Method(name = "sayHello", executes= 10, retries = 0))
public class DefaultRpcOrderProcessApi implements RpcOrderProcessApi
XML方式配置
限制类的线程隔离控制（消费端）
限制 com.xxx.ApiService的每个方法，每客户端并发执行（或占用连接的请求数）不能超过 10 个：
<dubbo:reference interface="com.xxx.ApiService" actives="10" />
Annotation方式配置
限制类的线程隔离控制（消费端）
限制 com.xxx.ApiService的每个方法，每客户端并发执行（或占用连接的请求数）不能超过 10 个：
@DubboReference(version = "1.0.0",actives = 10)
RpcShopCarProcessApi rpcShopCarProcessApi;
XML方式配置
限制方法的线程隔离控制（消费端）
限制 com.xxx.ApiService 的 sayHello 方法，每客户端并发执行（或占用连接的请求数）不能超过 10 个：
<dubbo:reference interface="com.xxx.ApiService">
<dubbo:method name="sayHello" actives="10" />
</dubbo:service>
Annotation方式配置
限制方法的线程隔离控制（消费端）
限制 com.xxx.ApiService 的 sayHello 方法，每客户端并发执行（或占用连接的请求数）不能超过 10 个：
@DubboReference(version = "1.0.0",methods = @Method(name = "sayHello", actives= 10, retries = 0))
RpcShopCarProcessApi rpcShopCarProcessApi;```
集群负载均衡
在集群负载均衡时，Dubbo 提供了多种均衡策略，缺省为 random 随机调用。配置服务的客户端的 loadbalance 属性为leastactive，此 Loadbalance 会调用并发数最小的 Provider（Consumer端并发数）。
负载均衡策略
目前 Dubbo 内置了如下负载均衡算法，用户可直接配置使用：
| 算法 | 特性 | 备注 |
|---|---|---|
| RandomLoadBalance | 加权随机 | 默认算法，默认权重相同 |
| RoundRobinLoadBalance | 加权轮询 | 借鉴于 Nginx 的平滑加权轮询算法，默认权重相同 |
| LeastActiveLoadBalance | 最少活跃优先 + 加权随机 | 背后是能者多劳的思想 |
| ShortestResponseLoadBalance | 最短响应优先 + 加权随机 | 更加关注响应速度 |
| ConsistentHashLoadBalance | 一致性 Hash | 确定的入参，确定的提供者，适用于有状态请求 |
LoadbalanceRules的选择类型
public interface LoadbalanceRules
/**
* This class select one provider from multiple providers randomly.
**/
String RANDOM = "random";
/**
* Round robin load balance.
**/
String ROUND_ROBIN = "roundrobin";
/**
* Filter the number of invokers with the least number of active calls and count the weights and quantities of these invokers.
**/
String LEAST_ACTIVE = "leastactive";
/**
* Consistent Hash, requests with the same parameters are always sent to the same provider.
**/
String CONSISTENT_HASH = "consistenthash";
/**
* Filter the number of invokers with the shortest response time of success calls and count the weights and quantities of these invokers.
**/
String SHORTEST_RESPONSE = "shortestresponse";
String EMPTY = "";
Random
加权随机，按权重设置随机概率。在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。
- 缺点：存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。
实现的源码如下：
public class RandomLoadBalance extends AbstractLoadBalance
public static final String NAME = "random";
/**
* Select one invoker between a list using a random criteria
* @param invokers List of possible invokers
* @param url URL
* @param invocation Invocation
* @param <T>
* @return The selected invoker
*/
@Override
protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation)
// Number of invokers
int length = invokers.size();
if (!needWeightLoadBalance(invokers,invocation))
return invokers.get(ThreadLocalRandom.current().nextInt(length));
// Every invoker has the same weight?
boolean sameWeight = true;
// the maxWeight of every invokers, the minWeight = 0 or the maxWeight of the last invoker
int[] weights = new int[length];
// The sum of weights
int totalWeight = 0;
for (int i = 0; i < length; i++)
int weight = getWeight(invokers.get(i), invocation);
// Sum
totalWeight += weight;
// save for later use
weights[i] = totalWeight;
if (sameWeight && totalWeight != weight * (i + 1))
sameWeight = false;
if (totalWeight > 0 && !sameWeight)
// If (not every invoker has the same weight & at least one invoker's weight>0), select randomly based on totalWeight.
int offset = ThreadLocalRandom.current().nextInt(totalWeight);
// Return a invoker based on the random value.
for (int i = 0; i < length; i++)
if (offset < weights[i])
return invokers.get(i);
// If all invokers have the same weight value or totalWeight=0, return evenly.
return invokers.get(ThreadLocalRandom.current().nextInt(length));
private <T> boolean needWeightLoadBalance(List<Invoker<T>> invokers, Invocation invocation)
Invoker invoker = invokers.get(0);
URL invokerUrl = invoker.getUrl();
// Multiple registry scenario, load balance among multiple registries.
if (REGISTRY_SERVICE_REFERENCE_PATH.equals(invokerUrl.getServiceInterface()))
String weight = invokerUrl.getParameter(REGISTRY_KEY + "." + WEIGHT_KEY);
if (StringUtils.isNotEmpty(weight))
return true;
else
String weight = invokerUrl.getMethodParameter(invocation.getMethodName(), WEIGHT_KEY);
if (StringUtils.isNotEmpty(weight))
return true;
else
String timeStamp = invoker.getUrl().getParameter(TIMESTAMP_KEY);
if (StringUtils.isNotEmpty(timeStamp))
return true;
return false;
当我们使用它的时候，只需要进行选择loadBalance值作为“random”（ public static final String NAME = “random”;）
RoundRobin
加权轮询，按公约后的权重设置轮询比率，循环调用节点
- 缺点：同样存在慢的提供者累积请求的问题。
源码如下：
public class RoundRobinLoadBalance extends AbstractLoadBalance
public static final String NAME = "roundrobin";
private static final int RECYCLE_PERIOD = 60000;
protected static class WeightedRoundRobin
private int weight;
private AtomicLong current = new AtomicLong(0);
private long lastUpdate;
public int getWeight()
return weight;
public void setWeight(int weight)
this.weight = weight;
current.set(0);
public long increaseCurrent()
return current.addAndGet(weight);
public void sel(int total)
current.addAndGet(-1 * total);
public long getLastUpdate()
return lastUpdate;
public void setLastUpdate(long lastUpdate)
this.lastUpdate = lastUpdate;
private ConcurrentMap<String, ConcurrentMap<String, WeightedRoundRobin>> methodWeightMap = new ConcurrentHashMap<String, ConcurrentMap<String, WeightedRoundRobin>>();
/**
* get invoker addr list cached for specified invocation
* <p>
* <b>for unit test only</b>
*
* @param invokers
* @param invocation
* @return
*/
protected <T> Collection<String> getInvokerAddrList(List<Invoker<T>> invokers, Invocation invocation)
String key = invokers.get(0).getUrl().getServiceKey() + "." + invocation.getMethodName();
Map<String, WeightedRoundRobin> map = methodWeightMap.get(key);
if (map != null)
return map.keySet();
return null;
@Override
protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation)
String key = invokers.get(0).getUrl().getServiceKey() + "." + invocation.getMethodName();
ConcurrentMap<String, WeightedRoundRobin> map = methodWeightMap.computeIfAbsent(key, k -> new ConcurrentHashMap<>());
int totalWeight = 0;
long maxCurrent = Long.MIN_VALUE;
long now = System.currentTimeMillis();
Invoker<T> selectedInvoker = null;
WeightedRoundRobin selectedWRR = null;
for (Invoker<T> invoker : invokers)
String identifyString = invoker.getUrl().toIdentityString();
int weight = getWeight(invoker, invocation);
WeightedRoundRobin weightedRoundRobin = map.computeIfAbsent(identifyString, k ->
WeightedRoundRobin wrr = new WeightedRoundRobin();
wrr.setWeight(weight);
return wrr;
);
if (weight != weightedRoundRobin.getWeight())
//weight changed
weightedRoundRobin.setWeight(weight);
long cur = weightedRoundRobin.increaseCurrent();
weightedRoundRobin.setLastUpdate(now);
if (cur > maxCurrent)
maxCurrent = cur;
selectedInvoker = invoker;
selectedWRR = weightedRoundRobin;
totalWeight += weight;
if (invokers.size() != map.size())
map.entrySet().removeIf(item -> now - item.getValue().getLastUpdate() > RECYCLE_PERIOD);
if (selectedInvoker != null)
selectedWRR.sel(totalWeight);
return selectedInvoker;
// should not happen here
return invokers.get(0);
得出结论可以使用roundrobin进行指定（public static final String NAME = "roundrobin）
LeastActive
加权最少活跃调用优先，活跃数越低，越优先调用，相同活跃数的进行加权随机。活跃数指调用前后计数差（针对特定提供者：请求发送数 - 响应返回数），表特定提供者的任务堆积量，活跃数越低，代表该提供者处理能力越强。
- 使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大；相对的，处理能力越强的节点，处理更多的请求。
public class LeastActiveLoadBalance extends AbstractLoadBalance
public static final String NAME = "leastactive";
@Override
protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation)
// Number of invokers
int length = invokers.size();
// The least active value of all invokers
int leastActive = -1;
// The number of invokers having the same least active value (leastActive)
int leastCount = 0;
// The index of invokers having the same least active value (leastActive)
int[] leastIndexes = new int[length];
// the weight of every invokers
int[] weights = new int[length];
// The sum of the warmup weights of all the least active invokers
int totalWeight = 0;
// The weight of the first least active invoker
int firstWeight = 0;
// Every least active invoker has the same weight value?
boolean sameWeight = true;
// Filter out all the least active invokers
for (int i = 0; i < length; i++)
Invoker<T> invoker = invokers.get(i);
// Get the active number of the invoker
int active = RpcStatus.getStatus(invoker.getUrl(), invocation.getMethodName()).getActive();
// Get the weight of the invoker's configuration. The default value is 100.
int afterWarmup = getWeight(invoker, invocation);
// save for later use
weights[i] = afterWarmup;
// If it is the first invoker or the active number of the invoker is less than the current least active number
if (leastActive == -1 || active < leastActive)
// Reset the active number of the current invoker to the least active number
leastActive = active;
// Reset the number of least active invokers
leastCount = 1;
// Put the first least active invoker first in leastIndexes
leastIndexes[0] = i;
// Reset totalWeight
totalWeight = afterWarmup;
// Record the weight the first least active invoker
firstWeight = afterWarmup;
// Each invoke has the same weight (only one invoker here)
sameWeight = true;
// If current invoker's active value equals with leaseActive, then accumulating.
else if (active == leastActive)
// Record the index of the least active invoker in leastIndexes order
leastIndexes[leastCount++] = i;
// Accumulate the total weight of the least active invoker
totalWeight += afterWarmup;
// If every invoker has the same weight?
if (sameWeight && afterWarmup != firstWeight)
sameWeight = false;
// Choose an invoker from all the dubbo3高级特性「框架与服务」框架与服务的异步调用实践以及开发模式
异步调用在Dubbo中发起异步调用机制，从而提高对应的服务的调用的吞吐能力和调用机制特性说明技术背景从2.7.0开始，Dubbo的所有异步编程接口开始以CompletableFuture为基础，基于NIO的非阻塞实现并行调用，客户端不需要启动多线... 查看详情
dubbo3高级特性「框架与服务」dubbo3客户端和服务端的泛化调用机制体系(代码片段)
实现泛化实现（服务端泛化）服务端泛接口实现方式主要用于服务器端没有API接口及模型类元的情况，参数及返回值中的所有POJO均用Map表示，通常用于框架集成，比如：实现一个通用的远程服务框架，可通过实现RawTypeService接口... 查看详情
dubbo3高级特性「框架与服务」自定义dubbo服务容器及扩展容器实现分析
了解Dubbo3中服务自定义容器类型和使用背景介绍Dubbo3的服务容器是一个standalone的启动程序，因为后台服务不需要Tomcat或JBoss等Web容器的功能，如果硬要用Web容器去加载服务提供方，增加复杂性，也浪费资源。所以服务通常不需要... 查看详情
dubbo3高级特性「框架与服务」在dubbo3中进行参数校验及自定义验证扩展机制(代码片段)
Dubbo3的参数验证机制参数验证功能是基于JSR303实现的，用户只需标识JSR303标准的验证annotation，并通过声明filter来实现验证。JSR303https://jcp.org/en/jsr/detail?id=303Maven依赖<dependency><groupId>javax.validation</groupId><artif 查看详情
dubbo3高级特性「框架与服务」针对出现异常的rpc的服务功能降级机制(代码片段)
服务降级降级Dubbo服务特性说明推荐使用相关限流降级组件（如Sentinel）以达到最佳体验，微服务治理/限流降级服务降级是指服务在非正常情况下进行降级应急处理。使用场景某服务或接口负荷超出最大承载能力范围，需要进行... 查看详情
dubbo3高级特性「框架与服务」服务端通过线程池隔离技术实现资源限制和资源隔离机制(代码片段)
线程池隔离Dubbo3会提供一种新的线程池管理方式，用于隔离服务之间的线程池调用机制，主要用于服务提供者端进行实现服务资源隔离和容器隔离机制，最终的效果就是服务提供者内部的各个服务通过线程池隔离且互... 查看详情
dubbo3高级特性「框架与服务」开发内嵌式注册中心及多注册中心的开发实践(代码片段)
开发内嵌式注册中心引入Maven依赖<dependency><groupId>org.apache.dubbo</groupId><artifactId>dubbo-dependencies-zookeeper</artifactId> 查看详情
dubbo3高级特性「框架与服务」rpc调用上下文的介绍（全链路追踪基础）(代码片段)
使用场景通过上下文（Context）存放当前调用过程中所需的环境信息。特性说明上下文中存放的是当前调用过程中所需的环境信息。所有配置信息都将转换为URL的参数，参见schema配置参考手册中的对应URL参数一列。RpcContext是一个T... 查看详情
dubbo3高级特性「框架与服务」rpc全链路调用追踪参数传递（opentracing）
...在B调C之后，RpcContext记录的是B和C的信息。上下文的种类Dubbo3中，RpcContext被拆分为四大模块（ServerContext、ClientAttachment、ServerAttachment和ServiceContext），它们分别承担了不同的指责：ServiceContext&#x 查看详情
介绍说明」dubbo3新特性概览的介绍说明
Dubbo3的微服务框架系列【Dubbo3入门到精通】总体技术体系介绍及技术指南（目录）本系列专题是关于Dubbo的简单介绍，涵盖Dubbo的核心概念、基本使用方式以及Dubbo3核心功能。Dubbo的基本介绍ApacheDubbo是一款微服务开发框... 查看详情
dubbo3高级特性「系统级别检查」服务端和消费端启动时检查
...有些服务不关心，必须有一方先启动，或者针对于相关的dubbo3所对应的微服务利链路种形成了环路依赖或者相互引用关系。注意：如果你的Sprin 查看详情
深入浅出dubbo3原理及实战「新特性简介」dubbo3新特性概览的介绍说明
Dubbo3的微服务框架系列本系列专题是关于Dubbo的简单介绍，涵盖Dubbo的核心概念、基本使用方式以及Dubbo3核心功能。Dubbo的基本介绍ApacheDubbo是一款微服务开发框架，它提供了RPC通信与微服务治理两大关键能力。使用Dubbo开... 查看详情
dubbo3高级特性「提升系统安全性」ssl的安全服务能力(代码片段)
Dubbo3的TLS保证传输安全特性说明内置的DubboNettyServer和新引入的gRPC协议都提供了基于TLS的安全链路传输机制。TLS的配置都有统一的入口。使用场景对全链路有加密需求的用户可以使用TLS。使用方式API的模式使用方式Provider端建立... 查看详情
dubbo3终极特性「请求流治理体系」一文教你如何搭建dubbo3的控制台服务dubbo-admin
...一个控制台，为Dubbo集群提供更好可视化服务。Admin支持Dubbo3并很好的兼容2.7.x、2.6.x和2.5.x。DubboAdmin的部署方式接下来我们主要会介绍有四种DubboAdmin部署到生产环境的方式基于Helm运行Admin基于Kubernetes运行Admin基于Docker运行Admin基... 查看详情
dubbo3终极特性「流量治理体系」一文教你如何搭建dubbo3的控制台服务dubbo-admin(代码片段)
...个控制台，为Dubbo集群提供更好可视化服务。Admin支持Dubbo3并很好的兼容2.7.x、2.6.x和2.5.x。DubboAdmin的部署方式接下来我们主要会介绍有四种DubboAdmin部署到生产环境的方式基于Helm运行Admin基于Kubernetes运行Admin基于Docker运行Admin... 查看详情
dubbo3.0｜阿里巴巴服务框架三位一体的选择与实践
...一，合二为一并共建新一代的服务框架是必然趋势。Dubbo3.0是Dubbo2.0与HSF融合而来，是阿里经济体面向内部业务、商业化、开源的唯一标准服务框架。服务框架就像铁路的铁轨 查看详情
dubbo3.0｜阿里巴巴服务框架三位一体的选择与实践
...一，合二为一并共建新一代的服务框架是必然趋势。Dubbo3.0是Dubbo2.0与HSF融合而来，是阿里经济体面向内部业务、商业化、开源的唯一标准服务框架。服务框架就像铁路的铁轨一 查看详情
dubbo3.0新特性总结
dubbo3.0的变化： 1.服务发现模型： 2.0采用基于接口粒度的服务发现机制，3.0基于应用粒度的服务发现机制，有利于提高系统资源利用率，降低Dubbo地址的单机内存消耗（50%），降低注册中... 查看详情