【微服务笔记（五）】之负载均衡Ribbon，熔断器Hystrix，服务熔断

亦凉 2023-10-07 15:04 141阅读 0赞

### 本文章由公号【开发小鸽】发布！欢迎关注！！！ ###

**老规矩–妹妹镇楼：**

![20200721223424816.JPG][]

### 一. 负载均衡Ribbon ###

#### （一） 概述 ####

在实际开发中，一个服务一定有多个服务地址，当我们在服务消费方通过DiscoveryClient获取服务实例信息时，获取到的是一个服务地址列表，这时就需要负载均衡算法来决定到底访问哪一个服务。

#### （二） Ribbon ####

Eureka 中已经集成了负载均衡组件：Ribbon，这是Netflix发布的负载均衡器，它有助于控制HTTP和TCP客户端的行为，Ribbon配置服务提供者地址列表后，Ribbon就可以基于某种负载均衡算法，自动的为服务消费者去请求，包括轮询，随机等算法。Ribbon默认的负载均衡算法时轮询，通过在服务消费方的配置文件中修改如下参数：\{服务名称\}.ribbon.NFLoadBalancerRuleClassName，前面是服务的名称，后面是算法的名称。

如：修改服务user-service为随机：

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

#### （三） 实现步骤 ####

1. 要实现负载均衡，首先最起码要有两个及以上的服务提供方，创建一个8079端口，一个8080端口。

2. 修改服务消费方的RestTemplate实例化方法，添加负载均衡注解@LoadBalnced

@Bean
    @LoadBalanced
    public RestTemplate restTemplate(){
        
        return new RestTemplate();
    }

3. 修改服务消费方的controller，直接使用服务名称来替代原来的url中的host+port，这样Ribbon就能够自动负载均衡到一个服务地址中。

String url = "http://user-service/user/" + id;
    return restTemplate.getForObject(url, User.class);

#### （四） 实现原理 ####

为何我们只在url中提供了服务的名称就可以实现负载均衡呢？显然是有组件根据服务名称，获取到了服务实例的ip和端口号。Spring的负载均衡自动配置类LoadBalancerAutoConfiguration.LoadBalancerInterceptorConfig会自动配置负载均衡拦截器LoadBalncertInterceptor。这个类会对RestTemplate的请求进行拦截，从Eureka中根据服务的名称获取到服务列表，最后根据负载均衡算法得到真实的服务地址信息，替换url地址。访问服务地址，并且获取服务数据。

### 二. 熔断器Hystrix ###

#### （一） 概述 ####

Hystrix是一款提供保护机制的组件，由netflix公司研发。它是一个延迟和容错库，用于隔离访问远程服务，第三方库，防止出现级联失败。

#### （二） 雪崩问题 ####

在微服务的调用过程中，一个请求可能需要调用多个微服务接口才能够实现，调用过程比较复杂。当它调用的某一个服务发生异常时，请求被阻塞了，且这个线程并不会被释放，后面请求会继续发送来一直阻塞在这里。服务器资源被耗尽，导致其他服务都不可用了，形成了雪崩效应。Hystrix解决雪崩问题的手段是服务降级，包括线程隔离和服务降级。

#### （三） 线程隔离 ####

Hystrix为每个服务调用分配了一个小的线程池，如果线程池已经满调用了就立即拒绝服务调用，如果线程池中还有空闲的线程可以访问，则通过它来访问服务。

#### （四） 服务降级 ####

当线程池已经满了，或者请求超时时，则会进行服务降级处理。所谓的服务降级指的是返回一个服务调用失败的结果，至少用户的请求不会被阻塞，更不会无休止地等待到系统崩溃。

#### （五） Hystrix实践 ####

##### 1. 引入hystrix依赖 #####

由于Hystrix是作用于服务消费方消费服务的时候，因此在服务消费方的pom.xml中添加依赖：

<dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
        <version></version>
    </dependency>

##### 2. 开启降级 #####

在服务消费者的引导类上添加注解：@EnableCircuitBreaker

注意，在微服务中，服务消费方引导类通常会引入三个注解：

@SpringBootApplication
    @EnableDiscoveryClient
    @EnableCircuitBreaker

这三个注解可以组合成一个注解：`@SpringCloudApplication`，但是本人觉得还是不要合起来写最好。

##### 3. 服务降级逻辑编写 #####

###### （1）概述 ######

当服务访问失败时，就会通过服务降级返回失败的结果，同样是在服务消费方的Controller中定义服务访问失败结果，我们需要定义一个新的方法，一个服务对应一个访问失败的方法。

###### （2）添加注解 ######

首先，要在该服务方法上面添加注解

@HystrixCommand(fallbackMethod=”queryByIdFallBack”)

其中的参数fallbackMethod代表着该服务对应的访问失败方法，值为方法的名称。

###### （3）定义访问失败的方法 ######

定义这个访问失败的方法，注意，这个方法返回的一定是String，同样的，该方法对应的服务方法的返回值也要改为String，这是重点。

@GetMapping("/{id}")
        @HystrixCommand(fallbackMethod = "queryByIdFallBack")
        public String queryBuId(@PathVariable Long id){
        
    //        String url = "http://localhost:8080/user/8";
    //
    //        //获取eureka中注册的user-service的实例
    //        List<ServiceInstance> serviceInstances = discoveryClient.getInstances("user-service");
    //        ServiceInstance serviceInstance = serviceInstances.get(0);
    //        url = "http://" + serviceInstance.getHost() + ":" + serviceInstance.getPort() + "/user/" + id;
            String url = "http://user-service/user/" + id;
            return restTemplate.getForObject(url, String.class);
        }
    
        public String queryByIdFallBack(Long id){
        
            return "Sorry, the connection has failed";
        }

注意，原来的服务方法已经将返回值从User改为了String！！！

此时，进行测试，当我们停止服务提供方的运行时，服务消费方访问会返回失败方法的返回值。

###### （4）为类设置默认的访问失败方法 ######

为每个服务方法定义一个访问失败的方法是非常麻烦的，我们可以为整个类定义一个默认的访问失败的方法，作为该类中所有的服务访问失败的默认方法。

在类上面添加注解

@DefaultProperties(defaultFallback=”defaultFallback”)

同样的，defaultFallback参数表示这是默认的访问失败方法，值为方法的名称。继而定义这个方法。

在对应的服务方法上添加注解@HystrixCommand，不过这次不用添加参数

public String defaultFallback(){
        
    	return “default fail”;
    }

我尝试着在对应的服务方法上依旧添加注解`@HystrixCommand(fallbackMethod = "queryByIdFallBack")`，这样可以为每个服务设定个性化的访问失败方法。

##### 4. 设置Hystrix访问超时时间 #####

在服务消费方中配置Hystrix访问超时时间，通过以下参数：

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

这样，超时时间就设定为了3秒，当访问服务超过3秒没有响应时，那么就会启动服务降级，调用访问失败方法。我们可以通过浏览器自带的检查来查看访问该服务耗费的时间。

### 三. 服务熔断 ###

#### （一） 熔断原理 ####

在分布式系统中应用服务熔断后，服务调用方可以自己进行判断哪些服务反应慢或者存在大量超时，可以针对这些服务进行主动熔断，防止整个系统被拖垮。Hystrix的服务熔断机制，可以实现弹性容错，当服务请求情况好转以后，可以自动重连。通过断路的方式，将后续请求直接拒绝，一段时间（默认5秒）之后尝试地允许部分请求通过，如果这些请求调用成功则回到熔断器关闭的状态，否则继续打开熔断器，拒绝请求的服务。

#### （二） Hystrix熔断状态机模型 ####

##### 1. closed #####

熔断器关闭状态，所有的需求都能够正常访问。

##### 2. open #####

熔断器打开状态，所有的服务都会被降级。Hystrix会对请求情况进行继受，当一定时间内失败请求百分比达到阈值，则触发熔断，熔断器会完全打开。默认失败比例的阈值时50%，请求次数最少不低于20次。

##### 3. Half open #####

半开状态，不是永久的。熔断器打开后会进入休眠时间（默认是5s），随后熔断器会自动进入半开状态，此时会尝试地是释放部分请求，如果这些请求都能够执行成功的话，则会关闭熔断器，否则熔断器将继续保持打开，再次进行休眠计时。

#### （三） 修改服务熔断的参数 ####

我们可以在服务消费方中修改服务熔断的参数。如下所示：

hystrix:
      command:
        default:
          cirouitBreaker:
            errorThresholdPercentage: 50  #触发熔断错误比例阈值
            sleepWindowInMilliseconds: 10000 #熔断后休眠时间
            requestVolumeThreshold: 10  #熔断触发最小请求次数

errorThresholdPercentage: 触发熔断错误比例阈值  
sleepWindowInMilliseconds: 熔断后休眠的时间  
requestVolumeThreshold: 熔断触发最小请求次数

[20200721223424816.JPG]: https://img-blog.csdnimg.cn/20200721223424816.JPG