微服务之zuul网关

Zuul简介

ZUUL是Netflix开源的微服务网关，它可以和Eureka、Ribbon、Hystrix等组件配合使用，Zuul组件的核心是一系列的过滤器，这些过滤器可以完成以下功能：   
    动态路由：动态将请求路由到不同后端集群
    压力测试：逐渐增加指向集群的流量，以了解性能
    负载分配：为每一种负载类型分配对应容量，并弃用超出限定值的请求
    静态响应处理：边缘位置进行响应，避免转发到内部集群
    身份认证和安全: 识别每一个资源的验证要求，并拒绝那些不符的请求。		Spring Cloud对Zuul进行了整合和增强。

搭建Zuul网关服务器

（1）创建工程导入依赖

在IDEA中创建ZUUL网关工程 shop_zuul_server ，并添加响应依赖

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

（2）编写启动类
创建启动类 ZuulServerApplication

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

@EnableZuulProxy ： 通过 @EnableZuulProxy 注解开启Zuul网关功能

（3）编写配置
创建配置文件 application.yml ，并添加相应配置

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

Zuul中的路由转发

基本

最直观的理解：“路由”是指根据请求URL，将请求分配到对应的处理程序。在微服务体系中，Zuul负责接收所有的请求。根据不同的URL匹配规则，将不同的请求转发到不同的微服务处理。

zuul:
 routes:
  product-service: # 这里是路由id，随意写
   path: /product-service/** # 这里是映射路径
   url: http://127.0.0.1:9002 # 映射路径对应的实际url地址
   sensitiveHeaders: #默认zuul会屏蔽cookie，cookie不会传到下游服务，这里设置为空则取消默认的黑名单，如果设置了具体的头信息则不会传到下游服务

只需要在application.yml文件中配置路由规则即可：

product-service：配置路由id，可以随意取名
url：映射路径对应的实际url地址
path：配置映射路径，这里将所有请求前缀为/product-service/的请求，转发到http://127.0.0.1:9002处理

配置好Zuul路由之后启动服务，在浏览器中输入 http://localhost:8080/productservice/product/1 ，即可访问到订单微服务。

面向服务的路由

	微服务一般是由几十、上百个服务组成，对于一个URL请求，最终会确认一个服务实例进行处理。如果对每个服务实例手动指定一个唯一访问地址，然后根据URL去手动实现请求匹配，这样做显然就不合
理。
	Zuul支持与Eureka整合开发，根据ServiceID自动的从注册中心中获取服务地址并转发请求，这样做的好处不仅可以通过单个端点来访问应用的所有服务，而且在添加或移除服务实例的时候不用修改Zuul的路由配置。

（1）添加Eureka客户端依赖

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

（2）开启Eureka客户端发现功能

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

（3）添加Eureka配置，获取服务信息

eureka:
 client:
  serviceUrl:
   defaultZone: http://127.0.0.1:8761/eureka/
   registry-fetch-interval-seconds: 5 # 获取服务列表的周期：5s
 instance:
  preferIpAddress: true
  ip-address: 127.0.0.1

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

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

#配置路由规则
zuul:
 routes:
  product-service: # 这里是路由id，随意写
   path: /product-service/** # 这里是映射路径
   serviceId: shop-service-product #配置转发的微服务名称

serviceId: 指定需要转发的微服务实例名称

依次启动Eureka，商品微服务，API网关，在浏览器上通过访问 http://localhost:8080/productservice/product/1 查看最终效果

简化的路由配置

在刚才的配置中，我们的规则是这样的：

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


而大多数情况下，我们的 <route> 路由名称往往和服务名会写成一样的。因此Zuul就提供了一种简化的配置语法： zuul.routes.<serviceId>=<path>
上面的配置可以简化为一条：


zuul:
 routes:
  shop-service-product: /product-service/**

默认的路由规则

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

默认情况下，一切服务的映射路径就是服务名本身。
例如服务名为： shop-service-product ，则默认的映射路径就是： /shop-service-product/**

Zuul加入后的架构

在这里插入图片描述

Zuul中的过滤器

前言

通过之前的学习，我们得知Zuul它包含了两个核心功能：对请求的路由和过滤。其中路由功能负责将外部请求转发到具体的微服务实例上，是实现外部访问统一入口的基础；而过滤器功能则负责对请求的处理过程进行干预，是实现请求校验、服务聚合等功能的基础。其实，路由功能在真正运行时，它的路由映射和请求转发同样也由几个不同的过滤器完成的。所以，过滤器可以说是Zuul实现API网关功能最为核心的部件，每一个进入Zuul的HTTP请求都会经过一系列的过滤器处理链得到请求响应并返回给客户端。

那么接下来，我们重点学习的就是Zuul的第二个核心功能：过滤器。

请求到zuul网关后首先进入pre过滤器，然后到routing filters ，通过routing filters 真正去调用远程的服务origin server 然后远程服务响应到routing filters ，再到post，通过post filters响应数据到客户端，这中间哪一步出错了都会直接走到error filters。

在这里插入图片描述

在这里插入图片描述

ZuulFilter简介

Zuul 中的过滤器跟我们之前使用的 javax.servlet.Filter 不一样，javax.servlet.Filter 只有一种类型，可以通过配置 urlPatterns 来拦截对应的请求。而 Zuul 中的过滤器总共有 4 种类型，且每种类型都有对应的使用场景。

1. PRE：这种过滤器在请求被路由之前调用。我们可利用这种过滤器实现身份验证、在集群中选择请求的微服务、记录调试信息等。

2. ROUTING：这种过滤器将请求路由到微服务。这种过滤器用于构建发送给微服务的请求，并使用Apache HttpClient或Netfilx Ribbon请求微服务。

3. POST：这种过滤器在路由到微服务以后执行。这种过滤器可用来为响应添加标准的HTTPHeader、收集统计信息和指标、将响应从微服务发送给客户端等。

4. ERROR：在其他阶段发生错误时执行该过滤器。

Zuul提供了自定义过滤器的功能实现起来也十分简单，只需要编写一个类去实现zuul提供的接口。

public abstract ZuulFilter implements IZuulFilter{
    abstract public String filterType();
    abstract public int filterOrder();
    boolean shouldFilter();// 来自IZuulFilter
    Object run() throws ZuulException;// IZuulFilter
}

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

1.shouldFilter ：返回一个 Boolean 值，判断该过滤器是否需要执行。返true执行，返回false不执行。

2.run ：过滤器的具体业务逻辑。

3.filterType ：返回字符串，代表过滤器的类型。包含以下4种：
    pre ：请求在被路由之前执行
    routing ：在路由请求时调用
    post ：在routing和errror过滤器之后调用
    error ：处理请求时发生错误调用

4.filterOrder ：通过返回的int值来定义过滤器的执行顺序，数字越小优先级越高。

生命周期

在这里插入图片描述

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

2.异常流程：
	整个过程中，pre或者routing过滤器出现异常，都会直接进入error过滤器，再error处理完毕后，会将请求交给POST过滤器，最后返回给用户。
	如果是error过滤器自己出现异常，最终也会进入POST过滤器，而后返回。如果是POST过滤器出现异常，会跳转到error过滤器，但是与pre和routing不同的时，请求不会再到达POST过滤器了。
	
3.不同过滤器的场景：
	请求鉴权：一般放在pre类型，如果发现没有访问权限，直接就拦截了
	异常处理：一般会在error类型和post类型过滤器中结合来处理。
	服务调用时长统计：pre和post结合使用。

自定义过滤器

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

@Component
public class LoginFilter extends ZuulFilter{
    @Override
    public String filterType() {
        // 登录校验，肯定是在前置拦截
        return "pre";
    }
    @Override
    public int filterOrder() {
        // 顺序设置为1
        return 1;
    }
    @Override
    public boolean shouldFilter() {
        // 返回true，代表过滤器生效。
        return true;
    }
    @Override
    public Object run() throws ZuulException {
        // 登录校验逻辑。
        // 1）获取Zuul提供的请求上下文对象
        RequestContext ctx = RequestContext.getCurrentContext();
            // 2) 从上下文中获取request对象
        HttpServletRequest req = ctx.getRequest();
        // 3) 从请求中获取token
        String token = req.getParameter("access-token");
        // 4) 判断
        if(token == null || "".equals(token.trim())){
        // 没有token，登录校验失败，拦截
        ctx.setSendZuulResponse(false);
        // 返回401状态码。也可以考虑重定向到登录页。
        ctx.setResponseStatusCode(HttpStatus.UNAUTHORIZED.value());
    }
    // 校验通过，可以考虑把用户信息放入上下文，继续向后执行
    return null;
    }
}

RequestContext：用于在过滤器之间传递消息。它的数据保存在每个请求的ThreadLocal中。它用于存储请求路由到哪里、错误、HttpServletRequest、HttpServletResponse都存储在RequestContext中。RequestContext扩展了ConcurrentHashMap，所以，任何数据都可以存储在上下文中

"ctx.setSendZuulResponse(false) 表示不进行路由",即将其设为false代表的意思是,这个请求最终不会被zuul转发到后端服务器

Zuul网关存在的问题

在实际使用中我们会发现直接使用Zuul会存在诸多问题，包括：

1.性能问题：
	Zuul1x版本本质上就是一个同步Servlet，采用多线程阻塞模型进行请求转发。简单讲，每来一个请求，Servlet容器要为该请求分配一个线程专门负责处理这个请求，直到响应返回客户端这个线程才会被释放返![在这里插入图片描述](https://img-blog.csdnimg.cn/f3108b1b0b2544988c85aa012e5818f0.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA5L2g55qE5bCP5LyZ5Ly05ZWK,size_20,color_FFFFFF,t_70,g_se,x_16)

回容器线程池。如果后台服务调用比较耗时，那么这个线程就会被阻塞，阻塞期间线程资源被占用，不能干其它事情。我们知道Servlet容器线程池的大小是有限制的，当前端请求量大，而后台慢服务比较多时，很容易耗尽容器线程池内的线程，造成容器无法接受新的请求。

2.不支持任何长连接，如websocket

zuul和gateway的区别

Zuul：
    使用的是阻塞式的 API，不支持长连接，比如 websockets。
    底层是servlet，Zuul处理的是http请求
    没有提供异步支持，流控等均由hystrix支持。
    依赖包spring-cloud-starter-netflix-zuul。
    
Gateway：
	Spring Boot和Spring Webflux提供的Netty底层环境，不能和传统Servlet容器一起使用，也不能打包成一个WAR包。
	依赖spring-boot-starter-webflux和/ spring-cloud-starter-gateway
	提供了异步支持，提供了抽象负载均衡，提供了抽象流控，并默认实现了RedisRateLimiter。
	
二、相同点：
    1、底层都是servlet
    2、两者均是web网关，处理的是http请求

三、不同点：
1、内部实现：
　　gateway对比zuul多依赖了spring-webflux，在spring的支持下，功能更强大，内部实现了限流、负载均衡等，扩展性也更强，但同时也限制了仅适合于Spring Cloud套件zuul则可以扩展至其他微服务框架中，其内部没有实现限流、负载均衡等。
2、是否支持异步
　　zuul仅支持同步
　　gateway支持异步。理论上gateway则更适合于提高系统吞吐量（但不一定能有更好的性能），最终性能还需要通过严密的压测来决定
3、框架设计的角度
　　gateway具有更好的扩展性，并且其已经发布了2.0.0的RELESE版本，稳定性也是非常好的
4、性能
　　WebFlux 模块的名称是 spring-webflux，名称中的 Flux 来源于 Reactor 中的类 Flux。Spring webflux 有一个全新的非堵塞的函数式 Reactive Web 框架，可以用来构建异步的、非堵塞的、事件驱动的服务，在伸缩性方面表现非常好。使用非阻塞API。 Websockets得到支持，并且由于它与Spring紧密集成，所以将会是一个更好的 开发 体验。Zuul 1.x，是一个基于阻塞io的API Gateway。Zuul已经发布了Zuul 2.x，基于Netty，也是非阻塞的，支持长连接，但Spring Cloud暂时还没有整合计划。

四、总结
　　总的来说，在微服务架构，如果使用了Spring Cloud生态的基础组件，则Spring Cloud Gateway相比而言更加具备优势，单从流式编程+支持异步上就足以让开发者选择它了。
　　对于小型微服务架构或是复杂架构（不仅包括微服务应用还有其他非Spring Cloud服务节点），zuul也是一个不错的选择。
　　

zuul网关的应用概述

平时自己在应用中怎么使用zuul网关呢？
1.首先是登录接口，点击登录后会返回一个令牌（一般叫做token），比如在我现在这个系统中就是返回的一个uuid做为token。登录的时候通过用户名去数据库查询该用户信息，然后把用户信息存入redis缓存中，key就是token，value就是用户信息。然后登录接口返回token值，前端把token存入cookie缓存中，此时登录接口就完成了。（我当前系统是把token存入cookie中后，在把token放到header中，给header新增一个键值对Authorization：token值），然后zuul网关取Authorization的值就拿到token，通过token去redis缓存获取用户信息。

2.点击页面调用某个接口时，都会走zuul网关的过滤器，而我们一般把校验用户的操作放在pre过滤器里面，在pre过滤器里面有个shouldFilter方法，shouldFilter方法一般有两个逻辑，第一个是处理登录请求，即校验验证码（验证码不能为空，验证码已失效，验证码错误等），如果验证码不过关则不需要继续往后走去校验用户信息，同时也不会转发到对应的路由了，网关直接就返回错误提示；第二个逻辑是跳过白名单，即配置了白名单的路径不需要去校验用户信息，但是需要转发到对应的路由。
这里需要注意，在pre过滤器中还有一个方法叫做run，一般用户校验逻辑就在run方法中，shouldFilter方法返回false则不走run方法，即不校验用户，shouldFilter返回true就会进入run方法，去校验用户信息。
zuul上下文中有一个东西叫做sendZuulResponse，当这个值为false时，就代表不会转发路由了，网关直接给响应。（requestContext.setSendZuulResponse(false); ）即在shouldFilter方法中的两个逻辑（一个处理验证码，一个跳过白名单），处理验证码逻辑出现错误时，shouldFilter方法返回false的同时sendZuulResponse需要设置为false，即不继续转发路由，而在跳过白名单逻辑的时候，检查到该路径是配置在白名单中，则直接返回false而不会把sendZuulResponse设置为false，而是设置为true（默认就是true，所以可以直接不设置）

3.shouldFilter方法返回true后就会进入run方法进行用户信息的校验，在run方法中就获取到前端request header中的token，通过这个token从redis缓存中得到用户信息，然后拿到用户信息去做具体校验即可，如果用户信息错误则把sendZuulResponse设置为false，不继续跳转路由，如果校验没有问题，一般把用户信息放到zuul的上下文对象中，run方法直接返回null（代表校验通过），转发请求到对应的路由，这样整个zuul进行用户校验的过滤器逻辑就完成了。

几个注意点：
1.shouldFilter方法返回true则进入run方法，返回false则不进入run方法
2.sendZuulResponse为false则不会去进行路由的转发了，网关层直接返回响应；sendZuulResponse为true则网关会转发到对应的路由，sendZuulResponse默认就是true。
3.run方法直接返回null就代表校验成功

如下，前端把token放在request headers里面的Authorization里面，在zuul网关里面就获取header的这个Authorization值就拿到了Bearer+空格+token值，然后在代码中把Bearer+空格替换为空串，即得到了纯粹与的token，就可以通过token从redis获取用户信息了
在这里插入图片描述

# java # spring # spring boot
Logo
开放原子开发者工作坊

开放原子开发者工作坊旨在鼓励更多人参与开源活动，与志同道合的开发者们相互交流开发经验、分享开发心得、获取前沿技术趋势。工作坊有多种形式的开发者活动，如meetup、训练营等，主打技术交流，干货满满，真诚地邀请各位开发者共同参与！

更多推荐

多模态大模型&科学计算双管齐下，百度飞桨两大赛项报名倒计时！

第二届开放原子大赛是由开放原子开源基金会组织举办的开源技术领域专业赛事，聚焦解决真问题，重点覆盖基础软件、工业软件、人工智能大模型等领域

avatar 开放原子开发者工作坊

以智能 致世界 | 操作系统大会2024议程全览

avatar 开放原子开发者工作坊

开放原子开源基金会新增捐赠人（2024年9月）

2024年9月，新增以下单位成为开放原子开源基金会及旗下项目捐赠人。

avatar 开放原子开发者工作坊