dubbo源码阅读之负载均衡
Posted zhuge134
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了dubbo源码阅读之负载均衡相关的知识，希望对你有一定的参考价值。
负载均衡
在之前集群的文章中，我们分析了通过监听注册中心可以获取到多个服务提供者，并创建多个Invoker，然后通过集群类如FailoverClusterInvoker将多个Invoker封装在一起，而外部的调用者以这个封装的Invoker为入口调用内部的多个Invoker，但是我们一次调用实际只能调用一个真实的Invoker(这里的真实的Invoker对应一个提供者)，所以怎么在多个Invoker中选择出一个Invoker来，使得整体的服务调用的性能最大化，这就是负载均衡策略。另外，除了负载均衡，集群类的一个重要功能就是处理服务调用故障，当一个invoker调用失败后怎么办，根据对这种情况的不同处理策略分为不同的集群类。当然除了以上两个功能，集群类的另一个功能就是粘滞调用，这里不再赘述。
值得一提的是，消费端的Invoker其实是一个分层的结构，我们可以在配置文件中指定多个注册中心，这样就会封装出多个Invoker(每个Invoker对应一个注册中心)，对于这多个Invoker再通过集群类的join方法封装为一个总的Invoker（StaticDirectory），所以集群类在执行故障处理，负载均衡策略时实际上也是分层级的。
好了，集群类的回顾就到这里，说这么多主要是想引出一点：负载均衡逻辑的执行是在集群类中，所以分析负载均衡就以集群类为切入点。
dubbo提供了五种负载均衡器，下面我们一一分析。
RandomLoadBalance（随机）
光看名字，会以为真的就是从Invoker列表中随机选择一个，实际上并不是这么简单，dubbo的随机负载均衡考虑到了权重因素，每个服务提供者的每个方法都有一个有一个权重，权重大的意味着被调用的可能性更大。 so, talk is cheap ,show me your code !
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?
// 表示是否所有的invoker的权重都相等？？
boolean sameWeight = true;
// the weight of every invokers
// 用于记录invoker权重的数组
int[] weights = new int[length];
// the first invoker's weight
// 第一个invoker的权重
int firstWeight = getWeight(invokers.get(0), invocation);
weights[0] = firstWeight;
// The sum of weights
// 所有invoker权重的和
int totalWeight = firstWeight;
// 遍历所有的invoker，获取权重，更新簿记量
for (int i = 1; i < length; i++) {
// 获取权重，默认是100
// 考虑到了服务预热的特性，
// 所谓服务预热是指服务在刚启动时不会一下子被赋予全部的权重，而是缓慢第达到设定的权重值
// 默认权重是100， 默认的预热时间是10分钟
int weight = getWeight(invokers.get(i), invocation);
// save for later use
// 记录权重
weights[i] = weight;
// Sum
// 记录权重和
totalWeight += weight;
// 如果与第一个权重不相等，那么更新簿记量
if (sameWeight && weight != firstWeight) {
sameWeight = false;
}
}
// 如果invoker的权重有区别，那么需要根据权重来随机
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++) {
offset -= weights[i];
if (offset < 0) {
return invokers.get(i);
}
}
}
// If all invokers have the same weight value or totalWeight=0, return evenly.
// 如果所有invoker的权重相等，或者权重和为0, 那么随机选择一个invoker
return invokers.get(ThreadLocalRandom.current().nextInt(length));
}这里指的关注的是所谓的随机并不是完全随机，而是在考虑权重的基础上的随机，这种算法值得我们学习，以后再需要的场景中也可以这样做。
此外，dubbo还有服务预热的特性，就像我在注释中说的，这种策略应该是为了避免在服务刚启动时就涌上来大量的请求，导致服务崩溃，设置一个缓冲时间可以有效避免这种情况，默认的预热时间是10分钟，默认的权重值是100。
RoundRobinLoadBalance（轮询）
接下来，我们分析一下轮询调度算法。
@Override
protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) {
// 方法的key值
String key = invokers.get(0).getUrl().getServiceKey() + "." + invocation.getMethodName();
ConcurrentMap<String, WeightedRoundRobin> map = methodWeightMap.get(key);
if (map == null) {
// 注意，这里使用的是putIfAbsent方法，考虑到并发问题
methodWeightMap.putIfAbsent(key, new ConcurrentHashMap<String, WeightedRoundRobin>());
map = methodWeightMap.get(key);
}
int totalWeight = 0;
// 簿记量，记录当前的最大权重
long maxCurrent = Long.MIN_VALUE;
long now = System.currentTimeMillis();
// 被选中的Invoker
Invoker<T> selectedInvoker = null;
WeightedRoundRobin selectedWRR = null;
for (Invoker<T> invoker : invokers) {
// 获取该url的唯一标识
String identifyString = invoker.getUrl().toIdentityString();
WeightedRoundRobin weightedRoundRobin = map.get(identifyString);
// 获取权重，考虑到预热
int weight = getWeight(invoker, invocation);
if (weightedRoundRobin == null) {
weightedRoundRobin = new WeightedRoundRobin();
// 设置权重
weightedRoundRobin.setWeight(weight);
// 仍然调用putIfAbsent方法
map.putIfAbsent(identifyString, weightedRoundRobin);
// TODO 个人认为这里应该加下面这句
// weightedRoundRobin = map.get(identifyString);
}
if (weight != weightedRoundRobin.getWeight()) {
//weight changed
// 更新权重
weightedRoundRobin.setWeight(weight);
}
// 获取当前的累积权重
long cur = weightedRoundRobin.increaseCurrent();
// 设置更新时间
weightedRoundRobin.setLastUpdate(now);
// 如果累积权重大于当前的最大权重，那么将当前选中的invoker设为这个invoker
// 并更新最大权重值
if (cur > maxCurrent) {
maxCurrent = cur;
selectedInvoker = invoker;
selectedWRR = weightedRoundRobin;
}
// 累加权重和
totalWeight += weight;
}
// 如果invoker有变化，那么将那些长时间未被选到的WeightedRoundRobin清除出去
// 这里用AtomicBoolean来加锁，cas锁
if (!updateLock.get() && invokers.size() != map.size()) {
if (updateLock.compareAndSet(false, true)) {
try {
// copy -> modify -> update reference
ConcurrentMap<String, WeightedRoundRobin> newMap = new ConcurrentHashMap<String, WeightedRoundRobin>();
newMap.putAll(map);
Iterator<Entry<String, WeightedRoundRobin>> it = newMap.entrySet().iterator();
while (it.hasNext()) {
Entry<String, WeightedRoundRobin> item = it.next();
if (now - item.getValue().getLastUpdate() > RECYCLE_PERIOD) {
it.remove();
}
}
methodWeightMap.put(key, newMap);
} finally {
updateLock.set(false);
}
}
}
if (selectedInvoker != null) {
// 这一句很重要
// 选中这个invoker之后，将他的累积权重减去这一轮的总权重，
// 相当于将其放到队尾，当然仍然还是考虑到权重的，权重的大的即是减去总权重也还是有较高的累积权重
selectedWRR.sel(totalWeight);
return selectedInvoker;
}
// should not happen here
// 逻辑上将，代码是不会到这里的
// 但是由于语法的要求这里必须要有返回语句
return invokers.get(0);
}这里的轮询仍然是考虑到权重因素的，这里对于轮询的实现很巧妙，使用累积权重的方法，巧妙地将权重因素考虑进去；而当所有的服务提供者的权重都相等时，这种算法就会退化为标准的轮询算法，实际上累积权重在这里还起到了记忆轮询状态的作用。可以这么形象地理解，当调用过某个提供者后，就把这个提供者扔到靠后面的一个位置，权重越小越靠后，这样就实现了轮询的功能。
LeastActiveLoadBalance
// 最小活跃数，考虑权重因素
@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)
// 相同最小活跃数的invoker数量
int leastCount = 0;
// The index of invokers having the same least active value (leastActive)
// 拥有相同的最小活跃数的那些invoker的下标
int[] leastIndexes = new int[length];
// the weight of every invokers
// 每个invoker的权重
int[] weights = new int[length];
// The sum of the warmup weights of all the least active invokes
// 权重和
int totalWeight = 0;
// The weight of the first least active invoke
// 第一个最小活跃数的invoker的权重
int firstWeight = 0;
// Every least active invoker has the same weight value?
// 如果有多个相同最小活跃数的invoker，他们的权重是否相同
boolean sameWeight = true;
// Filter out all the least active invokers
// 这个循环的作用是选出最小活跃数的invoker，如果有多个相同最小活跃数的invoker，全部选择出来
for (int i = 0; i < length; i++) {
Invoker<T> invoker = invokers.get(i);
// Get the active number of the invoke
int active = RpcStatus.getStatus(invoker.getUrl(), invocation.getMethodName()).getActive();
// Get the weight of the invoke 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 leastIndexs
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 leastIndexs order
leastIndexes[leastCount++] = i;
// Accumulate the total weight of the least active invoker
totalWeight += afterWarmup;
// If every invoker has the same weight?
if (sameWeight && i > 0
&& afterWarmup != firstWeight) {
sameWeight = false;
}
}
}
// Choose an invoker from all the least active invokers
// 如果最小活跃数的invoker只有一个，那么就不用考虑权重因素
if (leastCount == 1) {
// If we got exactly one invoker having the least active value, return this invoker directly.
return invokers.get(leastIndexes[0]);
}
// 如果他们的权重不同，那么需要考虑权重的因素
// 这个方法与RandomLoadBalance中类似
if (!sameWeight && totalWeight > 0) {
// If (not every invoker has the same weight & at least one invoker's weight>0), select randomly based on
// totalWeight.
int offsetWeight = ThreadLocalRandom.current().nextInt(totalWeight);
// Return a invoker based on the random value.
for (int i = 0; i < leastCount; i++) {
int leastIndex = leastIndexes[i];
offsetWeight -= weights[leastIndex];
if (offsetWeight < 0) {
return invokers.get(leastIndex);
}
}
}
// If all invokers have the same weight value or totalWeight=0, return evenly.
// 如果他们的权重相同，那就随机选择一个
return invokers.get(leastIndexes[ThreadLocalRandom.current().nextInt(leastCount)]);
}这个方法相信大家都能看懂，这里我想重点说一下最小活跃数的维护方法。
最小活跃数是通过RpcStatus类维护的，这个类对于每个服务的每个方法都维护了一个RpcStatus类，可以看出来，dubbo对于负载均衡是细化到方法级别的，粒度还是很细的，从前面轮询算法也可以看出来这点。
RpcStatus类中除了维护最小活跃数，还维护了调用事件，总调用时间，调用次数，失败的调用次数等等统计量，那么问题是：这些统计量是在什么时候更新的呢？你肯定会回答当然是在服务调用的时候更新的。那么在代码中是怎么保证在每次服务调用的时候都更新相应的RpcStatus类呢？？答案就是ExtensionLoader的AOP特性，可见dubbo的spi机制真是无处不在，贯穿了框架的各个部分。ExtensionLoader在加载一个接口的实现类的时候会将一些包装类缓存起来，当实例化一个实现类的时候会用这些包装类对实例进行层层包装（通过构造方法），这样就实现了多层代理，每个包装类都会加入一些通用的功能，实际上就是切面的思想。 服务调用的统计其实正是一个通用的功能，很适合作为一个横切面，切入所有的Invoker中。而消费端Invoker的创建是在Protocol.refer方法中，我们看一下Protocol实现类，发现了一些包装类：
- ProtocolFilterWrapper， 嵌入可用的Filter
- ProtocolListenerWrapper, 加入监听器
- QosProtocolWrapper， 启动QOS服务
最小活跃数功能的实现是通过过滤器。ProtocolFilterWrapper.refer方法在创建invoker时会通过层层代理的方式形成一个过滤器链，注意对于注册中心的Invoker是不用添加过滤器链的，只有对真正执行远程调用的那些Invoker才会添加过滤器链。
public <T> Invoker<T> refer(Class<T> type, URL url) throws RpcException {
if (Constants.REGISTRY_PROTOCOL.equals(url.getProtocol())) {
return protocol.refer(type, url);
}
return buildInvokerChain(protocol.refer(type, url), Constants.REFERENCE_FILTER_KEY, Constants.CONSUMER);
}Filter也是一个SPI接口，是通过ExtensionLoader加载的，在加载Filter接口是调用了getActivateExtension方法，与Activate注解有关。
活跃数的功能是通过ActiveLimitFilter过滤器实现的。
ActiveLimitFilter.invoke
@Override
public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {
URL url = invoker.getUrl();
// 调用的方法名
String methodName = invocation.getMethodName();
// 最大活跃数，默认是0，0表示不限制，这个逻辑在RpcStatus.beginCount中
int max = invoker.getUrl().getMethodParameter(methodName, Constants.ACTIVES_KEY, 0);
// 获取方法对应的RpcStatus对象
RpcStatus count = RpcStatus.getStatus(invoker.getUrl(), invocation.getMethodName());
// 如果增加活跃数失败，就需要等待，
// 这里的活跃数类似于信号量，作用是控制最大并发量
if (!count.beginCount(url, methodName, max)) {
long timeout = invoker.getUrl().getMethodParameter(invocation.getMethodName(), Constants.TIMEOUT_KEY, 0);
long start = System.currentTimeMillis();
long remain = timeout;
synchronized (count) {
// 等待活跃数降下来，并试图获取到一个活跃数，知道超时
while (!count.beginCount(url, methodName, max)) {
try {
count.wait(remain);
} catch (InterruptedException e) {
// ignore
}
long elapsed = System.currentTimeMillis() - start;
remain = timeout - elapsed;
if (remain <= 0) {
throw new RpcException("Waiting concurrent invoke timeout in client-side for service: "
+ invoker.getInterface().getName() + ", method: "
+ invocation.getMethodName() + ", elapsed: " + elapsed
+ ", timeout: " + timeout + ". concurrent invokes: " + count.getActive()
+ ". max concurrent invoke limit: " + max);
}
}
}
}
// 到这里说明成功获取到一个活跃数，那么可以继续后面的调用
boolean isSuccess = true;
long begin = System.currentTimeMillis();
try {
return invoker.invoke(invocation);
} catch (RuntimeException t) {
isSuccess = false;
throw t;
} finally {
// 调用结束，释放获取到的活跃数
count.endCount(url, methodName, System.currentTimeMillis() - begin, isSuccess);
// 这里指的思考一下，为什么只有在max>0时才通知
// 因为max<=0时，最大活跃数是Integer.MAX_VALUE, 相当于不设上限，
// 所以在前面的循环中第一次就能获取到活跃数，压根不会进入循环，也就不会获取锁等待，
// 所以这里也就不需要通知了
if (max > 0) {
synchronized (count) {
count.notifyAll();
}
}
}
}注释已经很清楚，就不再赘述。
ConsistentHashLoadBalance
public class ConsistentHashLoadBalance extends AbstractLoadBalance {
public static final String NAME = "consistenthash";
private final ConcurrentMap<String, ConsistentHashSelector<?>> selectors = new ConcurrentHashMap<String, ConsistentHashSelector<?>>();
@SuppressWarnings("unchecked")
@Override
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的唯一标示，
int identityHashCode = System.identityHashCode(invokers);
ConsistentHashSelector<T> selector = (ConsistentHashSelector<T>) selectors.get(key);
// 如果invokers列表变了，就重新hash
if (selector == null || selector.identityHashCode != identityHashCode) {
selectors.put(key, new ConsistentHashSelector<T>(invokers, methodName, identityHashCode));
selector = (ConsistentHashSelector<T>) selectors.get(key);
}
return selector.select(invocation);
}
private static final class ConsistentHashSelector<T> {
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();
// 虚拟节点个数
this.replicaNumber = url.getMethodParameter(methodName, "hash.nodes", 160);
// 参与生成hash值的参数的序号
String[] index = Constants.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]);
}
// 初始化的时候生成hash环
for (Invoker<T> invoker : invokers) {
// 一个地址（ip:port）生成的hash节点实际上是固定的
String address = invoker.getUrl().getAddress();
for (int i = 0; i < replicaNumber / 4; i++) {
byte[] digest = md5(address + i);
for (int h = 0; h < 4; h++) {
// 生成的hash值尽量散列
long m = hash(digest, h);
virtualInvokers.put(m, invoker);
}
}
}
}
public Invoker<T> select(Invocation invocation) {
// 用指定的参数参与生成hash
String key = toKey(invocation.getArguments());
byte[] digest = md5(key);
// 只要参数相同，那么生成的hash值就是相同的，选择到的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) {
Map.Entry<Long, Invoker<T>> entry = virtualInvokers.ceilingEntry(hash);
// entry == null说明hash比treeMap中最大的hash值还大，
// 根据一致性hash环的算法，这是需要绕回第一个节点，即hash最小的那个节点
if (entry == null) {
entry = virtualInvokers.firstEntry();
}
return entry.getValue();
}
// 散列函数，这种方法使生成的hash尽量均匀分散
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;
}
private byte[] md5(String value) {
MessageDigest md5;
try {
md5 = MessageDigest.getInstance("MD5");
} catch (NoSuchAlgorithmException e) {
throw new IllegalStateException(e.getMessage(), e);
}
md5.reset();
byte[] bytes = value.getBytes(StandardCharsets.UTF_8);
md5.update(bytes);
return md5.digest();
}
}}
首先我们要理解一致性hash的算法原理，明白一致性hash算法之后再来看这个类，就简单多了。
值得注意的是，这里使用了TreeMap保存hash环的所有hash值值得借鉴，这样做的好处是查找快速，效率很高。
以上是关于dubbo源码阅读之负载均衡的主要内容，如果未能解决你的问题，请参考以下文章
dubbo的负载均衡策略之RandomLoadBalance加权随机策略源码分析
dubbo的负载均衡策略之RandomLoadBalance加权随机策略源码分析