dubbo源码分析5-服务消费（下）

我们接着分析服务消费，上一篇文章已经分析到相关初始化等操作，我们回到代理方法那里，从代理调用接着分析、以及服务端接受的相关逻辑

JavassistProxyFactory.getProxy

public  T getProxy(Invoker invoker, Class[] interfaces) {
      return (T) Proxy.getProxy(interfaces).newInstance(new InvokerInvocationHandler(invoker));
}

首先我们来分解一下，这个invoker实际上是：MockClusterWrapper(FailoverCluster(directory))
然后通过InvokerInvocationHandler做了一层包装变成了
InvokerInvocationHandler(MockClusterWrapper(FailoverCluster(directory)))

这个方法里面，会生成一个动态代理的方法，我们通过debug可以看到动态字节码的拼接过程。它代理了当前这个接口的方法sayHello , 并且方法里面是使用handler.invoke进行调用的。
而handler又是这样一个实现：
InvokerInvocationHandler(MockClusterWrapper(FailoverCluster(directory)))

 public java.lang.String sayHello(java.lang.String arg0){
        Object[] args = new Object[1];
        args[0] = ($w)$1;
        Object ret = handler.invoke(this, methods[0], args);
        return (java.lang.String)ret;
    }

消费端调用的过程

handler的调用链路为：
InvokerInvocationHandler(MockClusterWrapper(FailoverCluster(directory)))

图解调用链

image.png

InvokerInvocationHandler.invoke

这个方法主要判断当前调用的远程方法，如果是tostring、hashcode、equals，就直接返回
否则，调用invoker.invoke,进入到MockClusterWrapper.invoke 方法

 @Override
    public Object invoke(Object proxy, Method method, Object[] args) throws
            Throwable {
        String methodName = method.getName();
        Class[] parameterTypes = method.getParameterTypes();
        if (method.getDeclaringClass() == Object.class) {
            return method.invoke(invoker, args);
        }
        if ("toString".equals(methodName) && parameterTypes.length == 0) {
            return invoker.toString();
        }
        if ("hashCode".equals(methodName) && parameterTypes.length == 0) {
            return invoker.hashCode();
        }
        if ("equals".equals(methodName) && parameterTypes.length == 1) {
            return invoker.equals(args[0]);
        }
        //createInvocation,参数为目标方法名称和目标方法的参数，看起来似乎是组装一个传输的对象
        return invoker.invoke(createInvocation(method, args)).recreate();
    }

MockClusterInvoker.invoke

Mock，在这里面有两个逻辑

1. 是否客户端强制配置了mock调用，那么在这种场景中主要可以用来解决服务端还没开发好的时候直接使用本地数据进行测试
2. 是否出现了异常，如果出现异常则使用配置好的Mock类来实现服务的降级

  /**
     * 1. mock远程通信 进行测试
     * 2. 出现异常的情况下，实现服务降级
     *
     * @param invocation
     * @return
     * @throws RpcException
     */
    @Override
    public Result invoke(Invocation invocation) throws RpcException {
        Result result = null;

        //从url中获得MOCK_KEY对应的value
        String value = directory.getUrl().getMethodParameter(invocation.getMethodName(), MOCK_KEY, Boolean.FALSE.toString()).trim();
        //如果没有配置mock，则直接传递给下个invoker调用
        if (value.length() == 0 || value.equalsIgnoreCase("false")) {
            // 不走mock操作
            result = this.invoker.invoke(invocation);
        } else if (value.startsWith("force")) { {//如果强制为本地调用，则执行mockInvoke
            if (logger.isWarnEnabled()) {
                logger.warn("force-mock: " + invocation.getMethodName() + " force-mock enabled , url : " + directory.getUrl());
            }
            //force:direct mock
            result = doMockInvoke(invocation, null);
        } else { //调用服务失败.
            //fail-mock
            try {
                result = this.invoker.invoke(invocation); //远程调用
            } catch (RpcException e) {
                if (e.isBiz()) { //业务异常，直接抛出
                    throw e;
                }
                if (logger.isWarnEnabled()) {
                    logger.warn("fail-mock: " + invocation.getMethodName() + " fail-mock enabled , url : " + directory.getUrl(), e);
                }
                //如果远程调用出现异常，则使用Mock进行处理
                result = doMockInvoke(invocation, e); //调用Mock类进行返回
            }
        }
        return result;
    }

AbstractClusterInvoker.invoke

下一个invoke，应该进入FailoverClusterInvoke，但是在这里它又用到了模版方法，所以直接进入到父类的invoke方法中

  @Override
    public Result invoke(final Invocation invocation) throws RpcException {
        checkWhetherDestroyed();

        // attachments -> 隐式传参
        //RpcContext.getContext().setAttachment("key","value");
        Map contextAttachments = RpcContext.getContext().getAttachments();
        if (contextAttachments != null && contextAttachments.size() != 0) {
            ((RpcInvocation) invocation).addAttachments(contextAttachments);
        }

        /**
         *  去哪里拿到所有的目标服务呢？（RegistryDirectory）
         *  route 路由
         *  invokers.size = 2 ->
         *
         */
        List> invokers = list(invocation);
        //invokers -> route决定了invokers返回多少的问题(tag->a(2), tag->b)
        /**
         * 通过在server端和client端都可以配置 loadbalance="random"  "roundrobin"
         *     获得url里面配置的负载均衡策略，如果没有，默认为random
         *     spi -> 通过自适应扩展点进行适配->得到真正意义上的实现
         *     容错 -> failover重试 -> 已经调用过失败的节点，如果下次重试，肯定不会再次调用。
         */
        // 初始化负载均衡的机制
        //loadbalace ->RandomLoadBalance
        LoadBalance loadbalance = initLoadBalance(invokers, invocation);
        RpcUtils.attachInvocationIdIfAsync(getUrl(), invocation);
        return doInvoke(invocation, invokers, loadbalance);
    }

• 1. 绑定attachments，Dubbo中，可以通过 RpcContext 上的 setAttachment 和 getAttachment 在
     服务消费方和提供方之间进行参数的隐式传递，所以这段代码中会去绑定attachments

RpcContext.getContext().setAttachment("index", "1")

• 2. 通过list获得invoker列表，这个列表基本可以猜测到是从directory里面获得的、但是这里面还实现了服务路由的逻辑，简单来说就是先拿到invoker列表，然后通过router进行服务路由，筛选出符合路由规则的服务提供者（暂时不细讲，属于另外一个逻辑）
• 3. initLoadBalance 初始化负载均衡机制
• 4. 执行doInvoke

initLoadBalance

不用看这个代码，基本也能猜测到，会从url中获得当前的负载均衡算法，然后使用spi机制来获得负载均衡的扩展点。然后返回一个具体的实现

  protected LoadBalance initLoadBalance(List> invokers, Invocation invocation) {
        if (CollectionUtils.isNotEmpty(invokers)) {
            return ExtensionLoader.getExtensionLoader(LoadBalance.class).getExtension(invokers.get(0).getUrl()
                    .getMethodParameter(RpcUtils.getMethodName(invocation), LOADBALANCE_KEY, DEFAULT_LOADBALANCE));
        } else {
            return ExtensionLoader.getExtensionLoader(LoadBalance.class).getExtension(DEFAULT_LOADBALANCE);
        }
    }

FailoverClusterInvoker.doInvoke

  @Override
    @SuppressWarnings({"unchecked", "rawtypes"})
    public Result doInvoke(Invocation invocation, final List> invokers, LoadBalance loadbalance) throws RpcException {
        List> copyInvokers = invokers;
        checkInvokers(copyInvokers, invocation);
        String methodName = RpcUtils.getMethodName(invocation);
        //重试次数 默认2
        int len = getUrl().getMethodParameter(methodName, RETRIES_KEY, DEFAULT_RETRIES) + 1;
        if (len <= 0) {
            len = 1;
        }
        // retry loop.
        RpcException le = null; // 异常信息
        //invoked ->表示调用过的服务（记录调用过的服务）
        List> invoked = new ArrayList>(copyInvokers.size()); // invoked invokers.
        Set providers = new HashSet(len);
        for (int i = 0; i < len; i++) {
            //Reselect before retry to avoid a change of candidate `invokers`.
            //NOTE: if `invokers` changed, then `invoked` also lose accuracy.
            if (i > 0) {
                checkWhetherDestroyed();
                copyInvokers = list(invocation);
                // check again
                checkInvokers(copyInvokers, invocation);
            }
            //select -> 通过负载均衡算法之后，得到一个真正的目标invoker
            Invoker invoker = select(loadbalance, invocation, copyInvokers, invoked);
            invoked.add(invoker);
            RpcContext.getContext().setInvokers((List) invoked);
            try {
                //invoker -> InvokerDelegate(ProtocolFilterWrapper(ListenerInvokerWrapper(DubboInvoker)
                Result result = invoker.invoke(invocation); //发起一个远程调用
                if (le != null && logger.isWarnEnabled()) {
                    logger.warn("Although retry the method " + methodName
                            + " in the service " + getInterface().getName()
                            + " was successful by the provider " + invoker.getUrl().getAddress()
                            + ", but there have been failed providers " + providers
                            + " (" + providers.size() + "/" + copyInvokers.size()
                            + ") from the registry " + directory.getUrl().getAddress()
                            + " on the consumer " + NetUtils.getLocalHost()
                            + " using the dubbo version " + Version.getVersion() + ". Last error is: "
                            + le.getMessage(), le);
                }
                return result;
            } catch (RpcException e) {
                if (e.isBiz()) { // 如果是业务异常，直接抛出不进行重试
                    throw e;
                }
                le = e; //记录异常信息，进行下一次循环
            } catch (Throwable e) {
                le = new RpcException(e.getMessage(), e);
            } finally {
                providers.add(invoker.getUrl().getAddress());
            }
        }
        throw new RpcException(le.getCode(), "Failed to invoke the method "
                + methodName + " in the service " + getInterface().getName()
                + ". Tried " + len + " times of the providers " + providers
                + " (" + providers.size() + "/" + copyInvokers.size()
                + ") from the registry " + directory.getUrl().getAddress()
                + " on the consumer " + NetUtils.getLocalHost() + " using the dubbo version "
                + Version.getVersion() + ". Last error is: "
                + le.getMessage(), le.getCause() != null ? le.getCause() : le);
    }

这段代码逻辑也很好理解，这里面应该会实现容错的逻辑
获得重试的次数，并且进行循环
获得目标服务，并且记录当前已经调用过的目标服务防止下次继续将请求发送过去
如果执行成功，则返回结果
如果出现异常，判断是否为业务异常，如果是则抛出，否则，进行下一次重试

image.png

• 这里的 Invoker 是 Provider 的一个可调用 Service 的抽象， Invoker 封装了 Provider 地址及 Service 接口信息
• Directory 代表多个 Invoker ，可以把它看成 List ，但与 List 不同的是，它的值可能是动态变化的，比如注册中心推送变更
• Cluster 将 Directory 中的多个 Invoker 伪装成一个 Invoker ，对上层透明，伪装过程包含了容错逻辑，调用失败后，重试另一个
• Router 负责从多个 Invoker 中按路由规则选出子集，比如读写分离，应用隔离等
• LoadBalance 负责从多个 Invoker 中选出具体的一个用于本次调用，选的过程包含了负载均衡算法，调用失败后，需要重选

负载均衡

select

在调用invoker.invoke之前，会需要通过select选择一个合适的服务进行调用，而这个选择的过程其实，就是负载均衡的实现
所有负载均衡实现类均继承自 AbstractLoadBalance，该类实现了 LoadBalance 接口，并封装了一些公共的逻辑。所以在分析负载均衡实现之前，先来看一下 AbstractLoadBalance 的逻辑。首先来看一下负载均衡的入口方法 select，如下：

public  Invoker select(List> 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);
    }

负载均衡的子类实现有四个，默认情况下是RandomLoadBalance

randomLoadBalance

protected  Invoker doSelect(List> invokers, URL url, Invocation invocation) {
        int length = invokers.size();
        int totalWeight = 0;
        boolean sameWeight = true;
        // 下面这个循环有两个作用，第一是计算总权重 totalWeight，
        // 第二是检测每个服务提供者的权重是否相同
        for (int i = 0; i < length; i++) {
            int weight = getWeight(invokers.get(i), invocation);
            // 累加权重
            totalWeight += weight;
            // 检测当前服务提供者的权重与上一个服务提供者的权重是否相同，
            // 不相同的话，则将 sameWeight 置为 false。
            if (sameWeight && i > 0
                    && weight != getWeight(invokers.get(i - 1), invocation)) {
                sameWeight = false;
            }
        }
        // 下面的 if 分支主要用于获取随机数，并计算随机数落在哪个区间上
        if (totalWeight > 0 && !sameWeight) {
            // 随机获取一个 [0, totalWeight) 区间内的数字
            int offset = random.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 -= getWeight(invokers.get(i), invocation);
                if (offset < 0) {
                    // 返回相应的 Invoker
                    return invokers.get(i);
                }
            }
        }
        // 如果所有服务提供者权重值相同，此时直接随机返回一个即可
        return invokers.get(ThreadLocalRandom.current().nextInt(length));
    }

通过从RegistryDirectory中获得的invoker是什么呢？这个很重要，因为它决定了接下来的调用过程。这个时候我们需要去了解这个invoker是在哪里初始化的？

可调用的Invoker初始化过程

RegistryDirectory

在RegistryDirectory中有一个成员属性，保存了服务地方地址对应的invoke信息

private volatile Map> urlInvokerMap;

toInvokers

这个invoker是动态的，基于注册中心的变化而变化的。它的初始化过程的链路是
RegistryDirectory.notify->refreshInvoker->toInvokers 下面的这段代码中

if (invoker == null) { // Not in the cache, refer again
    invoker = new InvokerDelegate<>(protocol.refer(serviceType, url), url, providerUrl);
}

是基于protocol.refer来构建的invoker，并且使用InvokerDelegate进行了委托,在dubboprotocol中，
是这样构建invoker的。返回的是一个DubboInvoker对象

 @Override
    public  Invoker refer(Class serviceType, URL url) throws RpcException {
        optimizeSerialization(url);
        // create rpc invoker.
        DubboInvoker invoker = new DubboInvoker(serviceType, url, getClients(url), invokers);
        invokers.add(invoker);
        return invoker;
    }

所以这个invoker应该是：
InvokerDelegate(ProtocolFilterWrapper(ListenerInvokerWrapper(DubboInvoker())
ProtocolFilterWrapper->这个是一个invoker的过滤链路
ListenerInvokerWrapper-> 这里面暂时没做任何的实现
所以我们可以直接看到DubboInvoker这个类里面来

DubboInvoker

AbstractInvoker.invoke

这里面也是对Invocation的attachments进行处理，把attachment加入到Invocation中
这里的attachment，实际上是目标服务的接口信息以及版本信息

DubboInvoker.doInvoker

这里面看到一个很熟悉的东西，就是ExchangeClient，这个是客户端和服务端之间的连接
然后如果当前方法有返回值，也就是isOneway=false,则执行else逻辑，然后通过异步的形式进行通信

  @Override
    protected Result doInvoke(final Invocation invocation) throws Throwable {
        RpcInvocation inv = (RpcInvocation) invocation;
        final String methodName = RpcUtils.getMethodName(invocation);
        //将目标方法以及版本好作为参数放入到Invocation中
        inv.setAttachment(PATH_KEY, getUrl().getPath());
        inv.setAttachment(VERSION_KEY, version);

        //获得客户端连接
        ExchangeClient currentClient; //初始化invoker的时候，构建的一个远程通信连接
        if (clients.length == 1) { //默认
            currentClient = clients[0];
        } else {
            //通过取模获得其中一个连接
            currentClient = clients[index.getAndIncrement() % clients.length];
        }
        try {
            //表示当前的方法是否存在返回值
            boolean isOneway = RpcUtils.isOneway(getUrl(), invocation);
            int timeout = getUrl().getMethodParameter(methodName, TIMEOUT_KEY, DEFAULT_TIMEOUT);
            if (isOneway) {//不存在返回值
                boolean isSent = getUrl().getMethodParameter(methodName, Constants.SENT_KEY, false);
                currentClient.send(inv, isSent);
                RpcContext.getContext().setFuture(null);
                return AsyncRpcResult.newDefaultAsyncResult(invocation);
            } else { //存在返回值
                //是否采用异步
                AsyncRpcResult asyncRpcResult = new AsyncRpcResult(inv);
                //timeout ->超时时间
                //currentClient -> ReferenceCountExhcangeClient(HeaderExchangeClient(HeaderExchangeChannel( ->request)
                CompletableFuture