Dubbo高可用场景

Scroll Down

Dubbo高可用场景

为了保持程序7x24小时进行运行,我们需要保证程序的稳定性和高可用性

zookeeper 宕机和dubbo直连

  • 监控中心宕机不影响使用,但是丢失部分数据
  • 数据库宕机仍然能通过缓存提供查询
  • 注册中心集群有一台宕机,自动切换
  • 注册中心全部宕机,仍能通过本地缓存通信
  • 服务提供者无状态,宕机一台,不影响其他服务
  • 服务全宕机,讲无限次重连,等待恢复

服务直连

@Reference(url="127.0.0.1:20880")

没用注册中心的情况下也能调用服务

负载均衡

Random LoadBalance

按照权值随机访问

Dubbo默认使用随机的负载均衡机制

在一个截面上碰撞的概率高,但调用量越大分布越均匀,而且按概率使用权重后也比较均匀,有利于动态调整提供者权重。

RoundRobin LoadBalance

轮询 ,可以加上权重

存在慢的提供者累积请求的问题,比如:第二台机器很慢,但没挂,当请求调到第二台时就卡在那,久而久之,所有请求都卡在调到第二台上。

LeastActive LoadBalance

最少活跃数

使慢的提供者收到更少请求,因为越慢的提供者的调用前后计数差会越大。

ConsistentHash LoadBalance

一致性哈希,相同参数的请求总是发到同一提供者

当某一台提供者挂时,原本发往该提供者的请求,基于虚拟节点,平摊到其它提供者,不会引起剧烈变动。

实验设计

在Spring boot配置好的基础上进行实验

配置三台服务提供者

使用三个服务提供者,对配置进行更改

#第一台
dubbo:
  protocol:
    name: dubbo
    port: 20880
#第二台
dubbo:
  protocol:
    name: dubbo
    port: 20881
#第三台
dubbo:
  protocol:
    name: dubbo
    port: 20882

保证端口号不一样,并且保证名称不同

对服务实现进行略微的修改

public User findUserById(String id) {
    System.out.println("调用了服务------  1");
    return UserServiceImpl.userMap.get(id);
}

以此类推,启动服务

image-20200506173803133

此时应该能看见三个应用同时注册了同一个服务

启动消费者服务,发现调用是随机的

尝试更改策略

配置负载均衡的位置有四个

  1.  配置到服务端
     <dubbo:service interface="..." loadbalance="roundrobin" />
    
  2.  配置到客户端
     <dubbo:reference interface="..." loadbalance="roundrobin" />
    
  3.  配置到服务端方法
     <dubbo:service interface="...">
         <dubbo:method name="..." loadbalance="roundrobin"/>
     </dubbo:service>
    
  4.  配置到客户端方法
     <dubbo:reference interface="...">
         <dubbo:method name="..." loadbalance="roundrobin"/>
     </dubbo:reference>
    

    我选择进行最简单的消费者端配置

    @Reference(loadbalance = "roundrobin")
    UserService userService;
    

    再次进行实验

    服务是轮流被dubbo调用的

服务降级

当服务器压力剧增的情况下,根据实际业务的情况和流量,对一些服务和页面有策略的不处理或换种简单的方式进行处理,从而释放服务器资源以保证核心交易正常运作或高效运作

Dubbo支持两种服务降级

  • 直接屏蔽服务,直接返回为null
  • 调用超时后返回为空

集群容错

Dubbo对集群容错提供了多种策略

  • Failover
  • Failfast
  • Failsafe
  • Failback
  • Forking

Failover Cluster

失败自动切换,当出现失败,重试其它服务器。通常用于读操作,但重试会带来更长延迟。可通过 retries="2" 来设置重试次数(不含第一次)。

重试次数配置如下:

<dubbo:service retries="2" />

<dubbo:reference retries="2" />

<dubbo:reference>
    <dubbo:method name="findFoo" retries="2" />
</dubbo:reference>

Failfast Cluster

快速失败,只发起一次调用,失败立即报错。通常用于非幂等的写操作,比如新增记录。

Failsafe Cluster

失败安全,出现异常时,直接忽略。通常用于写入审计日志等操作。

Failback Cluster

失败自动恢复,后台记录失败请求,定时重发。通常用于消息通知操作。

Forking Cluster

并行调用多个服务器,只要一个成功即返回。通常用于实时性要求较高的读操作,但需要浪费更多服务资源。可通过 forks="2" 来设置最大并行数。

Broadcast Cluster

广播调用所有提供者,逐个调用,任意一台报错则报错。通常用于通知所有提供者更新缓存或日志等本地资源信息。

类似于同步的效果

集群模式配置

按照以下示例在服务提供方和消费方配置集群模式

<dubbo:service cluster="failsafe" />

<dubbo:reference cluster="failsafe" />

整合hystrix进行容错

配置spring-cloud-starter-netflix-hystrix

<!-- https://mvnrepository.com/artifact/org.springframework.cloud/spring-cloud-starter-netflix-hystrix -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
    <version>2.2.2.RELEASE</version>
</dependency>

再在主启动类启用hystrix功能

@EnableHystrix

方法实现上使用注解

@HystrixCommand
public User findUserById(String id) {
    System.out.println("调用了服务------  1");
    return UserServiceImpl.userMap.get(id);
}

在消费者端也导入依赖

开启服务容错,在调用的时候时候继续加上注解

@RequestMapping("/consume")
@HystrixCommand(fallbackMethod = "hello")
public String consume()
{
    User user = userService.findUserById("1");
    return user.getUserName()+"订购了一些东西";
}

如果方法调用出错,就会调用某些方法,比如说我这里写的hello方法