负载均衡
负载均衡这个概念，通俗来讲就是一个选择的问题，在集群环境中，不可能每次都让一个服务器都来处理所有的请求，当消费者调用服务时，客户端会选择，也必须选择一个服务器来进行处理，考虑各服务器的负载，来进行分压，避免单个服务器响应同一请求，容易造成服务器宕机、崩溃等问题。
Dubbo的负载均衡
主要是向外暴露的一个接口：loadBalance，位于dubbo的cluster包下，可见该接口是专门用于管理集群的，方法中也只存在一个方法：
通过select方法，从众多的Invoker（dubbo封装的类，代表客户端的调用者）选择出一个调用者，URL就是调用者发起的URL请求链接，从这个URL中可以获取很多请求的具体信息，Invocation表示的是调用的具体过程。
同时dubbo实现了一个抽象类AbstractLoadBlance，实现接口LoadBalance，而该抽象类AbstractLoadBalance的各个子类，便实现了dubbo的负载均衡策略。
在抽象类AbstractLoadBalance中，实现了接口LoadBalance的select方法：
在方法中实现了调用者的判断，如非空、单一服务，通过后调用真正的doSelect方法，从而获取服务。
而doSelect方法是一个抽象方法，意味着具体的策略均由继承该抽象类的子类来实现，该父类在select中只进行服务者的校验。
另外，在AbstractLoadBalance中，实现了getWeight方法，顾名思义，该方法用于获取服务的权重：
首先通过调用者的URL（URL为Invoker实体中的一个属性，同样由dubbo封装而成）获取基本的权重，如果权重大于0，会获取服务启动时间，再用当前的时间-启动时间就是服务到目前为止运行了多久，因此这个upTime就可以理解为服务启动时间，再获取配置的预热时间，如果启动时间小于预热时间，就会再次调用获取权重。这个预热的方法其实dubbo针对JVM做出的一个很契合的优化，因为JVM从启动到起来都运行到最佳状态是需要一点时间的，这个时间叫做warmup，而dubbo就会对这个时间进行设定，然后等到服务运行时间和warmup相等时再计算权重，这样就可以保障服务的最佳运行状态！
具体负债均衡策略
再看下这个图，dubbo实现了4种负载均衡策略，分别是：
RandomLoadBalance（随机调用）；
RoundRobinLoadBlance（轮询调用）；
LeastActiveLoadBlance（最少活跃数调用）；
ConsistentHashLoadBalance（一致性Hash算法）；
这里就只说一下dubbo的默认负载均衡策略RandomLoadBalance，也就是随机调用。
为什么说该策略是dubbo的默认策略呢。这里我们就得回到LoadBalance接口的源码上看了。
LoadBalance接口同时拥有一个@SPI的注解，该注解标注了dubbo的默认策略为RandomLoadBalance：
@SPI(RandomLoadBalance.class)
public interface LoadBalance{
//...
}
RandomLoadBalance（随机调用）
基于AbstractLoadBalance抽象类，该策略子类重写了父类的doSelect方法，在方法中，会首先遍历每个提供服务的机器，通过父类的getWeight方法，获取每个服务的权重，然后累加权重值，判断每个服务的提供者权重是否相同。
如果每个调用者的权重不相同，并且每个权重大于0，那么就会根据权重的总值生成一个随机数，再用这个随机数，根据调用者的数量每次减去调用者的权重，直到计算出当前的服务提供者随机数小于0，就选择那个提供者。
另外，如果每个机器的权重的都相同，那么权重就不会参与计算，直接选择随机算法生成的某一个选择，完全随机。源码：
如果说在业务场景中，不希望使用该策略，也可以通过注解@Reference来指定使用dubbo的哪一个负载均衡策略：
@Reference(loadbalance="roundrobin")
其中“roundrobin”为实现子类中的常量NAME，便可以指定使用策略RoundRobinLoadBlance（轮询调用）。
基于篇幅就不再一一介绍另外几个策略，有兴趣的可以看dubbo源码，一起进步~
閱讀更多 居家程序員 的文章
