【dubbo源码】20. 服务消费方：负载均衡

2021-07-22 本文已影响0人天还下着毛毛雨

前言

在上一章讲集群容错的时候就讲到,除了一些广播式的容错策略之外,大部分的容错策略都需要用负载均衡算法,选出一台或者n台(fock容错就需要选n台)服务主机来调用。

每一台可被调用的服务主机都以Invoker的方式以服务列表的形式被消费端持有,并与服务接口的methodName为key，存放在RegistryDirectory对象。

//缓存本地服务列表，建立method和invokers的映射关系
// Map<methodName, Invoker> cache service method to invokers mapping.
private volatile Map<String,List<Invoker<T>>> methodInvokerMap;

所谓负载均衡,在dubbo消费端发起调用时,其实就是根据调用的方法,去服务列表中methodInvokerMap获取到一个初始的invokers列表,然后用负载均衡算法,从invokers列表中挑选出合适的invoker进行后续的远程调用。

AbstractClusterInvoker.invoke()

AbstractClusterInvoker是所有的集群容错实现类,提供公共的invoke()方法,公共化了根据方法名称从服务列表中获取invokers,以及获取指定的负载均衡策略实例的功能,并利用钩子方法调用具体的集群容错子类,让子类重写doInvoker方法,自定义如何实现自己的集群容错,以及是否使用负载均衡。是一种典型的模板方法模式。

获取服务列表,以及用spi机制获取负载均衡算法类

image

服务列表就是根据方法名称从RegistryDirectory的methodInvokerMap拿的

image

获取负载均衡算法

如果url中配置了负载均衡算法,就根据配置拿,否则就是默认的random

if (invokers != null && !invokers.isEmpty()) {
    //获取负载均衡算法
    loadbalance = ExtensionLoader.getExtensionLoader(LoadBalance.class).getExtension(invokers.get(0).getUrl()
            .getMethodParameter(RpcUtils.getMethodName(invocation), Constants.LOADBALANCE_KEY, Constants.DEFAULT_LOADBALANCE));
}

ClusterInvoker实例.doInvoke()

根据负载均衡算法，选择一个服务调用

image

AbstractClusterInvoker.select()粘带连接

这里又是一个公共的方法,提供了粘带调用的功能、

如果你配置了sticky = true，表明开启粘带调用

@Reference(sticky = true)
private UserService userService;

粘滞连接用于有状态服务，尽可能让客户端总是向同一提供者发起调用，除非该提供者挂了，再连另一台

源码逻辑,如果第一次进来,上次调用的是个null,就负载均衡选择一台,然后赋值给类变量stickyInvoker,如果下次进来,上次调用的Invoker还可用,就直接调上次调用的invoker主机,否则重新负载均衡选择一台主机。

image

AbstractClusterInvoker.doSelect()重新负载均衡

这里一进来就具体的负载均衡算法选择一个invoker

image

其实这里还有个细节,就是如果你是FailoverCluster重试进来再选择invoker对象的话,会判断你是不是已经选择过了这台主机,由于重试是因为上次调用失败了才进行重试的,所以重试的这次会规避上次调用失败的那次主机,进行重新用负载均衡算法选择主机,如果再选不到就根据下标+1从invokes列表里选一台。