标签：先来 ast 比较 定义 相同 direct 源码 ide 图片
目录
Dubbo 系列（07-3）集群容错 - 负载均衡
相关文档推荐：
在 Dubbo 的整个集群容错流程中，首先经过 Directory 获取所有的 Invoker 列表，然后经过 Routers 根据路由规则过滤 Invoker，最后幸存下来的 Invoker 还需要经过负载均衡 LoadBalance 这一关，选出最终调用的 Invoker。在前篇文章已经分析了 服务字典 和 服务路由 的基本原理，接下来继续分析 LoadBalance。
Dubbo-2.7.3 提供了 4 种负载均衡实现，分别是：
总结： 四种 负载均衡实现类均继承自 AbstractLoadBalance， 该类实现了 LoadBalance 接口，还封装了一些公共逻辑 ，比如服务提供者权重计算逻辑。
Dubbo 默认是基于权重随机算法的 RandomLoadBalance，根据 loadbalance 参数可以指定负载均衡算法。接口定义如下：
@SPI(RandomLoadBalance.NAME)
public interface LoadBalance {
@Adaptive("loadbalance")
<T> Invoker<T> select(List<Invoker<T>> invokers, URL url, Invocation invocation) throws RpcException;
}AbstractLoadBalance 除了实现了 LoadBalance 接口，还提供了服务提供者权重计算逻辑。
首先来看一下负载均衡的入口方法 select，如下：
@Override
public <T> Invoker<T> select(List<Invoker<T>> invokers, URL url, Invocation invocation) {
if (CollectionUtils.isEmpty(invokers)) {
return null;
}
// 如果 invokers 列表中仅有一个 Invoker，直接返回即可，无需进行负载均衡
if (invokers.size() == 1) {
return invokers.get(0);
}
// 调用 doSelect 方法进行负载均衡，该方法为抽象方法，由子类实现
return doSelect(invokers, url, invocation);
}总结： select 本身的逻辑很简单，将具体的负载均衡算法委托给子类 doSelect 实现。
AbstractLoadBalance 还提供了服务提供者权重计算逻辑。具体实现如下：
protected int getWeight(Invoker<?> invoker, Invocation invocation) {
// 从 url 中获取指定方法权重 weight 配置值，默认值为 100
int weight = invoker.getUrl().getMethodParameter(invocation.getMethodName(), WEIGHT_KEY, DEFAULT_WEIGHT);
if (weight > 0) {
// 获取服务提供者启动时间戳
long timestamp = invoker.getUrl().getParameter(REMOTE_TIMESTAMP_KEY, 0L);
if (timestamp > 0L) {
// 计算服务提供者运行时长
int uptime = (int) (System.currentTimeMillis() - timestamp);
// 获取服务预热时间，默认为10分钟
int warmup = invoker.getUrl().getParameter(WARMUP_KEY, DEFAULT_WARMUP);
// 如果服务运行时间小于预热时间，则重新计算服务权重，即降权
if (uptime > 0 && uptime < warmup) {
// 重新计算服务权重
weight = calculateWarmupWeight(uptime, warmup, weight);
}
}
}
return weight >= 0 ? weight : 0;
}总结： 权重的计算分两步：一是获取指定方法 weight 参数，默认值是 100；二是如果服务的启动时间小于预热时间，根据比例（uptime/warmup）重新计算权重大小，也就是通常说的冷启动。
冷启动的目的是对服务进行降权，避免让服务在启动之初就处于高负载状态。服务预热是一个优化手段，与此类似的还有 JVM 预热。主要目的是让服务启动后“低功率”运行一段时间，使其效率慢慢提升至最佳状态。
static int calculateWarmupWeight(int uptime, int warmup, int weight) {
// 计算权重，下面代码逻辑上形似于 (uptime / warmup) * weight。
// 随着服务运行时间 uptime 增大，权重计算值 ww 会慢慢接近配置值 weight
int ww = (int) ((float) uptime / ((float) warmup / (float) weight));
return ww < 1 ? 1 : (ww > weight ? weight : ww);
}RandomLoadBalance 是加权随机算法的具体实现，它的算法思想很简单。假设我们有一组服务器 servers = [A, B, C]，他们对应的权重为 weights = [5, 3, 2]，权重总和为10。现在把这些权重值平铺在一维坐标值上，[0, 5) 区间属于服务器 A，[5, 8) 区间属于服务器 B，[8, 10) 区间属于服务器 C。接下来通过随机数生成器生成一个范围在 [0, 10) 之间的随机数，然后计算这个随机数会落到哪个区间上。比如数字3会落到服务器 A 对应的区间上，此时返回服务器 A 即可。
@Override
protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) {
// 1. 构建每个 Invoker 对应的权重数组 weights[]
int length = invokers.size();
// 1.1 sameWeight表示是否所有的 Invoker 具有相同的权重值
boolean sameWeight = true;
int[] weights = new int[length];
int firstWeight = getWeight(invokers.get(0), invocation);
weights[0] = firstWeight;
int totalWeight = firstWeight;
// 1.2 计算总权重 totalWeight，并检测每个服务提供者的权重是否相同 sameWeight
for (int i = 1; i < length; i++) {
int weight = getWeight(invokers.get(i), invocation);
weights[i] = weight;
totalWeight += weight;
if (sameWeight && weight != firstWeight) {
sameWeight = false;
}
}
// 2. 权重值不相等时，计算随机数落在哪个区间上
if (totalWeight > 0 && !sameWeight) {
// 随机获取一个 [0, totalWeight) 区间内的数字
int offset = ThreadLocalRandom.current().nextInt(totalWeight);
// 循环让 offset 数减去服务提供者权重值，当 offset 小于0时，返回相应的 Invoker。
// 举例说明一下，我们有 servers = [A, B, C]，weights = [5, 3, 2]，offset = 7。
// 第一次循环，offset - 5 = 2 > 0，即 offset > 5，
// 表明其不会落在服务器 A 对应的区间上。
// 第二次循环，offset - 3 = -1 < 0，即 5 < offset < 8，
// 表明其会落在服务器 B 对应的区间上
for (int i = 0; i < length; i++) {
// 让随机值 offset 减去权重值
offset -= weights[i];
if (offset < 0) {
// 返回相应的 Invoker
return invokers.get(i);
}
}
}
// 3. 权重值相同，此时直接随机返回一个即可
return invokers.get(ThreadLocalRandom.current().nextInt(length));
}总结： RandomLoadBalance 的算法比较简单，大致分为三步：
RandomLoadBalance 经过多次请求后，能够将调用请求按照权重值进行“均匀”分配。它是一个简单、高效的负载均衡实现，因此 Dubbo 选择它作为缺省实现。
LeastActiveLoadBalance 翻译过来是最小活跃数负载均衡。活跃调用数越小，表明该服务提供者效率越高，单位时间内可处理更多的请求。此时应优先将请求分配给该服务提供者。
LeastActiveLoadBalance 需要配合 ActiveLimitFilter 使用，这个过滤器会记录每个接口方法的活跃数，进行负载均衡时每次也只从活跃数最少的 Invoker 里选出一个 Invoker 来执行。
LeastActiveLoadBalance 可以看成是 RandomLoadBalance 的加强版，因为如果选出有多个活跃数最小的 invokers，之后的逻辑和 RandomLoadBalance 完全一样。
@Override
protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) {
// 1. 初始化各种计数器
int length = invokers.size();
int leastActive = -1;
int leastCount = 0;
int[] leastIndexes = new int[length];
int[] weights = new int[length];
int totalWeight = 0;
int firstWeight = 0;
boolean sameWeight = true;
// 2. pk获取活跃数最小的invokers
for (int i = 0; i < length; i++) {
Invoker<T> invoker = invokers.get(i);
// 2.1 核心，获取活跃数
int active = RpcStatus.getStatus(invoker.getUrl(), invocation.getMethodName()).getActive();
int afterWarmup = getWeight(invoker, invocation); // 权重值
weights[i] = afterWarmup;
// 2.2 pk获取新的最小活跃数（第一个，之前的最小活跃数清空）
if (leastActive == -1 || active < leastActive) {
leastActive = active; // 重新记录最小活跃数
leastCount = 1; // 重新记录最小活跃个数
leastIndexes[0] = i; // 重新记录 Invoker
totalWeight = afterWarmup; // 重新记录总权重值
firstWeight = afterWarmup; // 重新记录总权重
sameWeight = true; // 重新记录是否权重值相等
// 2.3 pk获取相同的最小活跃数（多个）
} else if (active == leastActive) {
leastIndexes[leastCount++] = i;
totalWeight += afterWarmup; // 等同于RandomLoadBalance
if (sameWeight && i > 0
&& afterWarmup != firstWeight) {
sameWeight = false;
}
}
}
// 3. 如果同时有多个活跃数最小的 invokers，等同于 RandomLoadBalance
if (leastCount == 1) {
return invokers.get(leastIndexes[0]);
}
if (!sameWeight && totalWeight > 0) {
int offsetWeight = ThreadLocalRandom.current().nextInt(totalWeight);
for (int i = 0; i < leastCount; i++) {
int leastIndex = leastIndexes[i];
offsetWeight -= weights[leastIndex];
if (offsetWeight < 0) {
return invokers.get(leastIndex);
}
}
}
return invokers.get(leastIndexes[ThreadLocalRandom.current().nextInt(leastCount)]);
}总结： 最后可以看到 LeastActiveLoadBalance 相对于 RandomLoadBalance 除了多出一个最小活跃数的比较外，其余的好像基本一致。
int active = RpcStatus.getStatus(invoker.getUrl(), invocation.getMethodName()).getActive();在 ActiveLimitFilter 中，请求处理前计数器 +1，请求处理后（不管成功或失败或异常）计数器 -1，这个计数器就是最小活跃数。相当于以下模拟代码，当然真实的 Filter 处理比这个要复杂一些。
try {
RpcStatus.beginCount(url, methodName, max);
...
RpcStatus.endCount(url, methodName, getElapsed(invocation), true)
} catch(Exception e) {
RpcStatus.endCount(url, methodName, getElapsed(invocation), false);
}标签：先来 ast 比较 定义 相同 direct 源码 ide 图片
原文地址：https://www.cnblogs.com/binarylei/p/11675282.html
