【图文并茂】一文讲透Dubbo负载均衡之最小活跃数算法

持续输出原创文章，点击蓝字关注我吧

这是why技术的第16篇原创文章

全文共计7786字，50图，预计阅读15分钟。

本文是对于Dubbo负载均衡策略之一的最小活跃数算法的详细分析。文中所示源码，没有特别标注的地方均为2.6.0版本。

为什么没有用截止目前的最新的版本号2.7.4.1呢？因为2.6.0这个版本里面有两个bug。从bug讲起来，印象更加深刻。

最后会对2.6.0/2.6.5/2.7.4.1版本进行对比，通过对比学习，加深印象。

本文目录

第一节：Demo准备。

本小节主要是为了演示方便，搭建了一个Demo服务。Demo中启动三个服务端，负载均衡策略均是最小活跃数，权重各不相同。

第二节：断点打在哪？

本小节主要是分享我看源码的方式。以及我们看源码时断点如何设置，怎么避免在源码里面"瞎逛"。

第三节：模拟环境。

本小节主要是基于Demo的改造，模拟真实环境。在此过程中发现了问题，引申出下一小节。

第四节：active为什么是0？

本小节主要介绍了RpcStatus类中的active字段在最小活跃数算法中所承担的作用，以及其什么时候发生变化。让读者明白为什么需要在customer端配置ActiveLimitFilter拦截器。

第五节：剖析源码

本小节对于最小活跃数算法的实现类进行了逐行代码的解读，基本上在每一行代码上加入了注释。属于全文重点部分。

第六节：Bug在哪里？

逐行解读完源码后，引出了2.6.0版本最小活跃数算法的两个Bug。并通过2.6.0/2.6.5/2.7.4.1三个版本的异同点进行交叉对比，加深读者印象。

第七节：意外收获 

看官方文档的时候发现了一处小小的笔误，我对其进行了修改并被merged。主要是介绍给开源项目贡献代码的流程。

PS：前一到三节主要是分享我看源码的一点思路和技巧，如果你不感兴趣可以直接从第四节开始看起。本文的重点是第四到第六节。

另：阅读本文需要对Dubbo有一定的了解。

一.Demo准备

我看源码的习惯是先搞个Demo把调试环境搭起来。然后带着疑问去抽丝剥茧的Debug，不放过在这个过程中在脑海里面一闪而过的任何疑问。

这篇文章分享的是Dubbo负载均衡策略之一最小活跃数(LeastActiveLoadBalance)。所以我先搭建一个Dubbo的项目，并启动三个provider供consumer调用。

三个provider的loadbalance均配置的是leastactive。权重分别是默认权重、200、300。

默认权重是多少？后面看源码的时候，源码会告诉你。

三个不同的服务提供者会给调用方返回自己是什么权重的服务。

启动三个实例。(注:上面的provider.xml和DemoServiceImpl其实只有一个，每次启动的时候手动修改端口、权重即可。)

到zookeeper上检查一下，服务提供者是否正常：

可以看到三个服务提供者分别在20880、20881、20882端口。（每个红框的最后5个数字就是端口号）。

最后，我们再看服务消费者。消费者很简单，配置consumer.xml

直接调用接口并打印返回值即可。

二.断点打在哪？

相信很多朋友也很想看源码，但是不知道从何处下手。处于一种在源码里面"乱逛"的状态，一圈逛下来，收获并不大。

这一小节我想分享一下我是怎么去看源码。首先我会带着问题去源码里面寻找答案，即有针对性的看源码。

如果是这种框架类的，正如上面写的，我会先搭建一个简单的Demo项目，然后Debug跟进去看。Debug的时候当然需要是设置断点的，那么这个断点如何设置呢？

第一个断点，当然毋庸置疑，是打在调用方法的地方，比如本文中，第一个断点是在这个地方：

接下里怎么办？

你当然可以从第一个断点处，一步一步的跟进去。但是在这个过程中，你发现了吗？大多数情况你都是被源码牵着鼻子走的。本来你就只带着一个问题去看源码的，有可能你Debug了十分钟，还没找到关键的代码。也有可能你Debug了十分钟，问题从一个变成了无数个。

那么我们怎么避免被源码牵着四处乱逛呢？我们得找到一个突破口，还记得我在《很开心，在使用mybatis的过程中我踩到一个坑》这篇文章中提到的逆向排查的方法吗？这次的文章,我再次展示一下该方法。

看源码之前，我们得冷静的分析。目标要十分明确，就是想要找到Dubbo最小活跃数算法的具体实现类以及实现类的具体逻辑是什么。根据我们的provider.xml里面的：

很明显，我们知道loadbalance是关键字。所以我们拿着loadbalance全局搜索，可以看到dubbo包下面的LoadBalance。