版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/fangxinde/article/details/87437557
dubbo通过注册中心实现负载均衡，一般是服务提供者进行集群，服务消费者请求消费时，通过一定算法进行寻找对应的接口地址。
本机上模拟两个服务注册到zookeeper上，实现集群。
服务提供者1：端口号为20880
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:dubbo="http://code.alibabatech.com/schema/dubbo"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-3.0.xsd
http://code.alibabatech.com/schema/dubbo
http://code.alibabatech.com/schema/dubbo/dubbo.xsd" default-autowire="byName">
<context:annotation-config></context:annotation-config>
<context:component-scan base-package="com.gupao.vip.mic.dubbo.order"/>
<!--name:当前项目在整个分布式架构里面的唯一名称，计算依赖关系的标签 owner表示当前application是由谁维护-->
<dubbo:application name="order-provider" owner="mic"/>
<!--dubbo这个服务所要暴露的服务地址所对应的注册中心-->
<dubbo:registry protocol="zookeeper" address="192.168.70.63:2181,192.168.70.64:2181,192.168.70.65:2181,192.168.70.66:2181"/>
<!--当前服务发布所依赖的协议：webservice Thrift Hession http-->
<dubbo:protocol name="dubbo" port="20880"/>
<!--服务发布的配置，需要暴露的服务接口-->
<dubbo:service interface="com.gupao.vip.mic.dubbo.order.IOrderServices" ref="orderService" protocol="dubbo" version="1.0"/>
</beans>服务提供者1，向外暴露的接口
public interface IOrderServices {
DoOrderResponse doOrder(DoOrderRequest request);
}
服务提供者1，接口的实现类
@Service(value = "orderService")
public class OrderServiceImpl implements IOrderServices{
@Override
public DoOrderResponse doOrder(DoOrderRequest request) {
System.out.println("曾经来过："+request);
DoOrderResponse response = new DoOrderResponse();
response.setData("负载均衡");
response.setCode("20880");
response.setMemo("处理成功，服务器端口号：20880");
return response;
}
}服务提供者2：服务端口号为：20881
此服务接口方法进行延迟10s,模拟慢服务提供者。
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:dubbo="http://code.alibabatech.com/schema/dubbo"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-3.0.xsd
http://code.alibabatech.com/schema/dubbo
http://code.alibabatech.com/schema/dubbo/dubbo.xsd" default-autowire="byName">
<context:annotation-config></context:annotation-config>
<context:component-scan base-package="com.gupao.vip.mic.dubbo.order"/>
<!--name:当前项目在整个分布式架构里面的唯一名称，计算依赖关系的标签 owner表示当前application是由谁维护-->
<dubbo:application name="order-provider" owner="mic"/>
<!--dubbo这个服务所要暴露的服务地址所对应的注册中心-->
<dubbo:registry protocol="zookeeper" address="192.168.70.63:2181,192.168.70.64:2181,192.168.70.65:2181,192.168.70.66:2181"/>
<!--当前服务发布所依赖的协议-->
<dubbo:protocol name="dubbo" port="20881"/>
<!--服务发布的配置，需要暴露的服务接口-->
<dubbo:service interface="com.gupao.vip.mic.dubbo.order.IOrderServices" ref="orderService" protocol="dubbo" version="1.0"/>
</beans>服务提供者2，对外暴露的接口
public interface IOrderServices {
DoOrderResponse doOrder(DoOrderRequest request) throws InterruptedException;
}服务提供者2，接口的实现类
@Service(value = "orderService")
public class OrderServiceImpl implements IOrderServices{
@Override
public DoOrderResponse doOrder(DoOrderRequest request) throws InterruptedException {
System.out.println("曾经来过："+request);
DoOrderResponse response = new DoOrderResponse();
response.setData("负载均衡");
response.setCode("20881");
response.setMemo("处理成功,服务器端口号：20881");
Thread.sleep(10000);
return response;
}
}两个服务启动后，两个暴露的接口已经注册到注册中心。
消费端：
设置服务超时时间：timeOut=15000毫秒，大于服务提供方的延迟时间。
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:dubbo="http://code.alibabatech.com/schema/dubbo"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://code.alibabatech.com/schema/dubbo
http://code.alibabatech.com/schema/dubbo/dubbo.xsd">
<!--name:当前项目在整个分布式架构里面的唯一名称，计算依赖关系的标签 owner表示当前application是由谁维护-->
<dubbo:application name="order-user" owner="mic"/>
<!--dubbo这个服务所要暴露的服务地址所对应的注册中心-->
<dubbo:registry address="zookeeper://192.168.70.66:2181?backup=192.168.70.65:2181,192.168.70.64:2181,192.168.70.63:2181"/>
<!--生成一个远程服务的调用代理-->
<dubbo:reference id="orderService1.0"
interface="com.gupao.vip.mic.dubbo.order.IOrderServices"
protocol="dubbo"
version="1.0" timeout="15000" retries="1" actives="200">
<dubbo:method name="doOrder"/>
</dubbo:reference>
</beans>消费端生成50个线程访问服务集群，来测试dubbo配合zookeeper实现负载均衡：
public class App
{
public static void main( String[] args ) throws ExecutionException, InterruptedException {
ClassPathXmlApplicationContext context=new ClassPathXmlApplicationContext("order-consumer.xml");
DoOrderRequest request = new DoOrderRequest();
IOrderServices services= (IOrderServices)context.getBean("orderService1.0");
int j=0;
DoOrderResponse doOrderResponse=null;
ArrayList<String> codes = new ArrayList<>();
for (int i = 0; i < 50; i++) {
Thread.sleep(20);
new Thread(new Runnable() {
@Override
public void run() {
request.setName("fangxinde");
DoOrderResponse doOrderResponse = services.doOrder(request);
System.out.println(doOrderResponse);
codes.add(doOrderResponse.getCode());
}
}).start();
}
Thread.sleep(10000);
for (int i = 0; i < codes.size(); i++) {
if (codes.get(i).equals("20880")) {
j++;
}
}
System.out.println("端口号为20880的服务:"+j);
}
}控制台上选择所需的负载方式：本案例选择最小并发模式
运行结果：
调用端口号为20880的服务的个数:47
因20881端口的服务比较耗时，故基本调用20880端口的服务。
分析：在集群负载均衡时，Dubbo提供了多种均衡策略，缺省为random随机模式。
Random LoadBalance
随机，按权重设置随机概率。
在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。
RoundRobin LoadBalance
轮询，按公约后的权重设置轮询比率
存在的问题：存在慢的提供者积累请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在第二台上。
LeastActive LoadBalance
最少活跃调用数。使慢的服务提供者获取更少的请求，因为越慢的提供者的调用前后计数差越大
ConsistentHash LoadBalance
一致性Hash，相同参数的请求总是发到同一提供者。当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其他提供者，不会引起剧烈变动。