SpringCloud学习总结（六）：Zuul（API网关服务）

Zuul网关

通过前面的学习，使用Spring Cloud实现微服务的架构基本成型，大致是这样的：

我们使用Spring Cloud Netflix中的Eureka实现了服务注册中心以及服务注册与发现；而服务间通过Ribbon或Feign实现服务的消费以及均衡负载；通过Spring Cloud Config实现了应用多环境的外部化配置以及版本管理。为了使得服务集群更为健壮，使用Hystrix的融断机制来避免在微服务架构中个别服务出现异常时引起的故障蔓延。

在该架构中，我们的服务集群包含：内部服务Service A和Service B，他们都会注册与订阅服务至Eureka Server，而Open Service是一个对外的服务，通过均衡负载公开至服务调用方。我们把焦点聚集在对外服务这块，直接暴露我们的服务地址，是否有更好的实现方式呢？

这样架构需要做的一些事儿以及存在的不足：

• 破坏了服务无状态特点。
  为了保证对外服务的安全性，我们需要实现对服务访问的权限控制，而开放服务的权限控制机制将会贯穿并污染整个开放服务的业务逻辑，这会带来的最直接问题是，破坏了服务集群中REST API无状态的特点。
  从具体开发和测试的角度来说，在工作中除了要考虑实际的业务逻辑之外，还需要额外考虑对接口访问的控制处理。
• 无法直接复用既有接口。
  当我们需要对一个即有的集群内访问接口，实现外部服务访问时，我们不得不通过在原有接口上增加校验逻辑，或增加一个代理调用来实现权限控制，无法直接复用原有的接口。

为了解决上面这些问题，我们需要将权限控制这样的东西从我们的服务单元中抽离出去，而最适合这些逻辑的地方就是处于对外访问最前端的地方，我们需要一个更强大一些的均衡负载器的 服务网关。

服务网关是微服务架构中一个不可或缺的部分。通过服务网关统一向外系统提供REST API的过程中，除了具备服务路由、均衡负载功能之外，它还具备了权限控制等功能。Spring Cloud Netflix中的Zuul就担任了这样的一个角色，为微服务架构提供了前门保护的作用，同时将权限控制这些较重的非业务逻辑内容迁移到服务路由层面，使得服务集群主体能够具备更高的可复用性和可测试性。

简介

Zuul加入后的架构

Zuul快速入门

1、访问 http://start.spring.io/
2、选择构建工具 Maven Project、Java、Spring Boot 版本 2.1.3 以及一些工程基本信息，可参考下图所示：依赖选择Zuul

3、点击 Generate Project 下载项目压缩包
4、解压后，使用 Idea 导入项目，File -> New -> Model from Existing Source… -> 选择解压后的文件夹 -> OK，选择 Maven 一路 Next，OK done!
5、引导类上通过@EnableZuulProxy注解开启Zuul的功能：

@SpringBootApplication
@EnableZuulProxy
public class DemoZuulApplication {

	public static void main(String[] args) {
		SpringApplication.run(DemoZuulApplication.class, args);
	}
}

6、编写application.yml

server:
  port: 10010 #服务端口
spring:
  application:
    name: api-gateway #指定服务名

7、编写路由规则

zuul:
  routes:
    user-service:
      path: /user-service/** # 这里是映射路径
      url: http://127.0.0.1:8081 # 映射路径对应的实际url地址

我们将符合path 规则的一切请求，都代理到 url参数指定的地址
本例中，我们将 /user-service/**开头的请求，代理到http://127.0.0.1:8081

8、启动访问：http://127.0.0.1:10010/user-service/user/1，测试成功

面向服务的路由

入门案例的路由规则中，我们把路径对应的服务地址写死了！如果同一服务有多个实例的话，这样做显然就不合理了。我们应该根据服务的名称，去Eureka注册中心查找 服务对应的所有实例列表，然后进行动态路由才对！
优化：
1、添加Eureka客户端依赖：

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

2、开启Eureka客户端发现功能

@SpringBootApplication
@EnableZuulProxy
@EnableDiscoveryClient
public class DemoZuulApplication {

	public static void main(String[] args) {
		SpringApplication.run(DemoZuulApplication.class, args);
	}
}

3、添加Eureka配置，注册并获取服务信息

eureka:
  client:
    registry-fetch-interval-seconds: 5 # 获取服务列表的周期：5s
    service-url:
      defaultZone: http://127.0.0.1:10086/eureka

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

zuul:
  routes:
    user-service: # 这里是路由id，随意写
      path: /user-service/** # 这里是映射路径
      serviceId: user-service # 指定服务名称

5、再次启动，这次Zuul进行代理时，会利用Ribbon进行负载均衡访问：日志中可以看到使用了负载均衡器

简化的路由配置

在上面的配置中，我们的规则是这样的：

• zuul.routes..path = /xxx/**： 来指定映射路径。是自定义的路由名
• zuul.routes..serviceId = user-service：来指定服务名。

大多数情况下，我们的：路由名称，往往和服务名会写成一样的。因此Zuul就提供了一种简化的配置语法：zuul.routes.=

比方说上面我们关于user-service的配置可以简化为一条：省去了对服务名称的配置。

zuul:
  routes:
    user-service: /user-service/** # 这里是映射路径

默认的路由规则

在使用Zuul的过程中，上面讲述的规则已经大大的简化了配置项。但是当服务较多时，配置也是比较繁琐的。因此Zuul就指定了默认的路由规则：

• 默认情况下，一切服务的映射路径就是服务名本身。例如服务名为：user-service，则默认的映射路径就 是：/user-service/**
  也就是说，刚才的映射规则我们完全不配置也是OK的

路由前缀

我们通过zuul.prefix=/api来指定了路由的前缀，这样在发起请求时，路径就要以/api开头：

zuul:
  prefix: /api # 添加路由前缀

过滤器

Zuul作为网关的其中一个重要功能，就是实现请求的鉴权。而这个动作我们往往是通过Zuul提供的过滤器来实现的。
1、ZuulFilter
ZuulFilter是过滤器的顶级父类。在这里我们看一下其中定义的4个最重要的方法：

public abstract ZuulFilter implements IZuulFilter{

    abstract public String filterType();

    abstract public int filterOrder();
    
    boolean shouldFilter();// 来自IZuulFilter

    Object run() throws ZuulException;// IZuulFilter
}

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

2、过滤器执行生命周期

正常流程：

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

异常流程：

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

所有内置过滤器列表：

使用场景非常多：

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

自定义过滤器

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

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

    /**
     * 过滤器的执行顺序
     * @return
     */
    @Override
    public int filterOrder() {
        return 1;
    }

    /**
     * 该过滤器是否生效
     * @return
     */
    @Override
    public boolean shouldFilter() {
        return true;
    }

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

负载均衡和熔断

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

hystrix:
  command:
    execution:
      isolation:
        thread:
          timeoutInMillisecond: 6000 # 熔断超时时长：6000ms