2万字长文带你细细盘点五种负载均衡策略( 三 ) _负载均衡

可以看到，这行代码在最短响应时间、加权随机、最小活跃数负载均衡策略中都出现了，且都在最后一行。
好了，到这里最短响应时间负载均衡策略就讲完了，你再回过头去看那张流程图，会发现其实流程非常的清晰，完全可以根据代码结构画出流程图。一个是说明这个算法是真的不复杂，另一个是说明好的代码会说话。
优雅你知道 Dubbo 加入这个新的负载均衡算法提交了几个文件吗？
四个文件，其中还包含两个测试文件：

文章插图

这里就是策略模式和 SPI 的好处。对原有的负载均衡策略没有任何侵略性。只需要按照规则扩展配置文件，实现对应接口即可。
这是什么？
这就是值得学习优雅！
那我们优雅的进入下一议题。
最小活跃数负载均衡这一小节所示源码，没有特别标注的地方均为 2.6.0 版本。
为什么没有用截止目前（我当时写这段文章的时候是2019年12月01日）的最新的版本号 2.7.4.1 呢？因为 2.6.0 这个版本里面有两个 bug。从 bug 讲起来，印象更加深刻。
最后会对 2.6.0/2.6.5/2.7.4.1 版本进行对比，通过对比学习，加深印象。
我这里补充一句啊，仅仅半年的时间，版本号就从 2.7.4.1 到了 2.7.7 。其中还包含一个 2.7.5 这样的大版本。

所以还有人说 Dubbo 不够活跃？（几年前的文章现在还有人在发。）

对吧，我们不吵架，我们摆事实，聊数据嘛。
Demo 准备我看源码的习惯是先搞个 Demo 把调试环境搭起来。然后带着疑问去抽丝剥茧的 Debug，不放过在这个过程中在脑海里面一闪而过的任何疑问。
这一小节分享的是Dubbo负载均衡策略之一最小活跃数(LeastActiveLoadBalance) 。所以我先搭建一个 Dubbo 的项目，并启动三个 provider 供 consumer 调用。
三个 provider 的 loadbalance 均配置的是 leastactive 。权重分别是默认权重、200、300 。

文章插图

**默认权重是多少？**后面看源码的时候，源码会告诉你。
三个不同的服务提供者会给调用方返回自己是什么权重的服务。

文章插图

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

文章插图

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

文章插图

可以看到三个服务提供者分别在 20880、20881、20882 端口。（每个红框的最后5个数字就是端口号）。
最后，我们再看服务消费者。消费者很简单，配置consumer.xml

文章插图

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

文章插图

断点打在哪？相信很多朋友也很想看源码，但是不知道从何处下手。处于一种在源码里面"乱逛"的状态，一圈逛下来，收获并不大。
这一部分我想分享一下我是怎么去看源码。首先我会带着问题去源码里面寻找答案，即有针对性的看源码。
如果是这种框架类的，正如上面写的，我会先翻一翻官网（Dubbo 的官方文档其实写的挺好了），然后搭建一个简单的 Demo 项目，然后 Debug 跟进去看。Debug 的时候当然需要是设置断点的，那么这个断点如何设置呢？
第一个断点，当然毋庸置疑，是打在调用方法的地方，比如本文中，第一个断点是在这个地方：

文章插图

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