高可用-zookeeper宕机与dubbo直连#

注册中心宕机,还可以消费dubbo暴露的服务

  • 监控中心宕机了,不影响使用,只会丢失部分数据的采集
  • 数据库宕机了,zookeeper仍然可以通过缓存查询服务提供者列表,但是不能注册新服务
  • 注册中心集群对等集群,任何一台挂掉后都会切换到另一台
  • 注册中心全部宕机,仍可一通过使用本地缓存进行通信
  • 服务提供者提供无状态的服务,任意一台宕机,都不影响使用
  • 服务提供者全部宕机后,服务消费者无法正常使用,无限次重连等待服务提供者的恢复

通过dubbo直连的方式#

绕开注册中心直连服务提供者

Copy
@Reference(url="127.0.0.1:20888") // dubbo的注解 UserService userService; public  List<UserAddress> initOrder(String userId) {     return  userService.getUserAddressList("1"); }

集群负载均衡#

同一种服务提供者存在多份时需要负载均衡策略, loadbalance

Random LoadBalance#

随机负载均衡, 按照权重设置随机概率,随机调用量越大,分布越均匀,有利于动态调整提供者的权重

例: UserService一共三台,我们根据实际的机器性能给这三个机器添加不同的权重

Copy
userService1 weight=100 userService2 weight=200 userService3 weight=300

这样这三台机器被随机调用到的比例就是1:2:3

这是Dubbo默认的负载均衡机制

Copy
@SPI("random") public interface LoadBalance {     @Adaptive({"loadbalance"})     <T> Invoker<T> select(List<Invoker<T>> var1, URL var2, Invocation var3) throws RpcException; }

RoundRobin LoadBalace#

假如同样存在三台相同的服务提供者, 不设置权重的话,消费者的会被均匀的按瞬间分发到这个三台机器上123123123...

轮询, 按照公约后的权重值,设置查询比率 , 存在慢的提供者请求累积的问题, 这种方式的访问顺序也是提前就知道的,只不过添加上了权重的之后的顺序, 原来的123123... 可能变成了 123333

LeastActive LoadBalance#

最少活跃调用数, 活跃数指的是调用前后的计时差,使慢的提供者接受更少的请求

当用户的请求会先查询服务提供者列表中,然后选择活跃数最低的,也就是上次响应时间最短的机器

ConsistentHash LoadBalance#

一致性Hash, 使相同参数的请求总是发到同一个提供者上,当某一台提供者挂掉时,原本该发送到这个服务提供者的请求会平摊到其他提供者身上,不会产生巨大的动荡

  • 缺省只对第一个参数 Hash，如果要修改，请配置 <dubbo:parameter key="hash.arguments" value="0,1" />
  • 缺省用 160 份虚拟节点，如果要修改，请配置 <dubbo:parameter key="hash.nodes" value="320" />

负载均衡的修改方式#

  • 配置文件版
Copy
服务端服务级别 <dubbo:service interface="..." loadbalance="roundrobin" />  客户端服务级别 <dubbo:reference interface="..." loadbalance="roundrobin" />  服务端方法级别 <dubbo:service interface="...">     <dubbo:method name=