Spring Cloud OpenFeign

以你之姓@ 2023-10-04 08:23 30阅读 0赞

# 3.OpenFeign #

## 3.1.基本使用 ##

步骤：

Feign中已经自动集成了Ribbon负载均衡，因此我们不需要自己定义RestTemplate了

*  引入依赖
    
        
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-openfeign</artifactId>
        </dependency>
    
     *  启动类上添加注解  @EnableFeignCleints ，开启feign功能，如果又必须要，需要指定client所在的包,
    
    (程序启动后，会进行包扫描，扫描所有的@FeignCleint的注解的类，并将这些信息注入到ioc容器中 ) 
    
        @SpringCloudApplication
        @EnableFeignClients // 开启Feign功能
        public class ConsumerDemoApplication {
              
            public static void main(String[] args) {
              
                SpringApplication.run(UserConsumerDemoApplication.class, args);
            }
        }
 *  编写FeignClient的接口, 并加  @FeignCleint 注解
    
    (当接口的方法被调用，通过jdk的代理，来生成 具体的 RestTemplate，RestTemplate再生成Request, Request交给Client去处理，) 
    
        @FeignClient("user-service")
        public interface UserClient {
              
            @GetMapping("/user/{id}")
            User queryById(@PathVariable("id") Long id);
        }
 *  在消费者端使用UserClient

@RestController
      @RequestMapping("consumer")
      @Slf4j
      public class ConsumerController {
        
      
          @Autowired
          private UserClient userClient;
      
          @GetMapping("{id}")
          public User queryById(@PathVariable("id") Long id){
        
              return userClient.queryById(id);
          }
      }

## 3.2.整合Ribbon ##

实际环境中，我们往往会开启很多个user-service的集群。此时我们获取的服务列表中就会有多个，到底该访问哪一个呢？一般这种情况下我们就需要编写负载均衡算法，在多个实例列表中进行选择 。

Ribbon的配置：

*  超时时间(Fegin内置的ribbon默认设置了请求超时时长，默认是1000ms，我们可以通过手动配置来修改这个超时时长：) 
    
        ribbon:
          ReadTimeout: 200 # 读取超时时长
          ConnectTimeout: 1000 # 建立链接的超时时长
 *  重试次数(因为ribbon内部有重试机制，一旦超时，会自动重新发起请求。如果不希望重试，可以添加配置：) 
    
        ribbon:
          MaxAutoRetries: 0 # 当前服务器的重试次数
          MaxAutoRetriesNextServer: 1 # 重试多少次服务
          OkToRetryOnAllOperations: false # 是否对所有的请求方式都重试
 *  饥饿加载(因为ribbon内部有重试机制，一旦超时，会自动重新发起请求。如果不希望重试，可以添加配置：) 
    
        ribbon:
          eager-load:
            enabled: true  #开启饥饿加载
            clients: 
            - user-service   #服务端的id

## 3.3.整合Hystix ##

网关做请求路由转发，如果被调用的请求阻塞，需要通过Hystrix来做线程隔离和熔断，防止出现故障。

### 3.3.1.整合的基本步骤 ###

*  Hystix配置
    
        feign:
          hystrix:
            enabled: true # 开启Feign的熔断功能
 *  定义降级的处理函数,我们要定义一个类，实现刚才编写的UserFeignClient，作为fallback的处理类
    
        @Component
        public class UserClientFallback implements UserClient {
              
            @Override
            public User queryById(Long id) {
              
                User user = new User();
                user.setId(id);
                user.setName("用户查询出现异常！");
                return user;
            }
        }
 *  在UserFeignClient中，指定刚才编写的实现类

@FeignClient(value = "user-service", fallback = UserClientFallback.class)
    public interface UserClient {
        
    
        @GetMapping("/user/{id}")
        User queryById(@PathVariable("id") Long id);
    }

### 3.3.2.常见的一些概念 ###

*  超时时间配置
 *  雪崩问题
    
    如果说，我们需要访问的某个服务，Dependency-I发生了故障，此时，我们应用中，调用Dependency-I的服务，也会故障，造成阻塞。此时，其它业务似乎不受影响。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgxMTA1Nw_size_16_color_FFFFFF_t_70]
    
    例如微服务I发生异常，请求阻塞，用户不会得到响应，则tomcat的这个线程不会释放，于是越来越多的用户请求到来，越来越多的线程会阻塞：  
    ![\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vZ7TdMdY-1615796261981)(assets/1604375397407.png)\]][img-vZ7TdMdY-1615796261981_assets_1604375397407.png]
    
    服务器支持的线程和并发数有限，请求一直阻塞，会导致服务器资源耗尽，从而导致所有其它服务都不可用，形成雪崩效应。
    
    这就好比，一个汽车生产线，生产不同的汽车，需要使用不同的零件，如果某个零件因为种种原因无法使用，那么就会造成整台车无法装配，陷入等待零件的状态，直到零件到位，才能继续组装。 此时如果有很多个车型都需要这个零件，那么整个工厂都将陷入等待的状态，导致所有生产都陷入瘫痪。一个零件的波及范围不断扩大。
 *  服务降级、线程隔离、原理
    
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgxMTA1Nw_size_16_color_FFFFFF_t_70 1]
    
    Hystrix为每个服务调用的功能分配一个小的线程池，如果线程池已满调用将被立即拒绝，默认不采用排队.加速失败判定时间。
    
    用户的请求将不再直接访问服务，而是通过线程池中的空闲线程来访问服务，如果**线程池已满**，或者**请求超时**，则会进行降级处理：**返回给用户一个错误提示或备选结果**。
    
     服务降级虽然会导致请求失败，但是不会导致阻塞，而且最多占用该服务的线程资源，不会导致整个容器资源耗尽，把故障的影响隔离在线程池内
 *  服务熔断(Circuit Breaker)、原理

尽管隔离可以避免服务出现级联失败，但是对于访问\*\*服务I（故障服务）\*\*的 其它服务，每次处理请求都要等待 数秒直至fallback，显然是对系统资源的浪费。

因此，当Hystix判断一个依赖服务失败比例较高时，就会对其做**熔断处理**： 拦截对故障服务的请求，快速失 败，不再阻塞等待，就像电路的断路器断开了，保护电路。

熔断原理  
熔断器，也叫断路器，其英文单词为：Circuit Breaker ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgxMTA1Nw_size_16_color_FFFFFF_t_70 2]  
Hystix的熔断状态机模型：![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgxMTA1Nw_size_16_color_FFFFFF_t_70 3]  
状态机有3个状态：

*  Closed：关闭状态（断路器关闭），所有请求都正常访问。
 *  Open：打开状态（断路器打开），所有请求都会被降级。Hystix会对请求情况计数，当一定时间内失败请求百分比达到阈值，则触发熔断，断路器打开。默认失败比例的阈值是50%，请求次数最少不低于20次。
 *  Half Open：半开状态，open状态不是永久的，打开后会进入休眠时间（默认是5S）。随后断路器会自动进入半开状态。此时会释放1次请求通过，若这个请求是健康的，则会关闭断路器，否则继续保持打开，再次进行5秒休眠计时。

动手实践

为了能够精确控制请求的成功或失败，我们在consumer的调用业务中加入一段逻辑：

@GetMapping("{id}")
    @HystrixCommand
    public String queryById(@PathVariable("id") Long id){
        
        if(id == 1){
        
            throw new RuntimeException("太忙了");
        }
        String url = "http://user-service/user/" + id;
        String user = restTemplate.getForObject(url, String.class);
        return user;
    }

这样如果参数是id为1，一定失败，其它情况都成功。

我们准备两个请求窗口：

*  一个请求：http://localhost:8080/consumer/1，注定失败
 *  一个请求：http://localhost:8080/consumer/2，肯定成功

熔断器的默认触发阈值是20次请求，不好触发。休眠时间时5秒，时间太短，不易观察，为了测试方便，我们可以通过配置修改熔断策略：

hystrix:
          command:
            default:
              execution.isolation.thread.timeoutInMilliseconds: 2000
              circuitBreaker:
                errorThresholdPercentage: 50 # 触发熔断错误比例阈值，默认值50%
                sleepWindowInMilliseconds: 10000 # 熔断后休眠时长，默认值5秒
                requestVolumeThreshold: 10 # 触发熔断的最小请求次数，默认20

解读：

*  requestVolumeThreshold：触发熔断的最小请求次数，默认20，这里我们设置为10，便于触发
 *  errorThresholdPercentage：触发熔断的失败请求最小占比，默认50%
 *  sleepWindowInMilliseconds：休眠时长，默认是5000毫秒，这里设置为10，便于观察熔断现象

当我们疯狂访问id为1的请求时（10次左右），就会触发熔断。断路器会进入打开状态，一切请求都会被降级处理。

此时你访问id为2的请求，会发现返回的也是失败，而且失败时间很短，只有20毫秒左右：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgxMTA1Nw_size_16_color_FFFFFF_t_70 4]

## 3.4.日志配置 ##

通过`logging.level.xx=debug`来设置日志级别。然而这个对Fegin客户端而言不会产生效果。因为`@FeignClient`注解修改的客户端在被代理时，都会创建一个新的Fegin.Logger实例。我们需要额外指定这个日志的级别才可以。

1）设置cn.itcast包下的日志级别都为debug

logging:
      level:
        cn.itcast.consumer: debug #设置日志级别为debug

2）编写配置类，定义日志级别

@Configuration
    public class FeginConfig {
        
        @Bean
        Logger.Level feginLoggerLevel(){
        
    //        return Logger.Level.FULL;
    //        return Logger.Level.BASIC;
            return Logger.Level.HEADERS;
        }
    }

3）在FeignClient中指定配置类：

//此注解作用通过反射获取服务id，去eureka上拉去服务，负载均衡
    //fallback 降级之后的回调函数
    //configuration  log日志
    @FeignClient(value = "user-service",fallback =UserClientFallback.class,
                                        configuration = FeginConfig.class)
    public interface UserClient {
        
        @GetMapping("/user/{id}")
        User queryById(@PathVariable("id") Long id);
    }

## 3.5.[OpenFeign 基本介绍和原理了解][OpenFeign] ##

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgxMTA1Nw_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20210315162029840.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgxMTA1Nw==,size_16,color_FFFFFF,t_70
[img-vZ7TdMdY-1615796261981_assets_1604375397407.png]: https://img-blog.csdnimg.cn/20210315164753787.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgxMTA1Nw==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgxMTA1Nw_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20210315164943370.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgxMTA1Nw==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgxMTA1Nw_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/2021031517511862.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgxMTA1Nw==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgxMTA1Nw_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/20210315175152404.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgxMTA1Nw==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgxMTA1Nw_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/2021031518033430.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgxMTA1Nw==,size_16,color_FFFFFF,t_70
[OpenFeign]: https://blog.csdn.net/weixin_40364776/article/details/128695858