当前位置：首页 > article >正文

快速理解微服务中Fegin的概念

article 2024/11/27 14:00:39

一.由来

1.在传统的架构里面，我们是通过使用RestTemplate来访问其他的服务，但是这种方式就存在了一个很大的缺陷，也就是被调用方如果发生了服务的迁移(IP和端口发生了变化)，那么调用方也需要同步的在代码里面进行修改，然后重启服务；

2.这种方法在微服务新起以后，它的弊端就被无线放大，因此这个方式就逐渐的演变，然后形成了注册中心和配置中心，虽然我们使用注册中心解决服务发送迁移等等其他的一系列问题，但是最根本的服务之间的Http访问问题还是没有解决；

3.在两个服务之间，需要发生调用，它首先需要来到注册中心，在注册中心拿到相应的服务以后，再在本地进行负载，负载之后再发起远程调用，但是在微服务里面，服务的调用是非常的频繁，比如在一个方法里面可能出现多个服务的调用，那么同一个服务之间的调用就出现了代码的冗余。(我们以为最简单的为例：比如我们通过一个代码来都注册中心里面，拉取这个注册配置，然后再本地进行负载，负载之后再通过RestTemplate进行访问，也就是说一次简单的调用就需要写三行代码，如果是多个服务，就要编写更多的代码，这样就出现了代码的冗余)

因此，基于这种场景就引入了Fegin。

二.基本概念

1.Fegin是一个声明式的Web服务客户端，它简化了使用基于HTTP的远程服务的开发；(相当于把我们上面说的三行代码进行了一个封装，当我们使用远程调用的时候，直接使用Fegin，然后Fegin的底层来帮我们实现这个调用的过程)

2.Fegin是在RestTemplate和Ribbon的基础上进一步封装，使用RestTemplate实现Http调用，使用Ribbon实现负载均衡，关系如图所示：

Feign的主要特点和功能包括：

1.声明式API：Feign允许开发者使用简单的注解来定义和描述对远程服务的访问，通过使用注解，开发者可以轻松地指定URL、HTTP方法、请求参数、请求头等信息，使得远程调用变得非常直观和易于理解。

    @FeignClient(name = "example", url = "https://api.example.com")
    public interface ExampleService {
        @GetMapping("/endpoint")
        String getEndpointData();
    }

2.集成负载均衡：Feign集成了Ribbon负载均衡器，可以自动实现客户端的负载均衡，它可以根据服务名和可用实例进行动态路由，并分发请求到不同的服务实例上，提高系统的可用性和可伸缩性；(我们不需要来处理负载均衡了，由Fegin来帮我们集成了)

3.容错机制：Feign支持集成Hystrix容错框架，可以在调用远程服务时提供容错和断路器功能(防止雪崩)，当远程服务不可用或响应时间过长时，Feign可以快速失败并返回预设的响应结果，避免对整个系统造成级联故障。

3.自定义错误处理：允许你配置自定义的错误处理策略，当远程服务返回错误时，能够进行定制化的处理：

@FeignClient(name = "user-service", configuration = CustomFeignConfiguration.class)
public interface UserClient {
    // 方法定义
}

@Configuration
public class CustomFeignConfiguration {
    @Bean
    public ErrorDecoder errorDecoder() {
        return new MyCustomErrorDecoder(); // 自定义错误解码器
    }
}

注意：

在2019年，Netflix宣布停止对Feign的维护，为了替代 Feign ，Spring Cloud 社区推出了 OpenFeign，它继承了Feign的所有功能，并增加了对Spring MVC注解的支持‌，OpenFeign目前仍在维护中，特别是在Spring Cloud Finchley及以上版本中广泛使用‌。

其实，OpenFeign 和 Feign 在使用方式上非常相似，因为 OpenFeign 是 Feign 的社区版，并且在设计上保持了与 Feign 一致的 API 和功能，换句话说，OpenFeign 基本上是对 Feign 的延续和改进，尤其是在与 Spring Cloud 集成方面，所以，二者的使用方式差异并不大。

三.为什么Fegin第一次调用耗时很长？

主要原因是由于Ribbon的懒加载机制，当第一次调用发生时，Fegin会触发Ribbon的加载过程，包括从服务注册中心获取服务列表、建立连接池等操作，这个加载过程会增加首次调用的耗时。

解决方案：

  ribbon:
    eager-load:
      enabled: true // 开启饥饿加载
        clients: service-1 // 服务名，多个以逗号隔开

可以在应用启动时预热Fegin客户端，自动触发一次无关紧要的调用，来提前加载Ribbon和其他相关组件，这个，就相当于提前进行了一次调用。

四.Fegin是怎么做负载均衡？

在Feign中，负载均衡是通过集成Ribbon来实现的。

Ribbon是Netfix开源的一个客户端负载均衡器，可以与Feign无缝集成，为Feign提供负载均衡的能力。

Ribbon在发起请求前，会从“服务中心”获取服务列表(清单)，然后按照一定的负载均衡策略去发起请求，从而实现客户端的负载均衡。

Ribbon本身也维护着“服务提供者”清单的有效性，相当于是缓存了服务清单，只有当它发现“服务提供者”不可用，才会重新从“服务中心”获取有效的“服务提供者”清单来及时更新，并不是每一次调用都会进行拉取，这种方式也提高了整个系统的性能。

五.Fegin怎么实现认证传递？

首先先我们需要知道，为什么Fegin需要实现认证传递？先了解一下微服务的完整调用链路：

1.通常用户在前端进行请求，请求就就会到达Nginx，然后Nginx就会进行转发，到达我们的Api网关层，在Api网关层就会通过一个过滤器来实现一个认证服务，然后校验通过的请求就会将相应的认证信息或者是用户信息存到请求头里面；

2.网关完成认证之后，就会将请求转发到一个具体的微服务，微服务中使用HandlenInterceptor拦截器来获取Api层传递过来的认证信息，使用过滤器和拦截器就打通了Api层和微服务层的一个认证信息的传递；

3.但是，其实大量的请求并不是直接通过网关层到达服务层，而是直接由微服务之间的调用产生，微服务都是通过了HandlenInterceptor拦截器来获取请求头里面的信息，而微服务之间的调用是通过了openFegin来进行处理的，而使用openFegin时并没有在请求头中添加相应的一个请求信息，所以被调用的微服务就没有办法直接使用拦截器获取到一个相应的认证信息，所以为了解决这个问题，就需要在openfegin调用的时候将相应的用户信息或认证信息存储到请求头里面，这样才能完成微服务之间的一个认证问题。

解决方案：

比较常见的一种做法就是使用拦截器传递认证信息，可以通过实现RequestInterceptor接口来定义拦截器，在拦截器里，把认证信息添加到请求头中，然后将其注册到Fegin的配置中。

@Configuration
public class FeignclientConfig {
    @Bean
    public RequestInterceptor requestInterceptor() {
        return new RequestInterceptor() {
            @Override
            public void apply(RequestTemplate template) {
                // 添加认证信息到请求头中
                template.header("Authorization", "Bearer " + getToken());
            }
        };
    }

    private String getToken() {
        return "token";
    }
}

查看全文

http://www.kler.cn/a/411435.html