1.微服务网关概述

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

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

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

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

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

1.1 服务网关的概念

1.1.1 什么是微服务网关

API网关是一个服务器，是系统对外的唯一入口。API网关封装了系统内部架构，为每个客户端提供一个定制的API。API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。通常，网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。

1.1.2 作用和应用场景

网关具有的职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。当然，最主要的职责还是与“外界联系”。

1.2 常见的API网关实现方式

Kong

基于Nginx+Lua开发，性能高，稳定，有多个可用的插件(限流、鉴权等等)可以开箱即用。问题：只支持Http协议；二次开发，自由扩展困难；提供管理API，缺乏更易用的管控、配置方式。

Zuul

Netflflix开源，功能丰富，使用JAVA开发，易于二次开发；需要运行在web容器中，如Tomcat。问题：缺乏管控，无法动态配置；依赖组件较多；处理Http请求依赖的是Web容器，性能不如Nginx；

Traefifik

Go语言开发；轻量易用；提供大多数的功能：服务路由，负载均衡等等；提供WebUI问题：二进制文件部署，二次开发难度大；UI更多的是监控，缺乏配置、管理能力；

Spring Cloud Gateway

SpringCloud提供的网关服务

Nginx+lua实现

使用Nginx的反向代理和负载均衡可实现对api服务器的负载均衡及高可用问题：自注册的问题和网关本身的扩展性

1.3 基于Nginx的网关实现

1.3.1 Nginx介绍

1.3.2 正向/反向代理

（1）正向代理

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

（2）反向代理

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

如果只是单纯的需要一个最基础的具备转发功能的网关，那么使用Ngnix是一个不错的选择。

1.3.3 准备工作

启动 shop_service_order 微服务，单独请求地址：

启动 shop_service_product 微服务,单独请求地址：

安装资料中提供的ngnix。找到ngnix.exe双击运行即可

1.3.4 配置Nginx的请求转发

location /api-order { proxy_pass ;}location /api-product { proxy_pass ;}

2 微服务网关Zuul

2.1 Zuul简介

ZUUL是Netflflix开源的微服务网关，它可以和Eureka、Ribbon、Hystrix等组件配合使用，Zuul组件的核心是一系列的过滤器，这些过滤器可以完成以下功能：

动态路由：动态将请求路由到不同后端集群压力测试：逐渐增加指向集群的流量，以了解性能负载分配：为每一种负载类型分配对应容量，并弃用超出限定值的请求静态响应处理：边缘位置进行响应，避免转发到内部集群身份认证和安全: 识别每一个资源的验证要求，并拒绝那些不符的请求。Spring Cloud对Zuul进行了整合和增强。

Spring Cloud对Zuul进行了整合和增强

2.2 搭建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 #指定服务名

2.3 Zuul中的路由转发

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

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

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

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

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

2.3.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的网关功能@EnableDiscoveryClientpublic class ZuulServerApplication {public static void main(String[] args) {SpringApplication.run(ZuulServerApplication.class, args);}}

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

eureka:client:serviceUrl:defaultZone: : 5 # 获取服务列表的周期：5sinstance:preferIpAddress: trueip-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网关，在浏览器上通过访问 

service/product/1 查看最终效果。

2.3.2 简化的路由配置

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

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

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

上面的配置可以简化为一条

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

2.3.3 默认的路由规则

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

默认情况下，一切服务的映射路径就是服务名本身。

例如服务名为： shop-service-product ，则默认的映射路径就是： /shop-serviceproduct/

2.3.4 Zuul加入后的架构

2.4 Zuul中的过滤器

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

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

2.4.1 ZuulFilter简介

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

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

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

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

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

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

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

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

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

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

filterType ：返回字符串，代表过滤器的类型。包含以下4种：

pre ：请求在被路由之前执行routing ：在路由请求时调用post ：在routing和errror过滤器之后调用error ：处理请求时发生错误调用

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

2.4.2 生命周期

正常流程：

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

异常流程：

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

不同过滤器的场景：

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

所有内置过滤器列表：

2.4.3 自定义过滤器

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

@Componentpublic class LoginFilter extends ZuulFilter{@Overridepublic String filterType() {// 登录校验，肯定是在前置拦截return "pre";}@Overridepublic int filterOrder() {// 顺序设置为1return 1;}@Overridepublic boolean shouldFilter() {// 返回true，代表过滤器生效。return true;}@Overridepublic Object run() throws ZuulException {// 登录校验逻辑。// 1）获取Zuul提供的请求上下文对象RequestContext ctx = RequestContext.getCurrentContext();// 2) 从上下文中获取request对象HttpServletRequest req = ctx.getRequest();// 3) 从请求中获取tokenString 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，所以，任何数据都可以存储在上下文中！

2.5 服务网关Zuul的核心源码解析

在Zuul中，整个请求的过程是这样的，首先将请求给zuulservlet处理，zuulservlet中有一个zuulRunner对象，该对象中初始化了RequestContext：作为存储整个请求的一些数据，并被所有的zuulfifilter共享。zuulRunner中还有 FilterProcessor，FilterProcessor作为执行所有的zuulfifilter的管理器。FilterProcessor从fifilterloader 中获取zuulfifilter，而zuulfifilter是被fifilterFileManager所加载，并支持groovy热加载，采用了轮询的方式热加载。有了这些fifilter之后，zuulservelet首先执行的Pre类型的过滤器，再执行route类型的过滤器，最后执行的是post 类型的过滤器，如果在执行这些过滤器有错误的时候则会执行error类型的过滤器。执行完这些过滤器，最终将请求的结果返回给客户端。

（1）初始化

SpringCloud对Zuul的封装使得发布一个ZuulServer无比简单，根据自动装载原则可以在 springcloud-netflix-zuul-2.1.0.RELEASE.jar 下找到 spring.factories

ZuulServerAutoConfiguration，ZuulProxyAutoConfiguration 是Zuul服务端的自动配置类，这些配置类究竟负责什么工作，我们继续来看

@Configuration@Import({RestClientRibbonConfiguration.class, OkHttpRibbonConfiguration.class,HttpClientRibbonConfiguration.class, HttpClientConfiguration.class})@ConditionalOnBean({Marker.class})public class ZuulProxyAutoConfiguration extends ZuulServerAutoConfiguration {//省略}

ZuulProxyAutoConfiguration 继承了 ZuulServerAutoConfiguration ，我们先看下这个配置类

@Configuration@EnableConfigurationProperties({ZuulProperties.class})@ConditionalOnClass({ZuulServlet.class, ZuulServletFilter.class})@ConditionalOnBean({Marker.class})public class ZuulServerAutoConfiguration {@Bean@Primarypublic CompositeRouteLocator primaryRouteLocator(Collection<RouteLocator>routeLocators) {return new CompositeRouteLocator(routeLocators);}@Bean@ConditionalOnMissingBean({SimpleRouteLocator.class})public SimpleRouteLocator simpleRouteLocator() {return new SimpleRouteLocator(this.server.getServlet().getContextPath(),this.zuulProperties);}@Beanpublic ZuulController zuulController() {return new ZuulController();}@Configurationprotected static class ZuulFilterConfiguration {@Autowiredprivate Map<String, ZuulFilter> filters;protected ZuulFilterConfiguration() {}@Beanpublic ZuulFilterInitializer zuulFilterInitializer(CounterFactorycounterFactory, TracerFactory tracerFactory) {FilterLoader filterLoader = FilterLoader.getInstance();FilterRegistry filterRegistry = FilterRegistry.instance();return new ZuulFilterInitializer(this.filters, counterFactory,tracerFactory, filterLoader, filterRegistry);}}//其他省略}

整理一下这里配置类里面做了哪些事情呢？

CompositeRouteLocator：组合路由定位器，看入参就知道应该是会保存好多个RouteLocator，构造过程中其实仅包括一个DiscoveryClientRouteLocator。SimpleRouteLocator：默认的路由定位器，主要负责维护配置文件中的路由配置。ZuulController：Zuul创建的一个Controller，用于将请求交由ZuulServlet处理。ZuulHandlerMapping：这个会添加到SpringMvc的HandlerMapping链中，只有选择了ZuulHandlerMapping的请求才能出发到Zuul的后续流程。注册ZuulFilterInitializer，通过FilterLoader加载应用中所有的过滤器并将过滤器注册到FilterRegistry，那我们接下来一起看下过滤器是如何被加载到应用中的

public class ZuulFilterInitializer {private static final Log log =LogFactory.getLog(ZuulFilterInitializer.class);private final Map<String, ZuulFilter> filters;private final CounterFactory counterFactory;private final TracerFactory tracerFactory;private final FilterLoader filterLoader;private final FilterRegistry filterRegistry;public ZuulFilterInitializer(Map<String, ZuulFilter> filters, CounterFactorycounterFactory, TracerFactory tracerFactory, FilterLoader filterLoader,FilterRegistry filterRegistry) {this.filters = filters;this.counterFactory = counterFactory;this.tracerFactory = tracerFactory;this.filterLoader = filterLoader;this.filterRegistry = filterRegistry;}@PostConstructpublic void contextInitialized() {log.info("Starting filter initializer");TracerFactory.initialize(this.tracerFactory);CounterFactory.initialize(this.counterFactory);Iterator var1 = this.filters.entrySet().iterator();while(var1.hasNext()) {Entry<String, ZuulFilter> entry = (Entry)var1.next();this.filterRegistry.put((String)entry.getKey(),(ZuulFilter)entry.getValue());}}

（2）请求转发

在Zuul的自动配置中我们看到了 ZuulHandlerMapping ，为SpringMVC中 HandlerMapping 的拓展实现，会自动的添加到HandlerMapping链中。

public class ZuulHandlerMapping extends AbstractUrlHandlerMapping {private final RouteLocator routeLocator;private final ZuulController zuul;private ErrorController errorController;private PathMatcher pathMatcher = new AntPathMatcher();private volatile boolean dirty = true;public ZuulHandlerMapping(RouteLocator routeLocator, ZuulController zuul) {this.routeLocator = routeLocator;this.zuul = zuul;this.setOrder(-200);}private void registerHandlers() {Collection<Route> routes = this.routeLocator.getRoutes();if (routes.isEmpty()) {this.logger.warn("No routes found from RouteLocator");} else {Iterator var2 = routes.iterator();while(var2.hasNext()) {Route route = (Route)var2.next();this.registerHandler(route.getFullPath(), this.zuul);}}}}

其主要目的就是把所有路径的请求导入到ZuulController上.另外的功效是当觉察RouteLocator路由表变更,则更新自己dirty状态,重新注册所有Route到ZuulController。

public class ZuulController extends ServletWrappingController {public ZuulController() {//在这里已经设置了ZuulServletthis.setServletClass(ZuulServlet.class);this.setServletName("zuul");this.setSupportedMethods((String[])null);}public ModelAndView handleRequest(HttpServletRequest request,HttpServletResponse response) throws Exception {ModelAndView var3;try {//在这里面会调用ZuulServlet的service方法var3 = super.handleRequestInternal(request, response);} finally {RequestContext.getCurrentContext().unset();}return var3;}}

在 ZuulController 中的 handleRequest 方法，会调用已经注册的 ZuulServlet 完成业务请求，我们进入 ZuulServlet 看下内部是如何处理的

public void service(ServletRequest servletRequest, ServletResponseservletResponse) throws ServletException, IOException {try {this.init((HttpServletRequest)servletRequest,(HttpServletResponse)servletResponse);RequestContext context = RequestContext.getCurrentContext();context.setZuulEngineRan();try {this.preRoute();} catch (ZuulException var13) {this.error(var13);this.postRoute();return;}try {this.route();} catch (ZuulException var12) {this.error(var12);this.postRoute();return;}try {this.postRoute();} catch (ZuulException var11) {this.error(var11);}} catch (Throwable var14) {this.error(new ZuulException(var14, 500, "UNHANDLED_EXCEPTION_" +var14.getClass().getName()));} finally {RequestContext.getCurrentContext().unset();}}

（3）过滤器

Zuul默认注入的过滤器可以在 spring-cloud-netflix-core.jar 中找到。

2.6 Zuul网关存在的问题

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

性能问题

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

不支持任何长连接，如websocket

2.7 Zuul网关的替换方案

Zuul2.x版本

SpringCloud Gateway