SpringColud——Feign（服务调用）& 网关（Zuul）

1、Feign

1.1、导入依赖

1.2、开启Feign功能

在前面的学习中，我们使用了Ribbon的负载均衡功能，大大简化了远程调用时的代码（面向服务名）

String user = this.restTemplate.getForObject("http://service-provider/user/" + id, String.class);

有没有更优雅的方式，来对这些代码再次优化呢？

这就是我们接下来要学的Feign的功能了。

1、Feign

Feign可以把Rest的请求进行隐藏，伪装成类似SpringMVC的Controller一样。你不用再自己拼接url，拼接参数等等操作，一切都交给Feign去做。

1.1、导入依赖

改造consumer-service工程

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>

1.2、开启Feign功能

我们在启动类上，添加注解，开启Feign功能

@SpringCloudApplication //包含@SpringBootApplication、@EnableDiscoveryClient、@EnableCircuitBreaker
@EnableFeignClients //开启feign客户端
public class ConsumerApplication {
    public static void main(String[] args) {
        SpringApplication.run(ConsumerApplication.class, args);
    }
}

删除RestTemplate：feign已经自动集成了Ribbon负载均衡的RestTemplate。所以，此处不需要再注册RestTemplate。

1.3、Feign客户端

创建一个包，创建一个接口

@Component
@FeignClient(value = "user-service") //集成了ribbon，直接面向服务去调用
public interface UserClient {
    @GetMapping("/user/{id}")
    //参数里的注解不能省，省略则报错
    User getUser(@PathVariable("id") String id);
}

首先这是一个接口，Feign会通过动态代理，帮我们生成实现类。这点跟mybatis的mapper很像
@FeignClient，声明这是一个Feign客户端，类似@Mapper注解。同时通过value属性指定服务名称
接口中的定义方法，完全采用SpringMVC的注解，Feign会根据注解帮我们生成URL，并访问获取结果

1.4、Controller类

@RestController
@RequestMapping("/consumer2")
public class ConsumerController2 {
    @Autowired
    private UserClient userClient;

    @GetMapping("/{id}")
    public User getUser(@PathVariable("id") String id) {
        return userClient.getUser(id);
    }
}

正常获取到了结果。

1.5、负载均衡

Feign中本身已经集成了Ribbon依赖和自动配置：

因此我们不需要额外引入依赖，也不需要再注册RestTemplate对象。

1.6、Hystrix支持

Feign默认也有对Hystrix的集成：

只不过，默认情况下是关闭的。我们需要通过下面的参数来开启：(在工程添加配置内容)

feign:
  hystrix:
    enabled: true # 开启Feign的熔断功能

但是，Feign中的Fallback配置不像hystrix中那样简单了。

首先，我们要定义一个类UserClientFallback，实现刚才编写的UserClient，作为fallback的处理类

@Component
public class UserClientImpl implements UserClient {
    @Override
    public User getUser(String id) {
        User user=new User();
        user.setUsername("网络拥挤，请稍后再试！");
        return  user;
    }
}

然后在UserFeignClient中，指定刚才编写的实现类

@RestController
@RequestMapping("/consumer2")
//内置hystrix降级服务
public class ConsumerController2 {
    @Autowired
    private UserClient userClient;

    @GetMapping("/{id}")
    @HystrixCommand //使用feign内置的hystrix
    public User getUser(@PathVariable("id") String id) {
        //如果在本地服务器中报错，内置hystrix的降级服务不会执行
        if("1".equals(id)){
            throw new RuntimeException("服务崩溃了！");
        }
        return userClient.getUser(id);
    }
    //内置hystrix不用在这里写降级方法，需要实现接口，在实现类里书写
}

需要注意的是：在feign接口中定义降级类，要触发服务降级，必须是服务提供方发生异常方可。

去除客户端自定义报错

@RestController
@RequestMapping("/consumer2")
//内置hystrix降级服务
public class ConsumerController2 {
    @Autowired
    private UserClient userClient;

    @GetMapping("/{id}")
    @HystrixCommand //使用feign内置的hystrix
    public User getUser(@PathVariable("id") String id) {
        //如果在本地服务器中报错，内置hystrix的降级服务不会执行
        return userClient.getUser(id);
    }
    //内置hystrix不用在这里写降级方法，需要实现接口，在实现类里书写
}

在提供服务端进行报错

服务降级成功

1.7、请求压缩

Spring Cloud Feign 支持对请求和响应进行GZIP压缩，以减少通信过程中的性能损耗。通过下面的参数即可开启请求与响应的压缩功能

feign:
  compression:
    request:
      enabled: true # 开启请求压缩
      min-request-size: 2048 # 设置触发压缩的大小下限
    response:
      enabled: true # 开启响应压缩

同时，我们也可以对请求的数据类型，以及触发压缩的大小下限进行设置：

feign:
  compression:
    request:
      enabled: true # 开启请求压缩
      mime-types: text/html,application/xml,application/json # 设置压缩的数据类型
      min-request-size: 2048 # 设置触发压缩的大小下限

1.8、日志级别

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

logging:
  level:
    cn.itssl: debug

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

@Configuration
public class FeignLogConfiguration {

    @Bean
    Logger.Level feignLoggerLevel(){
        return Logger.Level.FULL;
    }
}

这里指定的Level级别是FULL，Feign支持4种级别：

NONE：不记录任何日志信息，这是默认值。
BASIC：仅记录请求的方法，URL以及响应状态码和执行时间
HEADERS：在BASIC的基础上，额外记录了请求和响应的头信息
FULL：记录所有请求和响应的明细，包括头信息、请求体、元数据。

在FeignClient中指定配置类：

@Component
@FeignClient(value = "user-service",fallback = UserClientImpl.class,configuration = FeignLogConfiguration.class) //集成了ribbon，直接面向服务去调用
public interface UserClient {
    @GetMapping("/user/{id}")
    //参数里的注解不能省，省略则报错
    User getUser(@PathVariable("id") String id);
}

2、Zuul (网关)

2.1、Zuul介绍

2.2、Zuul框架

不管是来自于客户端（PC或移动端）的请求，还是服务内部调用。一切对服务的请求都会经过Zuul这个网关，然后再由网关来实现鉴权、动态路由等等操作。Zuul就是我们服务的统一入口。

2.3、创建工程

创建一个工程

添加Zuul依赖：

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

server:
  port: 8085
spring:
  application:
    name: zuul-service
zuul:
  routes:
    consumer-api: # 这里是路由id，随意写
      path: /consumerApi/** # 这里是映射路径
      #url: http://127.0.0.1:8081 # 映射路径对应的实际url地址
      serviceId: consumer-service
    user-api:
      path: /userApi/**
      serviceId: user-service

2.4、启动类

@SpringBootApplication
@EnableZuulProxy //开启网关功能
public class ZuulApplication {
    public static void main(String[] args) {
        SpringApplication.run(ZuulApplication.class,args);
    }
}

2.5、启动测试

可以看到，访问8085端口的zuul服务，访问到了8084端口的consumer服务，调用了8762的生产者服务。

在刚才的路由规则中，我们把路径对应的服务地址写死了！如果同一服务有多个实例的话，这样做显然就不合理了。我们应该根据服务的名称，去Eureka注册中心查找服务对应的所有实例列表，然后进行动态路由才对！

2.6、添加Eureka客户端依赖

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

eureka:
  client:
    registry-fetch-interval-seconds: 5 #获取服务列表的周期5秒
    service-url:
      defaultZone: http://127.0.0.1:8761/eureka,http://127.0.0.1:8762/eureka,http://127.0.0.1:8763/eureka

@SpringBootApplication
@EnableZuulProxy //开启网关功能
@EnableDiscoveryClient //开启eureka
public class ZuulApplication {
    public static void main(String[] args) {
        SpringApplication.run(ZuulApplication.class,args);
    }
}

修改映射配置，通过服务名称获取

因为已经有了Eureka客户端，我们可以从Eureka获取服务的地址信息，因此映射时无需指定IP地址，而是通过服务名称来访问，而且Zuul已经集成了Ribbon的负载均衡功能。

zuul:
  routes:
    consumer-service: /consumerApi/**
    user-service: /userApi/**

再次启动，这次Zuul进行代理时，会利用Ribbon进行负载均衡访问

2.7、路由前缀

zuul:
  routes:
    consumer-service: /consumerApi/**
    user-service: /userApi/**
  prefix: /api #路由前缀

2.8、过滤器

Zuul作为网关的其中一个重要功能，就是实现请求的鉴权。而这个动作我们往往是通过Zuul提供的过滤器来实现的。

ZuulFilter是过滤器的顶级父类。在这里我们看一下其中定义的4个最重要的方法：

shouldFilter：返回一个Boolean值，判断该过滤器是否需要执行。返回true执行，返回false不执行。
run：过滤器的具体业务逻辑。
filterType：返回字符串，代表过滤器的类型。包含以下4种：
- pre：请求在被路由之前执行
- route：在路由请求时调用
- post：在route和errror过滤器之后调用
- error：处理请求时发生错误调用
filterOrder：通过返回的int值来定义过滤器的执行顺序，数字越小优先级越高。

过滤器的生命周期

正常流程：

请求到达首先会经过pre类型过滤器，而后到达route类型，进行路由，请求就到达真正的服务提供者，执行请求，返回结果后，会到达post过滤器。而后返回响应。

异常流程：

整个过程中，pre或者route过滤器出现异常，都会直接进入error过滤器，在error处理完毕后，会将请求交给POST过滤器，最后返回给用户。
如果是error过滤器自己出现异常，最终也会进入POST过滤器，将最终结果返回给请求客户端。
如果是POST过滤器出现异常，会跳转到error过滤器，但是与pre和route不同的是，请求不会再到达POST过滤器了。

所有内置过滤器列表：

使用场景

请求鉴权：一般放在pre类型，如果发现没有访问权限，直接就拦截了
异常处理：一般会在error类型和post类型过滤器中结合来处理。
服务调用时长统计：pre和post结合使用。

2.9、自定义过滤器

接下来我们来自定义一个过滤器，模拟一个登录的校验。基本逻辑：如果请求中有access-token参数，则认为请求有效，放行。

@Component
public class LoginFilter extends ZuulFilter {
    //过滤器的类型
    @Override
    public String filterType() {
        return "pre";
    }

    //过滤器的执行顺序
    @Override
    public int filterOrder() {
        return 1;
    }
    //该过滤器是否生效
    @Override
    public boolean shouldFilter() {
        return true;
    }

    //登录效验逻辑
    @Override
    public Object run() throws ZuulException {
        //获取Zuul提供的上下文对象
        RequestContext requestContext = RequestContext.getCurrentContext();
        // 从上下文对象中获取请求对象
        HttpServletRequest request = requestContext.getRequest();
        // 获取token信息
        String token = request.getParameter("token");
        //判断
        if(StringUtils.isEmpty(token)){
            // 过滤该请求，不对其进行路由
            requestContext.setSendZuulResponse(false);
            // 设置响应状态码，401
            requestContext.setResponseStatusCode(HttpStatus.SC_UNAUTHORIZED);
            // 设置响应信息
            requestContext.setResponseBody("{\"status\":\"401\", \"text\":\"request error!\"}");
        }
        // 校验通过，把登陆信息放入上下文信息，继续向后执行
        requestContext.set("token", token);
        return null;
    }

}

当我们不加参数访问，会出现401错误

只有携带了token参数，才能正常访问到数据

2.10、负载均衡和熔断

Zuul中默认就已经集成了Ribbon负载均衡和Hystix熔断机制。但是所有的超时策略都是走的默认值，比如熔断超时时间只有1S，很容易就触发了。因此建议我们手动进行配置：

hystrix:
  command:
    default:
      execution:
        isolation:
          thread:
            timeoutInMilliseconds: 6000 # 设置hystrix的超时时间为6000ms