09-SpringCloud 搭建Zuul网关服务器

微服务网关概述

在学习完前面的知识后，微服务架构已经初具雏形。但还有一些问题：不同的微服务一般会有不同的网 络地址，客户端在访问这些微服务时必须记住几十甚至几百个地址，这对于客户端方来说太复杂也难以 维护。如下图：

如果让客户端直接与各个微服务通讯，可能会有很多问题：

客户端会请求多个不同的服务，需要维护不同的请求地址，增加开发难度
在某些场景下存在跨域请求的问题
加大身份认证的难度，每个微服务需要独立认证

因此，我们需要一个微服务网关，介于客户端与服务器之间的中间层，所有的外部请求都会先经过微服务网关。客户端只需要与网关交互，只知道一个网关地址即可，这样简化了开发还有以下优点：

1、易于监控
2、易于认证
3、减少了客户端与各个微服务之间的交互次数

服务网关的概念

什么是微服务网关
API网关是一个服务器，是系统对外的唯一入口。API网关封装了系统内部架构，为每个客户端提供一个定制的API。API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。通常，网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。
作用和应用场景
网关具有的职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。当然，最主要的职责还是与“外界联系”。

常见的API网关实现方式

Kong
基于Nginx+Lua开发，性能高，稳定，有多个可用的插件(限流、鉴权等等)可以开箱即用。
问题：只支持Http协议；二次开发，*扩展困难；提供管理API，缺乏更易用的管控、配置方式。
Zuul
Netflflix开源，功能丰富，使用JAVA开发，易于二次开发；需要运行在web容器中，如Tomcat。
问题：缺乏管控，无法动态配置；依赖组件较多；处理Http请求依赖的是Web容器，性能不如 Nginx；
Traefifik
Go语言开发；轻量易用；提供大多数的功能：服务路由，负载均衡等等；提供WebUI
问题：二进制文件部署，二次开发难度大；UI更多的是监控，缺乏配置、管理能力；
Spring Cloud GatewaySpringCloud提供的网关服务
Nginx+lua实现
使用Nginx的反向代理和负载均衡可实现对api服务器的负载均衡及高可用
问题：自注册的问题和网关本身的扩展性

基于Nginx的网关实现

Nginx介绍

正向/反向代理
正向代理

正向代理，“它代理的是客户端，代客户端发出请求”，是一个位于客户端和原始服务器(origin server)之间的服务器，为了从原始服务器取得内容，客户端向代理发送一个请求并指定目标(原始服务器)，然后代理向原始服务器转交请求并将获得的内容返回给客户端。客户端必须要进行一些特别的设置才能使用正向代理。
反向代理

多个客户端给服务器发送的请求，Nginx服务器接收到之后，按照一定的规则分发给了后端的业务处 理服务器进行处理了。此时~请求的来源也就是客户端是明确的，但是请求具体由哪台服务器处理的并不明确了，Nginx扮演的就是一个反向代理角色。客户端是无感知代理的存在的，反向代理对外都是透明的，访问者并不知道自己访问的是一个代理。因为客户端不需要任何配置就可以访问。反向代理，“它代理的是服务端，代服务端接收请求”，主要用于服务器集群分布式部署的情况下，反向代理隐 了服务器的信息如果只是单纯的需要一个最基础的具备转发功能的网关，那么使用Ngnix是一个不错的选择。

微服务网关Zuul

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

搭建Zuul网关服务器

创建工程导入依赖

<dependencies>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-netflix-zuul</artifactId>
        <version>2.1.0.RELEASE</version>
    </dependency>
<dependency>
    <groupId>com.marcosbarbero.cloud</groupId>
    <artifactId>spring-cloud-zuul-ratelimit</artifactId>
    <version>1.3.4.RELEASE</version>
</dependency>

</dependencies>

编写启动类

@EnableZuulProxy ： 通过 @EnableZuulProxy 注解开启Zuul网管功能
编写配置
创建配置文件 application.yml ，并添加相应配置

server:
  port: 7003
spring:
  application:
    name: my-wf-gateway-zuul
eureka:
  client:
    service-url:
      defaultZone: http://root:[e-mail]:7001/eureka/
  instance:
    prefer-ip-address: true #显示浏览器中的状态栏显示ip
zuul:
  routes:
    myuser-consumer:  # 这里是路由id，随意写 
      path: /userserver/**   # 这里是映射路径
      serviceId: user-consumer #配置转发的微服务名称

#  ratelimit:
#    enabled: true #开启限流
#    policies:
#      myuser-consumer:
#        limit: 10 #60s 内请求超过 3 次，服务端就抛出异常，60s 后可以恢复正常请求
#        refresh-interval: 60
#        type: origin #针对 IP 进行限流，不影响其他 IP
  ratelimit:
    enabled: true #开启限流
    default-policy:
      limit: 3 #60s 内请求超过 3 次，服务端就抛出异常，60s 后可以恢复正常请求
      refresh-interval: 60
      type: origin #针对 IP 进行限流，不影响其他 IP

Zuul加入后的架构

Zuul中的过滤器

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

ZuulFilter简介

以通过配置 urlPatterns 来拦截对应的请求。而 Zuul 中的过滤器总共有 4 种类型，且每种类型都有对应的使用场景。

1. PRE：这种过滤器在请求被路由之前调用。我们可利用这种过滤器实现身份验证、在集群中选择请求的微服务、记录调试信息等。
2. ROUTING：这种过滤器将请求路由到微服务。这种过滤器用于构建发送给微服务的请求，并使用Apache HttpClient或Netfifilx Ribbon请求微服务。
3. POST：这种过滤器在路由到微服务以后执行。这种过滤器可用来为响应添加标准的HTTP
   Header、收集统计信息和指标、将响应从微服务发送给客户端等。
4. ERROR：在其他阶段发生错误时执行该过滤器。
   生命周期
   
   正常流程：
   请求到达首先会经过pre类型过滤器，而后到达routing类型，进行路由，请求就到达 真正的服务提供者，执行请求，返回结果后，会到达post过滤器。而后返回响应。
   异常流程：
   整个过程中，pre或者routing过滤器出现异常，都会直接进入error过滤器，再error 处理完毕后，会将请求交给POST过滤器，最后返回给用户。
   如果是error过滤器自己出现异常，最终也会进入POST过滤器，而后返回。
   如果是POST过滤器出现异常，会跳转到error过滤器，但是与pre和routing不同的时， 请求不会再到达POST过滤器了。
   不同过滤器的场景：
   请求鉴权：一般放在pre类型，如果发现没有访问权限，直接就拦截了
   异常处理：一般会在error类型和post类型过滤器中结合来处理。
   服务调用时长统计：pre和post结合使用。

@Component
public class PowerFilter extends ZuulFilter {
    @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 currentContext = RequestContext.getCurrentContext();
        HttpServletRequest request = currentContext.getRequest();
        String token = request.getParameter("token");
        if(token==null || token.equals("")){
            currentContext.setSendZuulResponse(false);
            currentContext.setResponseStatusCode(401);
            currentContext.setResponseBody("{'msg':'401 account without'}");
            return "access";
        }
        return "next";
    }
}

网关限流

常见的限流算法
（1） 计数器
计数器限流算法是最简单的一种限流实现方式。其本质是通过维护一个单位时间内的计数器，每次请求计数器加1，当单位时间内计数器累加到大于设定的阈值，则之后的请求都被拒绝，直到单位时间已经过去，再将计数器重置为零

（2） 漏桶算法
漏桶算法可以很好地限制容量池的大小，从而防止流量暴增。漏桶可以看作是一个带有常量服务时间的单服务器队列，如果漏桶（包缓存）溢出，那么数据包会被丢弃。 在网络中，漏桶算法可以控制端口的流量输出速率，平滑网络上的突发流量，实现流量整形，从而为网络提供一个稳定的流量。

为了更好的控制流量，漏桶算法需要通过两个变量进行控制：一个是桶的大小，支持流量突发增多时可以存多少的水（burst），另一个是水桶漏洞的大小（rate）。
（3） 令牌桶算法
令牌桶算法是对漏桶算法的一种改进，桶算法能够限制请求调用的速率，而令牌桶算法能够在限制调用 的平均速率的同时还允许一定程度的突发调用。在令牌桶算法中，存在一个桶，用来存放固定数量的令牌。算法中存在一种机制，以一定的速率往桶中放令牌。每次请求调用需要先获取令牌，只有拿到令 牌，才有机会继续执行，否则选择选择等待可用的令牌、或者直接拒绝。放令牌这个动作是持续不断的 进行，如果桶中令牌数达到上限，就丢弃令牌，所以就存在这种情况，桶中一直有大量的可用令牌，这 时进来的请求就可以直接拿到令牌执行，比如设置qps为100，那么限流器初始化完成一秒后，桶中就已经有100个令牌了，这时服务还没完全启动好，等启动完成对外提供服务时，该限流器可以抵挡瞬时 的100个请求。所以，只有桶中没有令牌时，请求才会进行等待，最后相当于以一定的速率执行。

Zuul高并发请求下的限流处理

高并发的情况肯定是实际场景中经常碰到的情况，那么这种情况下限流措施肯定是必须的，本文我们就来看看zuul中限流的处理
高并发的限流处理
异常处理
增对error异常，我们可以提供一个全局异常处理器

@RestControllerpublic class ExceptionHandler implements ErrorController{

    @Override
    public String getErrorPath() {
        
        return "error";
    }
    
    @RequestMapping(value="/error")
    public String error(){
        return "{\"result\":\"访问太多频繁，请稍后再访问！！！\"}";
    }
}

限流的提示如下:

令牌桶限流

import com.google.common.util.concurrent.RateLimiter;
import com.netflix.zuul.ZuulFilter;
import com.netflix.zuul.context.RequestContext;
import org.springframework.cloud.netflix.zuul.filters.support.FilterConstants;
import org.springframework.stereotype.Component;

@Component
public class RouteFilter extends ZuulFilter {
    // 定义一个令牌桶，每秒产生2个令牌，即每秒最多处理2个请求
    private static final RateLimiter RATE_LIMITER = RateLimiter.create(2);
    @Override
    public String filterType() {
        return FilterConstants.PRE_TYPE;
    }

    @Override
    public int filterOrder() {
        return -5;
    }

    @Override
    public boolean shouldFilter() {
        // 获取请求上下文
        RequestContext context = RequestContext.getCurrentContext();
        // tryAcquire() 只要能够马上获致到1个令牌，则返回true，不阻塞
        // tryAcquire(5, 3, TimeUnit.SECONDS) 在3秒钟内可以获取到5个令牌，则返回true，不阻塞
        // acquire(5) 获取到5个令牌，否则一直等待，会阻塞，返回值为阻塞的时长
        // acquire() 获取到1个令牌，否则一直等待，会阻塞，返回值为阻塞的时长
        if(!RATE_LIMITER.tryAcquire()) {
            context.getResponse().setContentType("application/json; charset=utf-8");
            // 指定当前请求未通过过滤
            context.setSendZuulResponse(false);
            // 向客户端返回响应码429，请求数量过多
            context.setResponseStatusCode(429);
            context.setResponseBody("{'msg':'429 访问量超载'}");
            return false;
        }
        return true;
    }

    @Override
    public Object run() {

        return null;
    }
}

Zuul网关存在的问题

在实际使用中我们会发现直接使用Zuul会存在诸多问题，包括：
性能问题
Zuul1x版本本质上就是一个同步Servlet，采用多线程阻塞模型进行请求转发。简单讲，每来
一个请求，Servlet容器要为该请求分配一个线程专门负责处理这个请求，直到响应返回客户
端这个线程才会被释放返回容器线程池。如果后台服务调用比较耗时，那么这个线程就会被
阻塞，阻塞期间线程资源被占用，不能干其它事情。我们知道Servlet容器线程池的大小是有
限制的，当前端请求量大，而后台慢服务比较多时，很容易耗尽容器线程池内的线程，造成
容器无法接受新的请求。不支持任何长连接，如websocket

Zuul网关的替换方案

Zuul2.x版本
SpringCloud Gateway