深入理解Dubbo原理系列（五）- Dubbo集群容错、路由、负载均衡实现原理

最新推荐文章于 2023-12-08 11:40:17 发布
最新推荐文章于 2023-12-08 11:40:17 发布
阅读量382 收藏 1
点赞数
分类专栏： Dubbo
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/Zong_0915/article/details/113563957
版权

深入理解Dubbo原理系列（五）- Dubbo集群容错、路由、负载均衡实现原理

一. Dubbo容错

1.1 Cluster层

Cluster层可以看做一个集群容错层。包含几个核心接口：

  • Cluster（接口，提供Failover等容错策略）
  • Directory
  • Router
  • LoadBalance

Cluster的整体工作流程可以分为以下几步（基本上和RPC调用的流程是一样的）：

  1. 生成Invoker对象，（不同的Cluster生成不同的ClusterInvoker）调用其invoker方法。
  2. 获得可调用的服务列表。
  3. 负载均衡。
  4. RPC调用。

流程图如下：
在这里插入图片描述

1.2 容错机制

1.2.1 Cluster接口关系

容错的接口主要有两大类：

  • Cluster：顶层接口
  • ClusterInvoker：负责实现容错策略部分。

Cluster的实现类，这里称为A类，A和ClusterInvoker是一个一对一的关系。我们知道Cluster接口可以有多种A实现类，那么在每个A中，都要实现其join（）方法，并返回一个对应类型的ClusterInvoker实现。

以FailoverCluster为例，来看下他的继承关系：
在这里插入图片描述
FailoverCluster类：

public class FailoverCluster extends AbstractCluster {
    public final static String NAME = "failover";

    @Override
    public <T> AbstractClusterInvoker<T> doJoin(Directory<T> directory) throws RpcException {
        return new FailoverClusterInvoker<>(directory);
    }
}

最终还是等同于实现了Cluster接口的join（）方法

public abstract class AbstractCluster implements Cluster {
	 @Override
    public <T> Invoker<T> join(Directory<T> directory) throws RpcException {
        return buildClusterInterceptors(doJoin(directory), directory.getUrl().getParameter(REFERENCE_INTERCEPTOR_KEY));
    }

    protected abstract <T> AbstractClusterInvoker<T> doJoin(Directory<T> directory) throws RpcException;
}

此外，AbstractClusterInvoker是一个抽象类，封装一些通用的模板逻辑：如获取服务列表、负载均衡、调用服务提供者等。其下面有7大子类，分别实现了不同的集群容错机制：
在这里插入图片描述

1.2.2 容错机制概述

Cluseter的具体实现:用户可以在<dubbo :service> 、<dubbo:reference> 、<dubbo:consumer> 、<dubbo:provider>标签上通过cluster属性设置，其代码实现

Failover策略

Failover是Dubbo的默认容错策略，因为Cluster接口上的@SPI注解中，引用了FailoverCluster。当调用出现失败时，会重试其他服务器。同时，用户还可以通过retries="2"设置重试次数。
在这里插入图片描述
代码（后文都是xxxClusterInvoker类下的doInvoke（）方法）：FailoverClusterInvoker下的doInvoke（）方法：

public class FailoverClusterInvoker<T> extends AbstractClusterInvoker<T> {

	@Override
    @SuppressWarnings({"unchecked", "rawtypes"})
    public Result doInvoke(Invocation invocation, final List<Invoker<T>> invokers, LoadBalance loadbalance) throws RpcException {
        List<Invoker<T>> copyInvokers = invokers;
        // 1.校验传入的Invoker列表是否为空
        checkInvokers(copyInvokers, invocation);
        String methodName = RpcUtils.getMethodName(invocation);
        // 2.获取参数配置，从调用的URL中获取对应的retries，即重试次数
        int len = getUrl().getMethodParameter(methodName, RETRIES_KEY, DEFAULT_RETRIES) + 1;
        if (len <= 0) {
            len = 1;
        }
        // 3.初始化一些集合和对象。用于保存调用过程中出现的异常、记录调用了哪些节点
        RpcException le = null; // last exception.
        List<Invoker<T>> invoked = new ArrayList<Invoker<T>>(copyInvokers.size()); // invoked invokers.
        Set<String> providers = new HashSet<String>(len);
        // 4.通过for循环完成重试，len=重试次数，成功则返回，失败则继续循环，否则抛出最后的异常
        for (int i = 0; i < len; i++) {
            // 5.若循环次数大于1，则代表有过失败，则检验节点是否被销毁、传入的列表是否为空
            if (i > 0) {
                checkWhetherDestroyed();
                copyInvokers = list(invocation);
                // check again
                checkInvokers(copyInvokers, invocation);
            }
            // 6.调用select做负载均衡，得到要调用的节点，并记录在上述的集合中
            Invoker<T> invoker = select(loadbalance, invocation, copyInvokers, invoked);
            invoked.add(invoker);
            RpcContext.getContext().setInvokers((List) invoked);
            try {
            	// 7.远程调用
                Result result = invoker.invoke(invocation);
                if (le != null && logger.isWarnEnabled()) {
                    //...
                }
                return result;
            } catch (RpcException e) {
                //...
            } finally {
                providers.add(invoker.getUrl().getAddress());
            }
        }
        throw new RpcException(....);
    }
}

流程图如下：
在这里插入图片描述

Failfast策略

快速失败，当请求失败后，快速返回异常结果，不做任何重试。会对请求 做负载均衡，通常使用在非幕等接口的调用上。

代码：

 @Override
public Result doInvoke(Invocation invocation, List<Invoker<T>> invokers, LoadBalance loadbalance) throws RpcException {
	// 1.校验参数
    checkInvokers(invokers, invocation);
    // 2.负载均衡
    Invoker<T> invoker = select(loadbalance, invocation, invokers, null);
    try {
    	// 3.进行远程调用，若捕捉到异常，则封装成RpcException类进行返回。
        return invoker.invoke(invocation);
    } catch (Throwable e) {
        if (e instanceof RpcException && ((RpcException) e).isBiz()) { // biz exception.
            throw (RpcException) e;
        }
        throw new RpcException(...);
    }
}
Failsafe策略

当出现异常时，直接忽略异常。会对请求做负载均衡。既然是忽略异常，那么这种调用则适用于不关心调用是否成功的一些功能。

代码：

@Override
public Result doInvoke(Invocation invocation, List<Invoker<T>> invokers, LoadBalance loadbalance) throws RpcException {
    try {
    	// 1.检查
        checkInvokers(invokers, invocation);
        // 2.负载均衡
        Invoker<T> invoker = select(loadbalance, invocation, invokers, null);
        // 3.调用，若出现异常，则返回一个空的结果
        return invoker.invoke(invocation);
    } catch (Throwable e) {
        logger.error("Failsafe ignore exception: " + e.getMessage(), e);
        return AsyncRpcResult.newDefaultAsyncResult(null, null, invocation); // ignore
    }
}
Fallback策略

**请求失败后，会自动记录在失败队列中，并由一个定时线程池定时重试，适用于一些异步或最终一致性的请求。**请求会做负载均衡。

代码：

@Override
protected Result doInvoke(Invocation invocation, List<Invoker<T>> invokers, LoadBalance loadbalance) throws RpcException {
    Invoker<T> invoker = null;
    try {
    	// 1.检查
        checkInvokers(invokers, invocation);
        // 2.负载均衡
        invoker = select(loadbalance, invocation, invokers, null);
        // 3.远程调用
        return invoker.invoke(invocation);
    } catch (Throwable e) {
        // 4.若出现异常，将invocation保存到重试集合addFailed中，并返回一个空的结果集。
        // 定时线程池将addFailed集合中的失败请求拿出来进行重新请求，若成功则从集合中移除。
        addFailed(loadbalance, invocation, invokers, invoker);
        return AsyncRpcResult.newDefaultAsyncResult(null, null, invocation); // ignore
    }
}
Forking策略

同时调用多个相同的服务，只要其中一个返回，则立即返回结果。若所有请求都失败时，Forking才算失败

代码：

@Override
@SuppressWarnings({"unchecked", "rawtypes"})
public Result doInvoke(final Invocation invocation, List<Invoker<T>> invokers, LoadBalance loadbalance) throws RpcException {
    try {
    	// 1.校验参数是否可用
        checkInvokers(invokers, invocation);
        // 初始化一个集合，用于保存真正要调用的Invoker列表。
        final List<Invoker<T>> selected;
        // 用户设置最大的并行数：forks
        final int forks = getUrl().getParameter(FORKS_KEY, DEFAULT_FORKS);
        final int timeout = getUrl().getParameter(TIMEOUT_KEY, DEFAULT_TIMEOUT);
        if (forks <= 0 || forks >= invokers.size()) {
            selected = invokers;
        } else {
        	// 2.获得最重要调用的Invoker列表
            selected = new ArrayList<>(forks);
            // selected.size()=实际可以调用的最大服务数，若<用户设置最大的并行数
            // 则说明可用的服务数小于用户的设置，因此最终要调用的 Invoker只能有selected.size()个
            while (selected.size() < forks) {
            	// 循环调用负载均衡方法，不断得到可调用的Invoker，加入到第一步中的Invoker列表中。
                Invoker<T> invoker = select(loadbalance, invocation, invokers, selected);
                if (!selected.contains(invoker)) {
                    //Avoid add the same invoker several times.
                    selected.add(invoker);
                }
            }
        }
        // 3.调用前的准备工作。设置要调用的Invoker列表到RPC上下文
        // 同时初始化一个异常计数器和一个阻塞队列，用于记录并行调用的结果
        RpcContext.getContext().setInvokers((List) selected);
        final AtomicInteger count = new AtomicInteger();
        final BlockingQueue<Object> ref = new LinkedBlockingQueue<>();
        // 4.执行调用。循环使用线程池并行调用，调用成功，则把结果加入阻塞队列。
        for (final Invoker<T> invoker : selected) {
            executor.execute(() -> {
                try {
                    Result result = invoker.invoke(invocation);
                    ref.offer(result);
                } catch (Throwable e) {
                	// 调用失败，则失败计数器+1
                    int value = count.incrementAndGet();
                    if (value >= selected.size()) {
                        ref.offer(e);
                    }
                }
            });
        }
        try {
        	// 5.同步等待结果，主线程中会使用阻塞队列的poll(-超时时间“)方法，同步等待阻塞队列中的第一个结果，
        	// 如果是正常结果则返回，如果是异常则抛出。
            Object ret = ref.poll(timeout, TimeUnit.MILLISECONDS);
            if (ret instanceof Throwable) {
                Throwable e = (Throwable) ret;
                throw new RpcException(...);
            }
            return (Result) ret;
        } catch (InterruptedException e) {
            throw new RpcException(...);
        }
    } finally {
        // clear attachments which is binding to current thread.
        RpcContext.getContext().clearAttachments();
    }
}

流程图如下：
在这里插入图片描述

Broadcast策略

广播调用所有可用的服务，任意一个节点报错则报错。 不做负载均衡。

代码：

@Override
@SuppressWarnings({"unchecked", "rawtypes"})
public Result doInvoke(final Invocation invocation, List<Invoker<T>> invokers, LoadBalance loadbalance) throws RpcException {
	// 1.校验参数并初始化一些对象，用于保存调用过程中产生的异常和结果信息等。
    checkInvokers(invokers, invocation);
    RpcContext.getContext().setInvokers((List) invokers);
    RpcException exception = null;
    Result result = null;
    // 2.循环遍历所有Invoker,直接做RPC调用。
    for (Invoker<T> invoker : invokers) {
        try {
            result = invoker.invoke(invocation);
        } catch (RpcException e) {
        	// 若出错，则先进行日志的打印，只有最后才会抛出异常，最终会抛出最后一个节点的异常（异常会覆盖）
            exception = e;
            logger.warn(e.getMessage(), e);
        } catch (Throwable e) {
            exception = new RpcException(e.getMessage(), e);
            logger.warn(e.getMessage(), e);
        }
    }
    if (exception != null) {
        throw exception;
    }
    return result;
}
Available策略

**遍历所有服务列表，找到第一个可用的节点， 直接请求并返回结果。**如果没有可用的节点，则直接抛出异常。不会做负载均衡。

代码（最简单的实现，即循环遍历）：

@Override
public Result doInvoke(Invocation invocation, List<Invoker<T>> invokers, LoadBalance loadbalance) throws RpcException {
    for (Invoker<T> invoker : invokers) {
        if (invoker.isAvailable()) {
            return invoker.invoke(invocation);
        }
    }
    throw new RpcException("No provider available in " + invokers);
}

二. 路由的实现

RouterFactory是一个SPI接口，没有设定默认值，来看下他的构造：

@SPI
public interface RouterFactory {
   	
    @Adaptive("protocol")
    //根据URL中的protocol参数确定要初始化哪一个具体的Router实现 
    Router getRouter(URL url);
}

其实现有：
在这里插入图片描述
本文章主要从三个实现类来进行说明：

  • ConditionRouterFactory
  • FileRouterFactory
  • ScriptRouterFactory

RouterFactory的实现类基本上都非常简单，就是直接new出一个对应的路由类并返回（除了FileRouterFactory），例如：

public class ConditionRouterFactory implements RouterFactory {

    public static final String NAME = "condition";
    @Override
    public Router getRouter(URL url) {
        return new ConditionRouter(url);
    }
}

2.1 条件路由

参数规则

条件路由使用的协议是：condition://协议，例如：

”condition://0.0.0.0/com.fbo.BarService?category=routers&dynamic=false&rule=" + URL.encode(nhost = 10.20.153.10 => host = 10.20.153.11")
参数名称含义
condition://表示路由规则的类型，支持条件路由规则和脚本路由规则， 可扩展，必填
0.0.0.0表示对所有IP地址生效，如果只想对某个IP的生效，则填入具体IP，必填
com.fdo.BarService表示只对指定服务生效，必填
category=routers表示该数据为动态配置类型，必填
dynamic=false表示该数据为持久数据，当注册方退出时，数据依然保存在注册中心，必填
enabled=true覆盖规则是否生效，可不填，默认生效
fbrce=false当路由结果为空时，是否强制执行，如果不强制执行，则路由结果为空的路由规则将自动失效，可不填，默认为false
runtime=false是否在每次调用时执行路由规则，否则只在提供者地址列表 变更时预先执行并缓存结果，调用时直接从缓存中获取路由结果。如果用了参数路由，则必须设为true。需要注意设置会影响调用的性能，可不填，默认为false
priority=l路由规则的优先级，用于排序，优先级越大越靠前执行，可不填，默认为0
URL.encode(nhost = 10.20.153.10 => host = 10.20.153.11")表示路由规则的内容，必填

案例：

method = find* => host = 192.168.237.130
  • 所有调用find开头的方法都会被路由到IP为192.168.237.130的服务节点上。
  • =>之前的部分为消费者匹配条件，将所有参数和消费者的URL进行对比，当消费者满足匹配条件时，对该消费者执行后面的过滤规则。
  • =>之后的部分为提供者地址列表的过滤条件，消费者最终只获取过滤后的地址列表。

条件路由的实现

条件路由的实现，可以从上文的ConditionRouterFactory开始，可以看到其返回一个ConditionRouter对象，来看下他的构造函数：

public class ConditionRouter extends AbstractRouter {
	public ConditionRouter(URL url) {
        this.url = url;
        this.priority = url.getParameter(PRIORITY_KEY, 0);
        this.force = url.getParameter(FORCE_KEY, false);
        this.enabled = url.getParameter(ENABLED_KEY, true);
        // 调用初始化方法
        init(url.getParameterAndDecoded(RULE_KEY));
    }

    public void init(String rule) {
        try {
            if (rule == null || rule.trim().length() == 0) {
                throw new IllegalArgumentException("Illegal route rule!");
            }
            rule = rule.replace("consumer.", "").replace("provider.", "");
            // 1.以=>为界，把规则分成两段，前面部分为whenRule,即消费者匹配条件
            // ---后面部分为thenRule，即提供者地址列表的过滤条件。
            int i = rule.indexOf("=>");
            String whenRule = i < 0 ? null : rule.substring(0, i).trim();
            String thenRule = i < 0 ? rule.trim() : rule.substring(i + 2).trim();
            // 2.分别解析两个路由规则。调用parseRule方法。通过正则表达式不断循环匹配whenRule 和thenRule字符串
            // parseRule（）方法简单地来说就是：根据key-value之间的分隔符对key-value做分类
            // 比如  A=B   A&B   A!=B   A,B  这4种，最终的参数会被封装成一个个MatchPair对象，也就是这里的value
            // MatchPair对象有两个作用：
            // 1.通配符的匹配和占位符的赋值，MatchPair对象是内部类，里面只有一个isMatch方法，用于判断是否可以匹配规则
            // 2.缓存规则，存放于Set集合中，一共有俩集合，一个存放匹配的规则，一个存放不匹配的规则。
            Map<String, MatchPair> when = StringUtils.isBlank(whenRule) || "true".equals(whenRule) ? new HashMap<String, MatchPair>() : parseRule(whenRule);
            Map<String, MatchPair> then = StringUtils.isBlank(thenRule) || "false".equals(thenRule) ? null : parseRule(thenRule);
            // NOTE: It should be determined on the business level whether the `When condition` can be empty or not.
            this.whenCondition = when;
            this.thenCondition = then;
        } catch (ParseException e) {
            throw new IllegalStateException(e.getMessage(), e);
        }
    }
}

其次，路由的主要实现肯定是看具体子类的route（）方法了，该方法的主要功能是过滤出符合路由规则的Invoker列表，即做具体的条件匹配判断：

@Override
public <T> List<Invoker<T>> route(List<Invoker<T>> invokers, URL url, Invocation invocation)
        throws RpcException {
     // 1. 各个参数的校验，比如规则是否启动？传入的Invoker列表是否为空？
    if (!enabled) {
        return invokers;
    }

    if (CollectionUtils.isEmpty(invokers)) {
        return invokers;
    }
    try {
    	 // 2.如果没有任何的whenRule匹配，即没有规则匹配。
        if (!matchWhen(url, invocation)) {
            return invokers;
        }
        List<Invoker<T>> result = new ArrayList<Invoker<T>>();
        // 3.如果whenRule有匹配的，但是thenRule为空，即没有匹配上规则的Invoker，则返回空。
        if (thenCondition == null) {
            logger.warn(...);
            return result;
        }
        for (Invoker<T> invoker : invokers) {
        	// 4.遍历Invoker列表，通过thenRule找出所有符合规则的Invoker加入集合
            if (matchThen(invoker.getUrl(), url)) {
                result.add(invoker);
            }
        }
        if (!result.isEmpty()) {
            return result;
        } else if (force) {
            logger.warn(...);
            return result;
        }
    } catch (Throwable t) {
        logger.error("Failed to execute condition router rule: " + getUrl() + ", invokers: " + invokers + ", cause: " + t.getMessage(), t);
    }
    return invokers;
}

2.2 文件路由

文件路由则是将规则写到文件中，URL中对应的key值则是文件的路径，主要功能就是将文件中的路由脚本读取出来并做解析。

其实现在工厂类本身：

public class FileRouterFactory implements RouterFactory {
	@Override
    public Router getRouter(URL url) {
        try {
            // 1.把类型为file的protocol替换为script类型,例如：
            // file:///d:/path/to/route.js?router=script ==> script:///d:/path/to/route.js?type=js&rule=<file-content>
            String protocol = url.getParameter(ROUTER_KEY, ScriptRouterFactory.NAME); 
            // 2.解析文件的后缀名，后续用于匹配的对应脚本，比如e.g., js, groovy
            String type = null; 
            String path = url.getPath();
            if (path != null) {
                int i = path.lastIndexOf('.');
                if (i > 0) {
                    type = path.substring(i + 1);
                }
            }
            // 3. 、读取文件
            String rule = IOUtils.read(new FileReader(new File(url.getAbsolutePath())));

            // FIXME: this code looks useless
            boolean runtime = url.getParameter(RUNTIME_KEY, false);
            // 4.生成路由工厂可以识别的URL，并将一些必要参数添加进去
            URL script = URLBuilder.from(url)
                    .setProtocol(protocol)
                    .addParameter(TYPE_KEY, type)
                    .addParameter(RUNTIME_KEY, runtime)
                    .addParameterAndEncoded(RULE_KEY, rule)
                    .build();
			// 再次调用路由的工厂，由于前面配置了protocol为script类型，所以这里会使用脚本路由进行解析
			// 具体方法的实现看2.3节
            return routerFactory.getRouter(script);
        } catch (IOException e) {
            throw new IllegalStateException(e.getMessage(), e);
        }
    }
}

2.3 脚本路由

public class ScriptRouter extends AbstractRouter {
	// 构造
	public ScriptRouter(URL url) {
        this.url = url;
        this.priority = url.getParameter(PRIORITY_KEY, SCRIPT_ROUTER_DEFAULT_PRIORITY);
		// 初始化脚本执行的引擎，根据脚本的类型，通过Java的ScriptEngineManager来创建不同的脚本执行器并缓存
        engine = getEngine(url);
        rule = getRule(url);
        try {
            Compilable compilable = (Compilable) engine;
            function = compilable.compile(rule);
        } catch (ScriptException e) {
            logger.error("route error, rule has been ignored. rule: " + rule +
                    ", url: " + RpcContext.getContext().getUrl(), e);
        }
    }

	private ScriptEngine getEngine(URL url) {
        String type = url.getParameter(TYPE_KEY, DEFAULT_SCRIPT_TYPE_KEY);

        return ENGINES.computeIfAbsent(type, t -> {
            ScriptEngine scriptEngine = new ScriptEngineManager().getEngineByName(type);
            if (scriptEngine == null) {
                throw new IllegalStateException("unsupported route engine type: " + type);
            }
            return scriptEngine;
        });
    }

	@Override
    public <T> List<Invoker<T>> route(List<Invoker<T>> invokers, URL url, Invocation invocation) throws RpcException {
        try {
        	// 1.构造需要传入到脚本的一些参数
            Bindings bindings = createBindings(invokers, invocation);
            if (function == null) {
                return invokers;
            }
            // 2. function.eval(bindings)执行脚本，用的是JDK脚本引擎
            return getRoutedInvokers(function.eval(bindings));
        } catch (ScriptException e) {
            logger.error("route error, rule has been ignored. rule: " + rule + ", method:" +
                    invocation.getMethodName() + ", url: " + RpcContext.getContext().getUrl(), e);
            return invokers;
        }
    }
}

三. 负载均衡的实现

大家可以回过头来看下上文中，在讲容错策略的时候，有这么一行代码：

Invoker<T> invoker = select(loadbalance, invocation, invokers, null);

这里其实就是通过负载均衡来获得一个节点，我们知道，负载均衡和LoadBalance类有关，但是这里却不是直接用的他的方法：

@SPI(RandomLoadBalance.NAME)
// 默认是按照权重设置随机概率做负载均衡，即随机负载均衡
public interface LoadBalance {
    
    @Adaptive("loadbalance")
    // 可以在URL中通过loadbalance=xx来动态指定select时的负载均衡算法
    <T> Invoker<T> select(List<Invoker<T>> invokers, URL url, Invocation invocation) throws RpcException;
}

类似路由，负载均衡也有一个抽象类来进行特性的封装和方法的实现：

  • 粘滞连接
  • 可用检测
  • 避免重复调用

官方文档：粘滞连接用于有状态服务，尽可能让客户端总是向同一提供者发起调用，除非该提供者“挂了”，再连接 另一台。
粘滞连接将自动开启延迟连接，以减少长连接数。
<dubbo:protocol name=Hdubbo" sticky=“true” />

一般来说，一个负载均衡的方法逻辑大概有4步：

  1. 检查URL中是否有配置粘滞连接，如果有则使用粘滞连接的Invoker。
  2. 通过ExtensionLoader获取负载均衡的具体实现，并通过负载均衡做节点的选择。（拓展点机制）
  3. 进行节点的重新选择（过滤不可用和已经调用过的节点，最终得到所有可用的节点）。
  4. 再次通过负载均衡选出一个节点然后返回，若找不到可用节点，则返回null。

本篇文章就讲比较常见的4种负载均衡（其他的都是后来的新特性）：

  • RandomLoadBalance：随机，按权重设置随机概率。
  • RoundRobinLoadBalance：轮询，按公约后的权重设置轮询比例。
  • LeastActiveLoadBalance：最少活跃调用数，如果活跃数相同则随机调用。
  • ConsistentHashLoadBalance（一致哈希）：一致性Hash,相同参数的请求总是发到同一提供者。

这几种跟上述的路由策略一样， 都运用到了设计模式中的模板模式，即：抽象父类AbstractLoadBalance中已经将通用的逻辑实现完成了，但是留下了一个抽象的doSelect（）方法让子类去完成。

public abstract class AbstractLoadBalance implements LoadBalance {
	@Override
    public <T> Invoker<T> select(List<Invoker<T>> invokers, URL url, Invocation invocation) {
        if (CollectionUtils.isEmpty(invokers)) {
            return null;
        }
        if (invokers.size() == 1) {
            return invokers.get(0);
        }
        return doSelect(invokers, url, invocation);
    }
    protected abstract <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation);
}

doSelect（）方法的实现子类：
在这里插入图片描述

3.1 Random负载均衡

代码如下：

@Override
protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) {
    // Invoker列表中实例的数量
    int length = invokers.size();
    // 计算总权重并判断每个Invoker的权重是否一样，初始化为true
    boolean sameWeight = true;
    int[] weights = new int[length];
    // 总权重
    int totalWeight = 0;
    // 遍历整个Invoker列表，求和总权重，并且对比每个Invoker的权重，判断所有的Invoker权重是否相同
    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);
        // 遍历所有的Invoker，选中第一个权重大于该偏移量的Invoker并返回
        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));
}

3.2 RoundRobin负载均衡

其实我们可以看出来，普通的Random算法，源码上可以发现，他要求每个节点的权重都是一样的。问题来了：如果有些节点的负载均衡能力很弱怎么办？

因此实际上我们还应该根据节点的能力来进行权重的干预。权重的轮询又分为：

  • 普通权重轮询（会造成某个节点会突然被频繁选中，导致某个节点的流量暴增）
  • 平滑权重轮询（在轮询时会穿插选择其他的节点，让整个服务器的选择过程比较均匀）
@Override
protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) {
    String key = invokers.get(0).getUrl().getServiceKey() + "." + invocation.getMethodName();
    // 1.初始化权重缓存map。以每个Invoker的URL为key。WeightedRoundRobin类作为其value
    // 同时将map保存到全局集合methodWeightMap中，其key：接口+方法名
    // WeightedRoundRobin封装了每个Invoker的权重，对象中保存了三个属性
    /**
     * protected static class WeightedRoundRobin {
     *         private int weight;// Invoker设定的权重
     * 		   // 考虑到并发场景下某个Invoker会被 同时选中，表示该节点被所有线程选中的权重总和
     *         private AtomicLong current = new AtomicLong(0);
     * 		   // 最后一次更新的时间，用于后续缓存超时的判断
     *         private long lastUpdate;
     * }
     */
    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;
    // 2.遍历所有Invoker
    for (Invoker<T> invoker : invokers) {
        String identifyString = invoker.getUrl().toIdentityString();
        int weight = getWeight(invoker, invocation);
        // 将每个Invoker的数据进行填充，存储于上述的map中（一开始为null）
        // 同时获取每个Invoker的预热权重
        WeightedRoundRobin weightedRoundRobin = map.computeIfAbsent(identifyString, k -> {
            WeightedRoundRobin wrr = new WeightedRoundRobin();
            wrr.setWeight(weight);
            return wrr;
        });
		// 如果预热权重和Invoker设置的权重不相等，则说明还在预热阶段，此时将预热权重进行替换
        if (weight != weightedRoundRobin.getWeight()) {
            weightedRoundRobin.setWeight(weight);
        }
        // 3.紧接着进行平滑轮询，每个Invoker把权重加到自己的current属性上，并更新当前的时间
        // 同时累加每个Invoker的权重到总权重中，遍历完成后选出current最大的作为最重要调用的节点
        long cur = weightedRoundRobin.increaseCurrent();
        weightedRoundRobin.setLastUpdate(now);
        if (cur > maxCurrent) {
            maxCurrent = cur;
            selectedInvoker = invoker;
            selectedWRR = weightedRoundRobin;
        }
        totalWeight += weight;
    }
    // 4.清除已经没有使用的缓存节点
    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);
}

3.3 LeastActive负载均衡

该算法会记录下每个Invoker的活跃数，每次只从活跃数最少的Invoker里选一个节点。该算法是随机算法的升级版，但是该算法需要配合ActiveLimitFilter过滤器来计算每个接口方法的活跃数（本质）。

@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;
    // 具有相同最小活动值（leastractive）的调用程序的索引
    int[] leastIndexes = new int[length];
    // 权重集合
    int[] weights = new int[length];
    // 所有最不活跃的调用程序的预热权重之和
    int totalWeight = 0;
    // 最不活跃的调用程序的权重
    int firstWeight = 0;
    // 每个最不活跃的调用程序都有相同的权重值？类似于随机算法中的那个布尔变量
    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 (leastActive == -1 || active < leastActive) {
            // 此时不管是第一次还是因为有更小的活跃数，之前的计数都要重新开始
            // 这里就是将之前的计数进行置空，因为我们只需要计算最小的活跃数
        } 
		// 当前Invoker的活跃数如果与计数相同的话，说明有n个Invoker都是最小计数
		// 那么将他们全部保存到集合中，后续就从中根据权重来选择一个节点
		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;
            }
        }
    }
    // 如果只有一个Invoker则直接返回
    if (leastCount == 1) {
        // If we got exactly one invoker having the least active value, return this invoker directly.
        return invokers.get(leastIndexes[0]);
    }
    // 如果权重不一样，则使用和Random负载均衡一样的权重算法找到一个Invoker并返回
    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);
            }
        }
    }
    // 如果权重相同，则直接随机选一个返回
    return invokers.get(leastIndexes[ThreadLocalRandom.current().nextInt(leastCount)]);
}

注：最少活跃的计数是如何知道的？

  1. 在ActiveLimitFilter中，只要进来一个请求，该方法的调用的计数就会原子性+1。
  2. 而整个Invoker的调用过程中，包含在try-catch-finally语句块中，最后的finally块中，都会将计数进行原子性的-1。那么可以通过该计数器来得到活跃数。

3.4 ConsistentHash负载均衡

ConsistentHash也就是一致哈希，可以让参数相同的请求每次都路由到相同的机器上。 可以让请求相对平均，普通的一致性Hash的示意图如下：
在这里插入图片描述

  1. 将每个服务节点散列到环形上，然后将请求的客户端散列到环上。
  2. 顺时针往前找到的第一个可用节点就是需要调用的节点。

但是这种普通的哈希有一定的局限性，也就是其散列不一定均匀，容易造成某些节点压力过大。而Dubbo框架使用了优化过的Ketama 一致性Hash，通过创建虚拟节点的方式让节点的分布更加均匀。

来看下其代码：

@Override
protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) {
	// 1.获得方法名
    String methodName = RpcUtils.getMethodName(invocation);
    // 2.以接口名+方法名作为key
    String key = invokers.get(0).getUrl().getServiceKey() + "." + methodName;
    // 3.将所有可以调用的Invoker列表进行hash
    int invokersHashCode = invokers.hashCode();
    // 4.现在Invoker列表的Hash码和之前的不一样（第三步），说明Invoker列表已经发生了变化，则重新创建Selector
    ConsistentHashSelector<T> selector = (ConsistentHashSelector<T>) selectors.get(key);
    if (selector == null || selector.identityHashCode != invokersHashCode) {
        selectors.put(key, new ConsistentHashSelector<T>(invokers, methodName, invokersHashCode));
        // 5.通过selector来获得一个调用的Invoker
        selector = (ConsistentHashSelector<T>) selectors.get(key);
    }
    return selector.select(invocation);
}

再来看下核心的ConsistentHashSelector选择器，来看下他的初始化过程（构造）：

  • 可以看出散列的环形是通过一个TreeMap来实现的。
  • 并且所有的真实、虚拟节点都会放到TreeMap中
  • 将节点的IP做MD5操作然后作为节点的唯一标识，再对标识做Hash得到TreeMap的key。
  • 最后将可以调用的节点作为TreeMap的value
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);
    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) {
    	// 得到每个节点的IP
        String address = invoker.getUrl().getAddress();
        // repiicaNumber是生成的虚拟节点数量，默认160个
        for (int i = 0; i < replicaNumber / 4; i++) {
        	// 以IP+递增数字做MD5,以此作为节点标识
            byte[] digest = Bytes.getMD5(address + i);
            for (int h = 0; h < 4; h++) {
            	// 将节点的IP做MD5操作然后作为节点的唯一标识，再对标识做Hash得到TreeMap的key。
            	// Invoker作为value
                long m = hash(digest, h);
                virtualInvokers.put(m, invoker);
            }
        }
    }
}

那么客户端在调用的时候，只需要对请求的参数做MD5即可。

  • 由于TreeMap是有序的树形结构，所以我们可以调用TreeMap的ceilingEntry（）方法。
  • 用于返回一个大于或等于当前给定key的Entry。从而达到顺时针往前找的效果。
  • 如果找不到，则使用firstEntry返回第一个节点。

到这里文章就结束了，后期准备再学习下Dubbo的扩展点机制。加油😝

dubbo系列--集群容错
田维常
11-08 259
作为一个程序员，咱们在开发的时候不仅仅是完成某个功能，更要考虑其异常情况程序如何设计，比如说：dubbo的消费端调用服务方异常的情况，要不要处理？如何处理？ dubbo提供了多种集群容错机制，默认是failover，也就是失败后重试。可以自行扩展集群容错策略，参见：dubbo官网   图中各节点关系： 这里的 Invoker 是 Provider 的一个可调用 Service 的抽象，...
Dubbo架构篇 - 集群容错
The Secret
08-11 884
本文解析Dubbo的集群容错。
Java Dubbo：（七）Dubbo 中服务的负载均衡
地球村
08-12 676
Dubbo 中服务的负载均衡1.什么是服务集群1.1 服务集群优点1.2 集群模式1.2.1 真实集群1.2.2 伪集群2.什么是负载均衡3.负载均衡解决方案分类及特征3.1 集中式负载均衡3.1.1常见的集中式负载均衡方式3.1.1.1 DNS 轮询3.1.1.2 反向代理负载均衡3.1.1.3 基于硬件的负载均衡3.2 进程内负载均衡4.Dubbo 的内置负载均衡策略4.1 Random4.2 RoundRobin4.3 LeastActive4.4 ConsistentHash5.Dubbo 负载均衡
【深入理解Dubbo原理】Dubbo源码解析-服务暴露
王小明的专栏
07-03 376
Dubbo源码解析-服务暴露 服务发布-原理 第一个发布的动作：暴露本地服务 Export dubbo service com.alibaba.dubbo.demo.DemoService to local registry, dubbo version: 2.0.0, current host: 127...
dubbo原理深入剖析
东天里的冬天
09-22 5156
一.dubbo架构 节点角色说明： Provider: 暴露服务的服务提供方。 Consumer: 调用远程服务的服务消费方。 Registry: 服务注册与发现的注册中心。 Monitor: 统计服务的调用次调和调用时间的监控中心。 Container: 服务运行容器。 调用关系说明： 0. 服务容器负责启动，加载，运行服务提供者。 1. 服务提供者
深入理解Dubbo原理系列文章导航
Zong_0915的博客
02-04 229
深入理解Dubbo原理系列文章导航 深入理解Dubbo原理系列（一）-Dubbo简介和基本使用 深入理解Dubbo原理系列（二）- Dubbo注册中心Zookeeper 深入理解Dubbo原理系列（三）- Dubbo服务暴露和消费原理
dubbo源码：dubbo集群容错机制介绍及原理
苦行僧
05-21 846
文章目录1.概要1.1 dubbo调用主流程1.2 dubbo集群配置2. 集群容错方案2.1 集群容错方案简介AvailableClusterBroadcastClusterFailbackClusterFailfastClusterFailoverCluster（默认）FailsafeClusterForkingClusterMergeableClusterRegistryAwareClust...
17. Dubbo原理解析-集群&容错之负载均衡
斩秋的专栏
12-03 8839
LoadBalance负载均衡， 负责从多个 Invokers中选出具体的一个Invoker用于本次调用，调用过程中包含了负载均衡的算法，调用失败后需要重新选择 LoadBalance接口定义 @SPI(RandomLoadBalance.NAME) public interface LoadBalance{ @Adaptive("loadbalance") Invoker sel
学习小记 -- Dubbo服务路由、负载均衡、集群容错
weixin_42029860的博客
05-18 236
这里参考某博主举的一个很好的例子： 有一个Dubbo的用户服务，在北京部署了10个，在上海部署了20个。一个杭州的服务消费方发起了一次调用，然后发生了以下的事情: 根据配置的路由规则，如果杭州发起的调用，会路由到比较近的上海的20个 Provider。（服务路由） 根据配置的随机负载均衡策略，在20个 Provider 中随机选择了一个来调用，假设随机到了第7个 Provider。（负载均衡） 结果调用第7个 Provider 失败了。 根据配置的Failover集群容错模式，
Dubbo 笔记（六） 集群容错和负载均衡
Wu_yongtao的博客
02-22 1103
Dubbo 的集群容错和负载均衡
Dubbo集群容错与负载均衡详解
这份文档深入解析了Dubbo框架在实际面试中的核心问题，对于理解Dubbo的设计思想、实现原理以及如何应对潜在问题具有重要的参考价值。掌握这些内容，可以帮助面试者展示其对分布式服务治理的理解和实践经验。
Dubbo集群容错与负载均衡策略
技术原始积累
12-14 288
一、 Dubbo集群容错策略概述当我们进行系统设计时候，不仅要考虑正常逻辑下代码该如何走，还要考虑异常情况下代码逻辑应该怎么走。当服务消费方调用服务提供方的服务出现错误时候，Dubbo ...
Dubbo 路由及负载均衡性能优化
最新发布
架构师小秘圈
12-08 70
作者：vivo 互联网中间件团队- Wang Xiaochuang本文主要介绍在vivo内部针对Dubbo路由模块及负载均衡的一些优化手段，主要是异步化+缓存，可减少在RPC调用过程中路由及负载均衡的CPU消耗，极大提升调用效率。一、概要vivo内部Java技术栈业务使用的是Apache Dubbo框架，基于开源社区2.7.x版本定制化开发。在海量微服务集群的业务实践中，我们发现Dubbo有一些性...
Dubbo-负载均衡
八角塘塘主的博客
07-06 954
一、背景 负载均衡是为了减少某台机器承载大部分流量压力，将流量平均分配至各个机器的一种分配算法，近的如Nginx. 二、dubbo的算法前提 前提是该服务有多台机器提供,有多个invoker。 权重会随着上线时间，才会慢慢和配置的权重一致。这个叫预热 三、四种算法 1、权重随机算法 ABC三台机器，配置权重50%，30%，20%。将(0,5],(5,8],(8,10]分配给这三台机器，随机生成0到10的随机数，落在哪里就调用哪台机器 2、最小活跃数加权算法 最小活跃数：有调用，活跃数+1。调用退出，活跃数-
Dubbo的负载均衡
MW
01-08 153
背景 Dubbo是一个分布式服务框架，能避免单点故障和支持服务的横向扩容。一个服务通常会部署多个实例。如何从多个服务 Provider 组成的集群中挑选出一个进行调用，就涉及到一个负载均衡的策略。 几个概念 在讨论负载均衡之前，我想先解释一下这3个概念。 负载均衡 集群容错 服务路由 这3个概念容易混淆。他们都描述了怎么从多个 Provider 中选择一个来进行调用。那他们到底有什么区别呢?下面我...
dubbo的负载均衡
liulong1010的专栏
03-29 355
LoadBalance LoadBalance 中文意思为负载均衡，它的职责是将网络请求，或者其他形式的负载“均摊”到不同的机器上。避免集群中部分服务器压力过大，而另一些服务器比较空闲的情况。通过负载均衡，可以让每台服务器获取到适合自己处理能力的负载。在为高负载服务器分流的同时，还可以避免资源浪费，一举两得。负载均衡可分为软件负载均衡和硬件负载均衡 Dubbo 需要对服务消费者的调用请求进行分配，...
Dubbo的负载均衡、协议
paul的专栏
09-06 437
http://dubbo.apache.org/zh-cn/blog/dubbo-loadbalance.html Dubbo的负载均衡 背景 Dubbo是一个分布式服务框架，能避免单点故障和支持服务的横向扩容。一个服务通常会部署多个实例。如何从多个服务 Provider 组成的集群中挑选出一个进行调用，就涉及到一个负载均衡的策略。 几个概念 在讨论负载均衡之前，我想先解释一下这3个概念。 负载均...
dubbo工作原理，集群容错，负载均衡
热门推荐
03-15 1万+
dubbo的构架，调用关系，集群容错，负载均衡
Dubbo架构分析，远程方法调用，服务注册与发现，集群容错，负载均衡，SPI机制
weixin_43251629的博客
07-20 623
单体架构 1.单体架构的话是所有的模块都放在一个项目中，部署的时候也是将整个项目部署到服务器中。 2.单体架构的优点有小项目开发快，成本低、容易部署。 3.存在的问题的是模块耦合严重，不易开发维护，沟通成本高。核心业务和边沿业务聚合在一起， 容易出问题。 垂直架构 1.根据业务把项目垂直切割成多个项目，因此这种架构称之为垂直架构。 2.这种架构的方式存在的好处有：系统拆分实现了流量分担，解决了并发问题。 方便水平扩展，负载均衡，容错率高。系统相互独立，互不影响。 3.存在的问题有：接口调用硬编码，
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Zong_0915

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值