前言

       介绍完分布式配置中心，结合前面的文章。我们已经有了一个微服务的框架了，可以对外提供api接口服务了。但现在试想一下，在微服务框架中，每个对外服务都是独立部署的，对外的api或者服务地址都不是不尽相同的。对于内部而言，很简单，通过注册中心自动感知即可。但我们大部分情况下，服务都是提供给外部系统进行调用的，不可能同享一个注册中心。同时一般上内部的微服务都是在内网的，和外界是不连通的。而且，就算我们每个微服务对外开放，对于调用者而言，调用不同的服务的地址或者参数也是不尽相同的，这样就会造成消费者客户端的复杂性，同时想想，可能微服务可能是不同的技术栈实现的，有的是http、rpc或者websocket等等，也会进一步加大客户端的调用难度。所以，一般上都有会有个api网关，根据请求的url不同，路由到不同的服务上去，同时入口统一了，还能进行统一的身份鉴权、日志记录、分流等操作。接下来，我们就来了解今天要讲解的路由服务：zuul。

为什么要使用微服务网关

        简单来说，微服务网关是微服务架构中一个不可或缺的部分。通过服务网关统一向外系统提供REST API的过程中，除了具备服务路由、均衡负载功能之外，它还具备了权限控制等功能。

在未加入网关时，一般上会在服务外网架设一个负载均衡，如nginx等。此时，微服务的组成为：

        此时，对于Open Service而言可能需要提供权限控制等和业务无关的能力，这样本身就破坏了微服务服务单一的原则。所以，一般上在Open Service之上，还有一层服务提供诸如通用的权限校验、参数校验等功能，此服务就是网关了。之后，对于内部微服务而言，只需要关系各自微服务提供的业务功能即可，无需去关心其他非业务相关的功能。

API网关是什么

API网关可以提供一个单独且统一的API入口用于访问内部一个或多个API。简单来说嘛就是一个统一入口，比如现在的支付宝或者微信的相关api服务一样，都有一个统一的api地址，统一的请求参数，统一的鉴权。

客户端和服务端直连的弊端

• 客户端会对此请求不同的微服务，增加客户端复杂性
• 存在跨域请求时，需要进行额外处理
• 认证服务，每个服务需要独立认证
• UI端和微服务耦合

Zuul介绍和使用

    Zuul是Netflix开源的微服务网关，可以和Eureka、Ribbon、Hystrix等组件配合使用，Spring Cloud对Zuul进行了整合与增强，Zuul的主要功能是路由转发和过滤器。

    Zuul基于JVM的路由器和服务器端负载均衡器。同时，Zuul的规则引擎允许规则和过滤器基本上用任何JVM语言编写，内置支持Java和Groovy。这个功能，就可以实现动态路由的功能了。当需要添加某个新的对外服务时，一般上不停机更新是通过数据缓存配置或者使用Groovy进行动态路由的添加的。

Zuul的核心一系列的过滤器：

• 身份认证与安全：识别每个资源的验证要求，并拒绝那些与要求不符的请求。
• 审查与监控：在边缘位置追踪有意义的数据和统计结果，从而带来精确的生产视图。
• 动态路由：动态地将请求路由到不同的后端集群。
• 压力测试：逐渐增加指向集群的流量，以了解性能。
• 负载分配：为每一种负载类型分配对应容量，并启用超出限定值的请求。
• 静态响应处理：在边缘位置直接建立部分相应，从而避免其转发到内部集群。

加入Zuul网关后：

Zuul实践

• 一个服务注册中心，EUREKASERVER，端口为5555；
• HELLOSERVER工程跑了三个实例，端口分别为5556、5557、5558，分别向服务注册中心注册；
• SERVICE-RIBBON端口为5560，向服务注册中心注册；
• SERVICE_FEIGN端口为5565，向服务注册中心注册；

1、加入pom依赖

        <!-- zuul 依赖 -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-zuul</artifactId>
        </dependency>        
        <!-- eureka client 依赖 -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-eureka</artifactId>
        </dependency>

注意：这里的Eureka不是必须的。在没有注册中心的情况下，也是可以进行zuul使用的。

server:
  port: 5580  #端口号
 
spring:
  application:
    name: service-zuul  #服务注册中心测试名
 
zuul:
  #ignored-services: microservicecloud-dept    //外部通过微服务应用不可以访问
  prefix: /atguigu                             //添加前缀
  ignored-services: "*"                        //忽略所有的
  routes:
    api-a:    #可以随便写，在zuul上面唯一即可；当这里的值=service-id时，service-id可以不写。
      path: /ribbon/**
      serviceId: service-ribbon  #如果是/ribbon/**路径下的请求，则跳转到service-ribbon
    api-b:
      path: /feign/**
      serviceId: service-feign  #如果是/feign/**路径下的请求，则跳转到service-feign
 
eureka:
  client:
    serviceUrl:
      defaultZone: http://localhost:5555/eureka/  #服务注册中心

友情提示： 默认情况下：Zuul代理所有注册到EurekaServer的微服务，路由规则： http://ZUUL_HOST:ZUUL_PORT/微服务实例名(serverId)/** 转发至serviceId对应的微服务。

2.启动类加入@EnableZuulProxy注解，声明一个Zuul代理。

@EnableEurekaClient
@EnableZuulProxy
@SpringBootApplication
public class SpringcloudzuulApplication {
 
    public static void main(String[] args) {
        SpringApplication.run(SpringcloudzuulApplication.class, args);
    }
 
    @Bean
    public AccessFilter accessFilter() {
        return new AccessFilter();
    }
}

        首先指定服务注册中心的地址为http://localhost:5555/eureka/；Zuul服务端口为5580，服务名为service-zuul；以/ribbon/ 开头的请求都转发给service-ribbon服务；以/feign/开头的请求都转发给service-feign服务。

映射规则：

我们可以通过下表中的示例来进一步理解这三个通配符的含义并进行参考使用。

3、过滤器类

public class AccessFilter extends ZuulFilter {
 
    private static Logger log = LoggerFactory.getLogger(AccessFilter.class);
 
    @Override
    public String filterType() {
        return FilterConstants.PRE_TYPE;
    }
 
    @Override
    public int filterOrder() {
        return 0;
    }
 
    @Override
    public boolean shouldFilter() {
        return true;
    }
 
    @Override
    public Object run() {
        //获取上下文
        RequestContext ctx = RequestContext.getCurrentContext();
        //获取Request
        HttpServletRequest request = ctx.getRequest();
        //获取请求参数accessToken
        String accessToken = request.getParameter("accessToken");
        //使用String工具类
        if (StringUtils.isBlank(accessToken)) {
            log.warn("accessToken is empty");
            ctx.setSendZuulResponse(false);  //进行拦截
            ctx.setResponseStatusCode(401);
            try {
                ctx.getResponse().getWriter().write("accessToken is empty");
            } catch (Exception e) {
            }
            return null;
        }
        log.info("access is ok");
        return null;
    }
}

• filterType: 过滤器的类型，它决定过滤器在请求的哪个生命周期中执行。这里定义为pre,代表会在请求被路由之前执行。有前置、后置和路由过滤器。pre：可以在请求被路由之前调用。routing： 路由请求时被调用。post：在routing和error过滤器之后被调用。error：处理请求时发生错误时被调用
• filterOrder: 过滤器的执行顺序。当请求在一个阶段中存在多个过滤器时，需要根据该方法返回的值来依次执行。
• shouldFilter: 判断该过滤器是否需要被执行。这里我们直接返回了true,因此该过滤器对所有请求都会生效。实际运用中我们可以利用该函数来指定过滤器的有效范围。
• run: 过滤器的具体逻辑。这里我们通过ctx.setSendZuulResponse(false)令zuul过滤该请求，不对其进行路由，然后通过ctx.setResponseStatusCode(401)设置了其返回的错误码，当然也可以进 一步优化我们的返回，比如，通过ctx.setResponseBody(body)对返回的body内容进行编辑等。

路由请求生命周期

       外部http请求到达api网关服务的时候，首先它会进入第一个阶段pre，在这里它会被pre类型的过滤器进行处理。该类型过滤器的主要目的是在进行请求路由之前做一些前置加工，比如请求的校验等。在完成了pre类型的过滤器处理之后，请求进入第二个阶段routing，也就是之前说的路由请求转发阶段，请求将会器处理。这里的具体处理内容就是将外部请求转发到具体服务实例上去的过程，当服务实例请求结果都返回之后，routing阶段完成，请求进入第三个阶段post。此时请求将会被post类型的过滤器处理，这些过滤器在处理的时候不仅可以获取到请求信息，还能获取到服务实例的返回信息，所以在post类型的过滤器中，我们可以对处理结果进行一些加工或转换等内容。另外，还有一个特殊的阶段error，该阶段只有在上述三个阶段中发生异常的时候才会触发，但是它的最后流向还是post类型的过滤器，因为它需要通过post过滤器将最终结果返回给请求客户端（对于error过滤器的处理，在spring cloud zuul的过滤链中实际上有一些不同）。

4、测试

（1）访问：http://localhost:5555/

（2）访问：http://localhost:5580/ribbon/hello

（3）访问：http://localhost:5580/ribbon/hello?accessToken=ribbon

（4）访问：http://localhost:5580/feign/hello

（5）访问：http://localhost:5580/feign/hello?accessToken=feign

通过以上的测试，可以得出Zuul的路由和过滤都起作用了。

 

参考文章：

https://blog.csdn.net/smartdt/article/details/79043282