服务端
配置文件
server.port=8081
spring.application.name=DemoProvider
dubbo.scan.base-packages=com.db.service #扫描提供的服务
dubbo.protocol.name=dubbo #协议名称
dubbo.protocol.port=666 #服务提供的端口
dubbo.protocol.host=192.168.101.106 #服务提供的地址
dubbo.registry.address=zookeeper://192.168.150.13:2181 #注册中心地址
#在配置文件中配置负载均衡，也可以在服务端或者消费端方法中设置负载均衡策略
dubbo.reference.loadbalance=roundrobin
服务提供的接口
public interface DemoService {
String sayHello(String name);
}
服务接口实现
//要带版本号，消费者会带着版本号来访问服务
//Service要使用dubbo的，loadbalance负载均衡策略，，默认使用随机策略
@Service(version = "1.0.0" ,timeout = 10000, interfaceClass = DemoService.class,loadbalance = "random")
@Component
public class DemoServiceImpl implements DemoService {
@Override
public String sayHello(String name) {
System.out.println("来啦~~~！");
return "hello:" + name;
}
}
客户端
配置文件
spring.application.name=DemoCustomer
dubbo.scan.base-packages=com.db.service #扫描服务调用
dubbo.registry.address=zookeeper://192.168.150.13:2181 #注册中心地址，用于获取服务列表
调用的服务接口，然后使用@Reference(version = "1.0.0")注入进来，进行服务调用，版本号要跟服务提供者的版本号对应上
public interface DemoService {
String sayHello(String name);
}
服务调用
//复杂均衡策略也可以在消费端
//集群容错策略，在消费端设置
@Reference(version = "1.0.0",loadbalance = "random",cluster = "failfast")
DemoService demoService ;
@RequestMapping("aaa")
public String aaa(@RequestParam(defaultValue = "1") int pageNum,Model model) {
//服务调用其实是拦截器，当Invoker的时候，进行拦截，根据服务列表进行匹配，然后进行封装数据包进行调用，返回结果，跟fengi差不多，都是对请求的控制器，方法，参数的获取，然后根据相应的规则匹配服务列表中的服务，然后根据服务列表中的Ip与port进行调用
return demoService.sayHello("小明")；
}
（1）dubbo负载均衡策略
1）random loadbalance
默认情况下，dubbo是random load balance随机调用实现负载均衡，可以对provider不同实例设置不同的权重，会按照权重来负载均衡，权重越大分配流量越高，一般就用这个默认的就可以了。
2）roundrobin loadbalance
还有roundrobin loadbalance，这个的话默认就是均匀地将流量打到各个机器上去，但是如果各个机器的性能不一样，容易导致性能差的机器负载过高。所以此时需要调整权重，让性能差的机器承载权重小一些，流量少一些。
跟运维同学申请机器，有的时候，我们运气，正好公司资源比较充足，刚刚有一批热气腾腾，刚刚做好的一批虚拟机新鲜出炉，配置都比较高。8核+16g，机器，2台。过了一段时间，我感觉2台机器有点不太够，我去找运维同学，哥儿们，你能不能再给我1台机器，4核+8G的机器。我还是得要。
3）leastactive loadbalance
这个就是自动感知一下，如果某个机器性能越差，那么接收的请求越少，越不活跃，此时就会给不活跃的性能差的机器更少的请求
4）consistanthash loadbalance
一致性Hash算法，相同参数的请求一定分发到一个provider上去，provider挂掉的时候，会基于虚拟节点均匀分配剩余的流量，抖动不会太大。如果你需要的不是随机负载均衡，是要一类请求都到一个节点，那就走这个一致性hash策略。
（2）dubbo集群容错策略
1）failover cluster模式
失败自动切换，自动重试其他机器，默认就是这个，常见于读操作
- failfast cluster模式
一次调用失败就立即失败，常见于写操作
3）failsafe cluster模式
出现异常时忽略掉，常用于不重要的接口调用，比如记录日志
4）failbackc cluster模式
失败了后台自动记录请求，然后定时重发，比较适合于写消息队列这种
5）forking cluster
并行调用多个provider，只要一个成功就立即返回
6）broadcacst cluster
逐个调用所有的provider
