血肉模糊的灵魂
也曾想着摘花送给神明
负载均衡
当我们的一个服务节点无法支撑现有的访问量时，我们会部署多个节点，组成一个集群，然后通过负载均衡，将请求分发给这个集群下的每个服务节点，从而达到多个服务节点共同分担请求压力的目的。
伪流程
分类
- 软负载：软件层面，代码层面的负载均衡，类似于 Dubbo 中的负载均衡策略
- 硬负载：硬件层面的负载均衡设备，类似于 F5
硬负载不足：
- 搭建负载均衡设备或 TCP/IP 四层代理，需要额外成本
- 请求流量都经过负载均衡设备，多经过一次网络传输，会额外浪费一些性能，而且在网络传输过程中，会产生不确定的因素。例如：超时，数据包丢失…
- 负载均衡添加节点和摘除节点，一般都要手动添加，当大批量扩容和下线时，会有大量的人工操作，“服务发现”在操作上是个问题
- 我们在服务治理的时候，针对不同接口服务、服务的不同分组，我们的负载均衡策略是需要可配的，如果大家都经过这一个负载均衡设备，就不容易根据不同的场景来配置不同的负载均衡策略了
Dubbo 中负载均衡策略源码分析
在 Dubbo 中，所有负载均衡实现类均继承自 AbstractLoadBalance
AbstractLoadBalance 不仅继承于 LoadBalance，还实现了一些公用的抽象逻辑，例如：
select接口：服务调用者需要通过负载均衡必然要经过这个关卡，参数传过来所有的服务提供者列表，如果仅有一个服务提供者则直接进行返回，如果有多个服务提供者，则进入 doSelect 的子类的负载均衡策略进行执行
getWeight 接口：服务提供者权重计算逻辑，在实际的负载均衡逻辑基本都会涉及到服务提供者权重的获得，在 Dubbo 中，关于服务提供者权重的获取引入了服务预热的优化手段。
服务预热：
主要用于保证当服务运行时长小于服务预热时间时，对服务进行降权，避免让服务在启动之初就处于高负载状态。服务预热是一个优化手段，与此类似的还有 JVM 预热。主要目的是让服务启动后“低功率”运行一段时间，使其效率慢慢提升至最佳状态
Hotspot 虚拟机内置了两个即时编译器，如果一段代码被调用次数达到一定程度，就会被判定为热代码交给即时编译器即时编译为本地代码。提高运行速度
在 Java 运行过程中，JVM 虚拟机会把高频的代码编译成机器码，被加载过的类也会被缓存到 JVM 缓存中，再次使用的时候不会触发临时加载，这样就使得热点代码执行不用每次都通过解释，从而提高执行速度
int getWeight(Invoker<?> invoker, Invocation invocation) {
int weight;
//获取 Url 用来获取配置的权重
URL url = invoker.getUrl();
// Multiple registry scenario, load balance among multiple registries.
if (REGISTRY_SERVICE_REFERENCE_PATH.equals(url.getServiceInterface())) {
weight = url.getParameter(REGISTRY_KEY + "." + WEIGHT_KEY, DEFAULT_WEIGHT);
} else {
weight = url.getMethodParameter(invocation.getMethodName(), WEIGHT_KEY, DEFAULT_WEIGHT);
if (weight > 0) {
//获取服务提供者启动的时间
long timestamp = invoker.getUrl().getParameter(TIMESTAMP_KEY, 0L);
if (timestamp > 0L) {
//当前时间-服务提供者启动时间得出服务已经启动了多久
long uptime = System.currentTimeMillis() - timestamp;
if (uptime < 0) {
return 1;
}
//获取服务需要预热的时间，默认10分钟
int warmup = invoker.getUrl().getParameter(WARMUP_KEY, DEFAULT_WARMUP);
if (uptime > 0 && uptime < warmup) {
//服务提供者启动了还没有达到服务预热结束的时间，则重新计算权重
weight = calculateWarmupWeight((int)uptime, warmup, weight);
}
}
}
}
return Math.max(weight, 0);
}
//重新计算权重
static int calculateWarmupWeight(int uptime, int warmup, int weight) {
//下面的表达式等价于(uptime / warmup) * weight，可见随着启动时间增加，计算的服务提供者权重值也越来越大
int ww = (int) ( uptime / ((float) warmup / weight));
//最大值不超过配置的权重大小，只是为了在服务提供者预热的途中给予较少的时间
return ww < 1 ? 1 : (Math.min(ww, weight));
}
权重随机
思想：
获取所有服务提供者权重，判断所有服务提供者的权重是否都相等，相等的话随机一个，不相等则按照权重的大小随机，权重大的分配的数量的概率大
源码：
protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) {
// Number of invokers
int length = invokers.size();
// 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) {
//总权重值范围随机一个值
int offset = ThreadLocalRandom.current().nextInt(totalWeight);
//根据随机值返回相应的服务提供者
for (int i = 0; i < length; i++) {
//看下weight数组保存的是什么就明白了
if (offset < weights[i]) {
return invokers.get(i);
}
}
}
//所有服务提供者权重相等，随机一个即可
return invokers.get(ThreadLocalRandom.current().nextInt(length));
}
加权最少活跃数
思想：
在具体实现中，每个服务提供者对应一个活跃数 active。初始情况下，所有服务提供者活跃数均为0。每收到一个请求，活跃数加1，完成请求后则将活跃数减1。在服务运行一段时间后，性能好的服务提供者处理请求的速度更快，因此活跃数下降的也越快，此时这样的服务提供者能够优先获取到新的服务请求
活跃调用数越小，表明该服务提供者效率越高，单位时间内可处理更多的请求。此时应优先将请求分配给该服务提供者
某一时刻它们的活跃数相同，此时 Dubbo 会根据它们的权重去分配请求，权重越大，获取到新请求的概率就越大。如果两个服务提供者权重相同，此时随机选择一个即可
源码：
protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) {
int length = invokers.size();
int leastActive = -1;
int leastCount = 0;
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;
int firstWeight = 0;
// Every least active invoker has the same weight value?
boolean sameWeight = true;
// 遍历 invokers 列表
for (int i = 0; i < length; i++) {
Invoker<T> invoker = invokers.get(i);
//获取活跃数
int active = RpcStatus.getStatus(invoker.getUrl(), invocation.getMethodName()).getActive();
int afterWarmup = getWeight(invoker, invocation);
// save for later use
weights[i] = afterWarmup;
//找出活跃数最少的服务提供者
if (leastActive == -1 || active < leastActive) {
leastActive = active;
leastCount = 1;
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;
//最小的活跃数有多个
} 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;
}
}
}
if (leastCount == 1) {
// If we got exactly one invoker having the least active value, return this invoker directly.
return invokers.get(leastIndexes[0]);
}
// 有多个 Invoker 具有相同的最小活跃数，但它们之间的权重不同
if (!sameWeight && totalWeight > 0) {
//权重随机，和第一种权重随机的思想差不多，看下weights数组保存的是什么
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)]);
}
一致性哈希
思想：
一致性哈希：
用于大规模缓存系统的负载均衡。它的工作过程是这样的，首先根据 ip 或者其他的信息为缓存节点生成一个 hash，并将这个 hash 投射到 [0, 2的32次方 - 1] 的圆环上。当有查询或写入请求时，则为缓存项的 key 生成一个 hash 值。然后查找第一个大于或等于该 hash 值的缓存节点，并到这个节点中查询或写入缓存项。如果当前节点挂了，则在下一次查询或写入缓存时，为缓存项查找另一个大于其 hash 值的缓存节点即可。大致效果如下图所示，每个缓存节点在圆环上占据一个位置。如果缓存项的 key 的 hash 值小于缓存节点 hash 值，则到该缓存节点中存储或读取缓存项。比如下面绿色点对应的缓存项将会被存储到 cache-2 节点中。由于 cache-3 挂了，原本应该存到该节点中的缓存项最终会存储到 cache-4 节点中
在 Dubbo 的一致性哈希的负载均衡策略中引入了虚拟节点，让 Invoker 在圆环上分散开来，避免数据倾斜问题。所谓数据倾斜是指，由于节点不够分散，导致大量请求落到了同一个节点上，而其他节点只会接收到了少量请求的情况。比如：
如上，由于 Invoker-1 和 Invoker-2 在圆环上分布不均，导致系统中75%的请求都会落到 Invoker-1 上，只有 25% 的请求会落到 Invoker-2 上。解决这个问题办法是引入虚拟节点，通过虚拟节点均衡各个节点的请求量。
源码：
protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) {
String methodName = RpcUtils.getMethodName(invocation);
String key = invokers.get(0).getUrl().getServiceKey() + "." + methodName;
// 获取 invokers 原始的 hashcode
int invokersHashCode = invokers.hashCode();
ConsistentHashSelector<T> selector = (ConsistentHashSelector<T>) selectors.get(key);
// 如果 invokers 是一个新的 List 对象，意味着服务提供者数量发生了变化，可能新增也可能减少了。
// 此时 selector.identityHashCode != identityHashCode 条件成立
if (selector == null || selector.identityHashCode != invokersHashCode) {
// 创建新的 ConsistentHashSelector
selectors.put(key, new ConsistentHashSelector<T>(invokers, methodName, invokersHashCode));
selector = (ConsistentHashSelector<T>) selectors.get(key);
}
// 调用 ConsistentHashSelector 的 select 方法选择 Invoker
return selector.select(invocation);
}
private static final class ConsistentHashSelector<T> {
// 使用 TreeMap 存储 Invoker 虚拟节点
private final TreeMap<Long, Invoker<T>> virtualInvokers;
private final int replicaNumber;
private final int identityHashCode;
private final int[] argumentIndex;
ConsistentHashSelector(List<Invoker<T>> invokers, String methodName, int identityHashCode) {
this.virtualInvokers = new TreeMap<Long, Invoker<T>>();
this.identityHashCode = identityHashCode;
URL url = invokers.get(0).getUrl();
// 获取虚拟节点数，默认为160
this.replicaNumber = url.getMethodParameter(methodName, HASH_NODES, 160);
// 获取参与 hash 计算的参数下标值，默认对第一个参数进行 hash 运算
String[] index = COMMA_SPLIT_PATTERN.split(url.getMethodParameter(methodName, HASH_ARGUMENTS, "0"));
argumentIndex = new int[index.length];
for (int i = 0; i < index.length; i++) {
argumentIndex[i] = Integer.parseInt(index[i]);
}
for (Invoker<T> invoker : invokers) {
String address = invoker.getUrl().getAddress();
for (int i = 0; i < replicaNumber / 4; i++) {
// 对 address + i 进行 md5 运算，得到一个长度为16的字节数组
byte[] digest = Bytes.getMD5(address + i);
// 对 digest 部分字节进行4次 hash 运算，得到四个不同的 long 型正整数
for (int h = 0; h < 4; h++) {
// h = 0 时，取 digest 中下标为 0 ~ 3 的4个字节进行位运算
// h = 1 时，取 digest 中下标为 4 ~ 7 的4个字节进行位运算
// h = 2, h = 3 时过程同上
long m = hash(digest, h);
// 将 hash 到 invoker 的映射关系存储到 virtualInvokers 中，
// virtualInvokers 需要提供高效的查询操作，因此选用 TreeMap 作为存储结构
virtualInvokers.put(m, invoker);
}
}
}
}
public Invoker<T> select(Invocation invocation) {
// 将参数转为 key（字符串）
String key = toKey(invocation.getArguments());
// 对参数 key 进行 md5 运算
byte[] digest = Bytes.getMD5(key);
// 取 digest 数组的前四个字节进行 hash 运算，再将 hash 值传给 selectForKey 方法，
// 寻找合适的 Invoker
return selectForKey(hash(digest, 0));
}
private String toKey(Object[] args) {
StringBuilder buf = new StringBuilder();
for (int i : argumentIndex) {
if (i >= 0 && i < args.length) {
buf.append(args[i]);
}
}
return buf.toString();
}
private Invoker<T> selectForKey(long hash) {
// 到 TreeMap 中查找第一个节点值大于或等于当前 hash 的 Invoker
Map.Entry<Long, Invoker<T>> entry = virtualInvokers.ceilingEntry(hash);
// 如果 hash 大于 Invoker 在圆环上最大的位置，此时 entry = null，
// 需要将 TreeMap 的头节点赋值给 entry
if (entry == null) {
entry = virtualInvokers.firstEntry();
}
// 返回 Invoker
return entry.getValue();
}
private long hash(byte[] digest, int number) {
return (((long) (digest[3 + number * 4] & 0xFF) << 24)
| ((long) (digest[2 + number * 4] & 0xFF) << 16)
| ((long) (digest[1 + number * 4] & 0xFF) << 8)
| (digest[number * 4] & 0xFF))
& 0xFFFFFFFFL;
}
}
注意：
-
ConsistentHashLoadBalance 的负载均衡逻辑只受参数值影响，
-
具有相同参数值的请求将会被分配给同一个服务提供者。ConsistentHashLoadBalance 不关系权重
平滑加权轮询
思想：
参考自 Nginx 的平滑加权轮询负载均衡。每个服务器对应两个权重，分别为 weight 和 currentWeight。其中 weight 是固定的，currentWeight 会动态调整，初始值为0。当有新的请求进来时，遍历服务器列表，让它的 currentWeight 加上自身权重。遍历完成后，找到最大的 currentWeight，并将其减去权重总和，然后返回相应的服务器即可
解决服务节点平滑行，穿插获取请求
源码：
protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) {
// key = 全限定类名 + "." + 方法名，比如 com.xxx.DemoService.sayHello
String key = invokers.get(0).getUrl().getServiceKey() + "." + invocation.getMethodName();
// 获取 url 到 WeightedRoundRobin 映射表，如果为空，则创建一个新的
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;
// 下面这个循环主要做了这样几件事情：
// 1. 遍历 Invoker 列表，检测当前 Invoker 是否有
// 相应的 WeightedRoundRobin，没有则创建
// 2. 检测 Invoker 权重是否发生了变化，若变化了，
// 则更新 WeightedRoundRobin 的 weight 字段
// 3. 让 current 字段加上自身权重，等价于 current += weight
// 4. 设置 lastUpdate 字段，即 lastUpdate = now
// 5. 寻找具有最大 current 的 Invoker，以及 Invoker 对应的 WeightedRoundRobin，
// 暂存起来，留作后用
// 6. 计算权重总和
for (Invoker<T> invoker : invokers) {
String identifyString = invoker.getUrl().toIdentityString();
//获取权重
int weight = getWeight(invoker, invocation);
// 检测当前 Invoker 是否有对应的 WeightedRoundRobin，没有则创建
WeightedRoundRobin weightedRoundRobin = map.computeIfAbsent(identifyString, k -> {
WeightedRoundRobin wrr = new WeightedRoundRobin();
wrr.setWeight(weight);
return wrr;
});
// Invoker 权重不等于 WeightedRoundRobin 中保存的权重，说明权重变化了，此时进行更新
if (weight != weightedRoundRobin.getWeight()) {
//weight changed
weightedRoundRobin.setWeight(weight);
}
// 让 current 加上自身权重，等价于 current += weight
long cur = weightedRoundRobin.increaseCurrent();
// 设置 lastUpdate，表示近期更新过
weightedRoundRobin.setLastUpdate(now);
// 找出最大的 current
if (cur > maxCurrent) {
maxCurrent = cur;
// 将具有最大 current 权重的 Invoker 赋值给 selectedInvoker
selectedInvoker = invoker;
// 将 Invoker 对应的 weightedRoundRobin 赋值给 selectedWRR，留作后用
selectedWRR = weightedRoundRobin;
}
// 计算权重总和
totalWeight += weight;
}
// 对 <identifyString, WeightedRoundRobin> 进行检查，过滤掉长时间未被更新的节点。
// 该节点可能挂了，invokers 中不包含该节点，所以该节点的 lastUpdate 长时间无法被更新。
// 若未更新时长超过阈值后，就会被移除掉，默认阈值为60秒。
if (invokers.size() != map.size()) {
// 遍历修改，即移除过期记录
map.entrySet().removeIf(item -> now - item.getValue().getLastUpdate() > RECYCLE_PERIOD);
}
if (selectedInvoker != null) {
// 让 current 减去权重总和，等价于 current -= totalWeight
selectedWRR.sel(totalWeight);
// 返回具有最大 current 的 Invoker
return selectedInvoker;
}
// should not happen here
return invokers.get(0);
}
最短响应时间
2.7.7 release 版本新加的一种负载均衡
思想：
过滤成功调用响应时间最短的服务提供者数量，并计算这些服务提供者的权重和数量，如果只有一个服务提供者，则直接使用该调服务提供者；如果有多个调用者并且权重不相同，则根据总权重随机；如果有多个调用者且权重相同，则将被随机调用
源码：
protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) {
// Number of invokers
int length = invokers.size();
// Estimated shortest response time of all invokers
long shortestResponse = Long.MAX_VALUE;
// The number of invokers having the same estimated shortest response time
int shortestCount = 0;
// The index of invokers having the same estimated shortest response time
int[] shortestIndexes = new int[length];
// the weight of every invokers
int[] weights = new int[length];
// The sum of the warmup weights of all the shortest response invokers
int totalWeight = 0;
// The weight of the first shortest response invokers
int firstWeight = 0;
// Every shortest response invoker has the same weight value?
boolean sameWeight = true;
// Filter out all the shortest response invokers
for (int i = 0; i < length; i++) {
Invoker<T> invoker = invokers.get(i);
RpcStatus rpcStatus = RpcStatus.getStatus(invoker.getUrl(), invocation.getMethodName());
//获取最短相应时间，接口分析在下方
long succeededAverageElapsed = rpcStatus.getSucceededAverageElapsed();
//获取服务提供者活跃数
int active = rpcStatus.getActive();
//计算总等待时间
long estimateResponse = succeededAverageElapsed * active;
int afterWarmup = getWeight(invoker, invocation);
weights[i] = afterWarmup;
// 找到最短响应时间的服务提供者
if (estimateResponse < shortestResponse) {
shortestResponse = estimateResponse;
shortestCount = 1;
shortestIndexes[0] = i;
totalWeight = afterWarmup;
firstWeight = afterWarmup;
sameWeight = true;
//最短响应时间的服务提供者有多个
} else if (estimateResponse == shortestResponse) {
shortestIndexes[shortestCount++] = i;
totalWeight += afterWarmup;
if (sameWeight && i > 0 && afterWarmup != firstWeight) {
//权重不相等
sameWeight = false;
}
}
}
if (shortestCount == 1) {
return invokers.get(shortestIndexes[0]);
}
//最短响应时间的服务提供者有多个，并且权重不相等，按照权重随机
if (!sameWeight && totalWeight > 0) {
int offsetWeight = ThreadLocalRandom.current().nextInt(totalWeight);
for (int i = 0; i < shortestCount; i++) {
int shortestIndex = shortestIndexes[i];
offsetWeight -= weights[shortestIndex];
if (offsetWeight < 0) {
return invokers.get(shortestIndex);
}
}
}
//权重相同，随机选择即可
return invokers.get(shortestIndexes[ThreadLocalRandom.current().nextInt(shortestCount)]);
}
/**
* 计算最短响应时间
*/
public long getSucceededAverageElapsed() {
//总数量-失败数量为成功数量
long succeeded = getSucceeded();
if (succeeded == 0) {
return 0;
}
//总调用响应时间 / 成功数量为最短响应时间
return getSucceededElapsed() / succeeded;
}
bilibili账号：段某人
文章持续更新，可以微信扫码关注第一时间阅读
468
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
