SpringColud——Ribbon（负载均衡）Hystrix（熔断器）_资讯

SpringColud——Ribbon（负载均衡）Hystrix（熔断器）

创始人

2024-03-25 05:00:34

0次

1、Ribbon

1.1、什么是Ribbon（负载均衡）

1.2、创建两个user-service实例

1.3、开启负载均衡

2、Histrix（熔断器）

2.1、什么是Histrix

2.2、雪崩问题

2.3、服务降级

2.4、开启熔断

2.5、编写降级逻辑

2.6、编写降级逻辑（默认的Fallback）

2.7、超时设置

前言：请先看完我上篇文章——SpringColud——Eureka后再看此篇文章，此文衔接上文

1、Ribbon

1.1、什么是Ribbon（负载均衡）

Spring Cloud Ribbon是基于Netflix Ribbon实现的一套客户端负载均衡的工具。

简单的说，Ribbon是Netflix发布的开源项目，主要功能是提供客户端的软件负载均衡算法，将Netflix的中间层服务连接在一起。Ribbon客户端组件提供一系列完善的配置项如连接超时，重试等。简单的说，就是在配置文件中列出Load Balancer（简称LB）后面所有的机器，Ribbon会自动的帮助你基于某种规则（如简单轮询，随机连接等）去连接这些机器。我们也很容易使用Ribbon实现自定义的负载均衡算法。

1.2、创建两个user-service实例

user-service的yml文件

server:port: 8081
spring:application:name: user-servicedatasource:driver-class-name: com.mysql.jdbc.Driverurl: jdbc:mysql://localhost:3306/ssm_crud?useSSL=false&useUnicode=true&characterEncoding=utf-8username: rootpassword: xxx
mybatis:type-aliases-package: cn.itssl.pojomapper-locations: classpath:mappers/*.xml
eureka:client:service-url:defaultZone: http://127.0.0.1:8761/eurekainstance:# 更倾向使用ip地址，而不是host名prefer-ip-address: true# 续约间隔，默认30秒lease-renewal-interval-in-seconds: 5# 服务失效时间，默认90秒  服务失效时间是要比续约间隔时间大的lease-expiration-duration-in-seconds: 10

user-service2的yml文件

server:port: 8083
spring:application:name: user-servicedatasource:driver-class-name: com.mysql.jdbc.Driverurl: jdbc:mysql://localhost:3306/ssm_crud?useSSL=false&useUnicode=true&characterEncoding=utf-8username: rootpassword: ssl0528
mybatis:type-aliases-package: cn.itssl.pojomapper-locations: classpath:mappers/*.xml
eureka:client:service-url:defaultZone: http://127.0.0.1:8761/eurekainstance:# 更倾向使用ip地址，而不是host名prefer-ip-address: true# 续约间隔，默认30秒lease-renewal-interval-in-seconds: 5# 服务失效时间，默认90秒  服务失效时间是要比续约间隔时间大的lease-expiration-duration-in-seconds: 10

启动eureka服务，访问http://127.0.0.1:8761可以看到有两个user-service服务已经注册到了注册中心。

1.3、开启负载均衡

因为Eureka中已经集成了Ribbon，所以我们无需引入新的依赖。

在客户端consumer-service启动类中的RestTemplate的配置方法上添加 @LoadBalanced 注解：

@SpringCloudApplication //包含@SpringBootApplication、@EnableDiscoveryClient、@EnableCircuitBreaker
public class ConsumerApplication {public static void main(String[] args) {SpringApplication.run(ConsumerApplication.class, args);}//远程调用工具@Bean//开启负载均衡  要求客户端必须面向服务的去调用@LoadBalancedpublic RestTemplate restTemplate() {return new RestTemplate();}
}

不再手动获取ip和端口，而是直接通过服务名称调用；

@GetMapping("{id}") 
public User queryById(@PathVariable("id") Long id){String url = "http://user-service/user/" + id; User user = restTemplate.getForObject(url, User.class); return user; 
}

访问查询用户10次，会远程调用到user-service

可以看出，user1和user2的访问次数都是5次，user-service具体调用到那个，会默认轮询的原则去访问，这就是负载均衡。

如果想要其他的原则，可以改变为随机访问，修改consumer-service的yml文件，改为随机访问

user-service: ribbon: NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule

2、Histrix（熔断器）

2.1、什么是Histrix

Hystrix在英文里面的意思是豪猪，它的logo看下面的图是一头豪猪，它在微服务系统中是一款提供保护机制的组件，和eureka一样也是由netflix公司开发。官网：https://github.com/Netflflix/Hystrix/

那么Hystrix的作用是什么呢？具体要保护什么呢？

Hystrix是Netflix开源的一个延迟和容错库，用于隔离访问远程服务、第三方库，防止出现级联失败。

2.2、雪崩问题

微服务中，服务间调用关系错综复杂，一个请求，可能需要调用多个微服务接口才能实现，会形成非常复杂的调用链路：

如图，一次业务请求，需要调用A、P、H、I四个服务，这四个服务又可能调用其它服务。

如果此时，某个服务出现异常：

例如：微服务I 发生异常，请求阻塞，用户请求就不会得到响应，则tomcat的这个线程不会释放，于是越来越多的用户请求到来，越来越多的线程会阻塞：

服务器支持的线程和并发数有限，请求一直阻塞，会导致服务器资源耗尽，从而导致所有其它服务都不可用，形成雪崩效应。

这就好比，一个汽车生产线，生产不同的汽车，需要使用不同的零件，如果某个零件因为种种原因无法使用，那么就会造成整台车无法装配，陷入等待零件的状态，直到零件到位，才能继续组装。此时如果有很多个车型都需要这个零件，那么整个工厂都将陷入等待的状态，导致所有生产都陷入瘫痪。一个零件的波及范围不断扩大。

Hystrix解决雪崩问题的手段主要是服务降级，包括：

线程池隔离

把每个服务的线程分离开，这样即使有服务崩溃了，其他服务也不会受影响。
服务降级
秒杀的时候，本来是要抢茅台的，结果返回了一条提示：网络拥挤，请稍后重试！没有走抢茅台的方法，走了提示的方法！
服务熔断：

拒绝请求

2.3、服务降级

在 consumer-service消费端系统的pom.xml文件添加如下依赖：

 org.springframework.cloudspring-cloud-starter-netflix-hystrix

2.4、开启熔断

在启动类 ConsumerApplication 上添加注解：@EnableCircuitBreaker，可以使用@SpringCloudApplication，里面整合的有@EnableCircuitBreaker

@SpringCloudApplication //包含@SpringBootApplication、@EnableDiscoveryClient、@EnableCircuitBreaker
public class ConsumerApplication {public static void main(String[] args) {SpringApplication.run(ConsumerApplication.class, args);}//远程调用工具@Bean//开启负载均衡  要求客户端必须面向服务的去调用@LoadBalancedpublic RestTemplate restTemplate() {return new RestTemplate();}
}

2.5、编写降级逻辑

当目标服务的调用出现故障，我们希望快速失败，给用户一个友好提示。因此需要提前编写好失败时的降级处理逻辑，要使用HystrixCommand来完成。

@RestController
@RequestMapping("/consumer")
//服务降级
public class ConsumerController {@Autowiredprivate RestTemplate restTemplate;@GetMapping("/{id}")@HystrixCommand(fallbackMethod = "getUserException")public User getUser(@PathVariable("id") String id){if("1".equals(id)){throw new RuntimeException("网络异常！");}String url="http://user-service/user/"+id;return restTemplate.getForObject(url, User.class);}//编写降级方法  必须与保护方法保持相同的返回值类型和参数值public User getUserException(String id){User user=new User();user.setUsername("当前网络波动异常!");return user;}}

要注意；因为熔断的降级逻辑方法必须跟正常逻辑方法保证：相同的参数列表和返回值声明。

失败逻辑中返回User对象没有太大意义，一般会返回友好提示。这里只是演示方便。

@HystrixCommand(fallbackMethod = "xxx")：用来声明一个降级逻辑的方法。

2.6、编写降级逻辑（默认的Fallback）

刚才把fallback写在了某个业务方法上，如果这样的方法很多，那岂不是要写很多。所以可以把Fallback配置加在类上，实现默认fallback；

@RestController
@RequestMapping("/consumer")
@DefaultProperties(defaultFallback = "getUserException2") //默认降级 这个类中所有保护的方法，出现问题后，走的是同一个降级方法
//服务降级
public class ConsumerController {@Autowiredprivate RestTemplate restTemplate;@Autowiredprivate DiscoveryClient discoveryClient;@GetMapping("/{id}")// @HystrixCommand(fallbackMethod = "getUserException")@HystrixCommandpublic User getUser(@PathVariable("id") String id){if("1".equals(id)){throw new RuntimeException("网络异常！");}String url="http://user-service/user/"+id;return restTemplate.getForObject(url, User.class);}@GetMapping("/getUser/{id}")// @HystrixCommand(fallbackMethod = "getUserException")@HystrixCommandpublic User getUser2(@PathVariable("id") String id){if("1".equals(id)){throw new RuntimeException("获取数据异常，请重试！");}String url="http://user-service/user/"+id;return restTemplate.getForObject(url, User.class);}//编写降级方法  必须与保护方法保持相同的返回值类型和参数值public User getUserException(String id){User user=new User();user.setUsername("当前网络波动异常，请稍后重试！");return user;}//编写默认降级方法  要求必须与保护方法的返回值类型一致，参数列表不要求public User getUserException2(){User user=new User();user.setUsername("当前网络波动异常！");return user;}}

2.7、超时设置

在之前的案例中，请求在超过1秒后都会返回错误信息，这是因为Hystrix的默认超时时长为1，我们可以通过配置修改：

hystrix:command:default:execution:isolation:thread:timeoutInMilliseconds: 2500

我们在查询之前先进行休眠2秒，如果不修改超时时间的话，会走降级方法的。因为默认是不到1秒的时间，2秒已经超过了1秒

@RestController
@RequestMapping("/consumer2")
//超时时间
public class ConsumerController2 {@Autowiredprivate RestTemplate restTemplate;@Autowiredprivate DiscoveryClient discoveryClient;@GetMapping("/{id}")@HystrixCommand(fallbackMethod = "getUserException")public User getUser(@PathVariable("id") String id){try {//请求过来先休眠2秒Thread.sleep(2000);} catch (InterruptedException e) {e.printStackTrace();}String url="http://user-service/user/"+id;return restTemplate.getForObject(url, User.class);}//编写降级方法  必须与保护方法保持相同的返回值类型和参数值public User getUserException(String id){User user=new User();user.setUsername("网络拥挤请稍后重试！");return user;}}

在等待了2秒后，依然能够查询出结果