微服务核心组件 Zuul 网关原理剖析

一、前言

Zuul 网关是具体核心业务服务的看门神，相比具体实现业务的系统服务来说它是一个边缘服务，主要提供动态路由，监控，弹性，安全性等功能。在分布式的微服务系统中，系统被拆为了多套系统，通过zuul网关来对用户的请求进行路由，转发到具体的后台服务系统中。

本 Chat 主要内容如下：

• 服务网关演化历程。
• Zuul 1.0 服务架构与源码剖析。
• Zuul 2.0 服务架构新特性。

二、服务网关演化历程

网关是具体核心业务服务的看门神，相比具体实现业务的系统服务来说它是一个边缘服务，主要提供动态路由，监控，弹性，安全性等功能，下面我们从单体应用到多体应用的演化过程来讲解网关的演化历程。

一般业务系统发展历程都是基本相似的，从单体应用到多应用，从本地调用到远程调用。对应单体应用架构模式（如下图1），由于只需一个应用，所有业务模块的功能都打包为了一个 War 包进行部署，这样可以减少机器资源和部署的繁琐。

图1 单体应用

在单体应用中，网关模块是和应用部署到同一个jvm进程里面的，当外部移动设备或者web站点访问单体应用的功能时候，请求是先被应用的网关模块拦截的，网关模块对请求进行鉴权、限流等动作后在把具体的请求转发到当前应用对应的模块进行处理。

随着业务的发展，网站的流量会越来越大，在单体应用中简单的通过加机器的方式可以带来的承受流量冲击的能力也越来越低，这时候就会考虑根据业务将单体应用拆成若干个功能独立的应用，单体应用拆为多个应用后，由于不同的应用开发对应的功能，所以多应用开发之间可以独立开发而不用去理解对方的业务，另外不同的应用模块只承受对应业务流量的压力，不会对其他应用模块造成影响，这时候多体的分布式系统就出现了，如下图2。

图2 多体应用

如上图在多体应用中业务模块A和B单独起了个应用，每个应用里面有自己的网关模块，如果业务模块多了，那么每个应用都有自己的网关模块，这样复用性不好，所以可以考虑把网关模块提起出来，单独作为一个应用来做服务路由，如下图3：

如上图当移动设备发起请求时候是具体发送到网关应用的，经过鉴权后请求会被转发到具体的后端服务应用上，对应前端移动设备来说他们不在乎也不知道后端服务器应用是一个还是多个，他们只能感知到网关应用的存在。

Zuul是Netflix开源的一个网关组件，在Netflix内部系统中Zuul被用来作为内部系统的门面，如下图是Zuul在Netflix内部使用的一个架构图：

如上图最上层的移动设备或者网站首先通过aws负载均衡器把请求路由到zuul网关上，zuul网关则负责把请求路由到具体的后端service上。

Zuul开源地址 https://github.com/Netflix/zuul

三、Zuul 1.0 服务架构与源码剖析

3.1 Zuul 1.0 服务架构概述

Zuul网关的核心是一系列的过滤器，这些过滤器可以对请求或者响应结果做一系列过滤，Zuul 提供了一个框架可以支持动态加载，编译，运行这些过滤器，这些过滤器是使用责任链方式顺序对请求或者响应结果进行处理的，这些过滤器直接不会直接进行通信，但是通过责任链传递的RequestContext参数可以共享一些东西。

虽然Zuul 支持任何可以在jvm上跑的语言，但是目前zuul的过滤器只能使用Groovy脚本来编写。编写好的过滤器脚本一般放在zuul服务器的固定目录，zuul服务器会开启一个线程定时去轮询被修改或者新增的过滤器，然后动态进行编译，加载到内存，然后等后续有请求进来，新增或者修改后的过滤器就会生效了。

在zuul中过滤器分为四种：

• PRE Filters(前置过滤器) ：当请求会路由转发到具体后端服务器前执行的过滤器，比如鉴权过滤器，日志过滤器，还有路由选择过滤器

• ROUTING Filters （路由过滤器）：该过滤器作用是把请求具体转发到后端服务器上，一般是通过Apache HttpClient 或者 Netflix Ribbon把请求发送到具体的后端服务器上

• POST Filters（后置过滤器）：当把请求路由到具体后端服务器后执行的过滤器；场景有添加标准http 响应头，收集一些统计数据（比如请求耗时等），写入请求结果到请求方等。

• ERROR Filters（错误过滤器）：当上面任何一个类型过滤器执行出错时候执行该过滤器

如下图为zuul1.0的工作原理：

如上图，当zuul接受到请求后，首先会由前置过滤器进行处理，然后在由路由过滤器具体把请求转发到后端应用，然后在执行后置过滤器把执行结果写会到请求方，当上面任何一个类型过滤器执行出错时候执行该过滤器。

3.2 Zuul 1.0 源码分析

…

3.2.2 动态装载过滤器-FilterFileManager类

…

总结：zuul1.0时候当zuul接受到一个请求后会同步执行前置过滤器、路由过滤器、后置过滤器，等执行完毕后在同步把结果返回为调用方，调用方在整个过程中是阻塞的。其实SpringBoot集成的zuul就是自己实现了个前置过滤器做选择路由，然后自己实现了个路由过滤器根据前置过滤器选择的路由具体做路由转发。

四、Zuul 2.0 服务架构新特性

4.1 新特性

Netty作为高性能异步网络通讯框架，在dubbo，rocketmq,sofa等知名开源框架中都有使用，如下图zuul2.0使用netty server作为网关监听服务器监听客户端发来的请求，然后把请求转发到前置过滤器（inbound filters）进行处理，处理完毕后在把请求使用netty client代理到具体的后端服务器进行处理，处理完毕后在把结果交给后者过滤器（outbound filters）进行处理，然后把处理结果通过nettyServer写回客户端。

…
总: 在zuul1.0时候客户端发起的请求后需要同步等待zuul网关返回，zuul网关这边对每个请求会分派一个线程来进行处理，这会导致并发请求数量有限。而zuul2.0使用netty作为异步通讯，可以大大加大并发请求量。

五、最后

• 微服务核心组件 Zuul 网关原理剖析全集单击我
• rocketmq环境搭建单击我
• 想系统学dubbo的单击我
• Java并发想学并发的童鞋可以 单击我
• spring事务
  本地事务咨询可以单击我
  分布式事务咨询可以单击我
  Spring事务配置解惑单击我