前言
日常测试工作中，开发提到的网关到底什么意思？本篇文章就分享一下所谓的网关究竟是什么技术、有什么好处，以及常见的网关组件有那些。
网关概述
如果没有网关？
1、前后端分离，页面会对接很多域（微服务），客户端处理的复杂性很高；
2、存在安全隐患，随着微服务暴露接口的增加，服务器的受攻击面积也会增加；
3、重复鉴权；服务鉴权功能分布在每个微服务中处理，客户端对于每个服务的提供者都需要重复鉴权；
4、客户端需要针对不同的请求协议做适配：因为在后端的微服务架构中，可能不同的服务采用的协议不同，比如：HTTP、RPC 等；客户端调用多个服务时，需要对不同的协议进行适配；
5、跨域问题；
6、客户端难以重构，因为微服务是动态拆分的，域名会改变；
微服务网关有什么好处呢？
针对没有网关时的缺点，微服务网关的诞生恰恰是解决这些问题的；
提供统一的访问入口，类似于门面，所有的请求都会先经过网关这一层，降低了服务器的受攻击面积；不管微服务怎么拆分，域名都不会变；也降低了客户端重构的难度。
提供统一的跨域问题解决方案；
提供统一的日志记录操作，进行用户打点，做用户画像，进行统一的监控；
提供统一的协议：如果后端微服务使用的协议不同，或存在一些对前端不友好的协议，可以在网关中转换为浏览器友好的、统一的协议。
认证授权；黑白名单机制，做路由转发。
限流，保护微服务；
整合微服务：API 网关层可以把后端的多个服务进行整合，提供统一的业务接口，形成若干套业务系统。
请求转发：可以根据不同的请求路径 pattern，进行请求的转发，并且可以基于网关实现内网 和 外网的隔离。外网采用 HTTP 提供服务，内网之间使用 RPC 通信（RPC 通信更快）。
网关有哪些分类呢？
网关大体上分为两类：独立网关和业务网关；
独立网关：像 nginx、Kong、Trsefik 属于独立网关，不关注业务代码；
业务网关：像 Zuul、Gateway 属于业务网关，他们在意业务代码的实现语言；
网关有哪些技术组件？
服务网关是所有微服务的唯一入口，在做技术选型时，网关组件应该具备的特性：
1、高可用：保证 7 * 24 小时可用，提供提供稳定可靠的服务；
2、高性能；所有的请求都会经过服务网关，它要承受的压力是很大的，所以它必须具备良好的性能，以应对高并发请求。
3、高安全性：要能防止外部的恶意访问，确保内网各个微服务的安全。
4、高可扩展性：服务网关是一个非业务的模块，除了要提供流量管控、路由转发、日志监控、认证鉴权等能力；同时要对以后非业务功能的扩展提供良好的兼容性。
现在的一些常见的网关技术：Nginx、OpenResty、Zuul、Spring Cloud Gateway 等。
Nginx
Nginx 是⼀款轻量级的 Web 服务器、反向代理服务器，由于它的内存占⽤少，启动极快，⾼并发能⼒强，在互联⽹项⽬中⼴泛应⽤。一般 Nginx 的上层还有一个负载均衡器，如 LVS，对 Nginx 做负载均衡。
特点：
1、Nginx 以事件驱动的⽅式编写，所以有⾮常好的性能；
2、在性能上，Nginx 占⽤很少的系统资源，能⽀持更多的并发连接，达到更⾼的访问效率；
3、在功能上，Nginx 是优秀的代理服务器和负载均衡服务器；
4、在安装配置上，Nginx 安装简单、配置灵活；
5、Nginx 支持热部署，启动速度特别快，可以在不间断服务的情况下对软件版本或配置进行升级；nginx -s reload。
在微服务的体系之下，Nginx 被越来越多的项目所采用，作为网关来使用，配合 Lua 做限流、熔断等控制。
此外，Nginx 可以用来做正向代理、反向代理；
正向代理：
1、正向代理 “代理” 的是客户端，客户端知道⽬标，⽽⽬标不知道客户端是通过 VPN 访问的；
2、由于防⽕墙的原因，我们并不能直接访问⾕歌，那么我们可以借助 VPN 来实现。
反向代理：
1、反向代理 “代理” 的是服务器端，这⼀个过程对于客户端⽽⾔是透明的；
2、当我们在外⽹访问 google 的时候，google 会进⾏⼀个转发，代理到他们内⽹去，这就是所谓的反向代理；
OpenResty
OpenResty 是⼀个基于 Nginx 与 Lua 的⾼性能 Web 平台，其内部集成了⼤量的 Lua 库、第三⽅模块。⽤于⽅便地搭建能够处理超⾼并发、扩展性极⾼的动态 Web 应⽤、Web 服务和动态⽹关；快速构造出⾜以胜任 10K 乃⾄ 1000K 以上单机并发连接的⾼性能 Web 应⽤系统。
OpenResty 的⽬标是让我们的 Web 服务直接跑在 Nginx 服务内部，充分利⽤ Nginx 的⾮阻塞 I/O 模型；不仅仅对 HTTP 客户端请求，甚⾄于对远程后端（诸如 MySQL、PostgreSQL、Memcached、Redis 等）都能进⾏⼀致的⾼性能响应。
本质上就是将 Lua 脚本嵌入到 Nginx 中，在每个 nginx 的进程中都嵌入一个 LuaJIT 虚拟机来执行 Lua 脚本；
在接收客户端请求时，通过在不同的阶段挂载不同的 Lua 脚本，实现拦截请求进行前置/后置处理；
OpenResty 实现网关功能的核心就是在 11 个步骤中挂载不同的 Lua 脚本实现功能的扩展。
特点：
轻、非常轻，Lua 脚本和 Nginx 耦合度非常低。
Zuul
Zuul 作为微服务系统的⽹关组件，是从设备和⽹站到 Netflix 流应⽤程序后端的所有请求的前⻔，其旨在实现动态路由，监控，弹性和安全性。
Zuul 的核心是由一些列的过滤器 Filter 组成，它定义了四种标准类型的过滤器，对应于请求的整个生命周期：
zuul 有两个版本：zuul1 和 zuul2，⽬前 spring cloud 只集成了 zuul1。zuul2 是 Netflix 在 2018 年 5 ⽉推出，它最⼤的特点就是⽀持异步调⽤（而 zuul1 仅⽀持同步) ，不过可惜 springcloud 并没有计划集成 zuul2，⽽且还推出 springcloud gateway 来替代 zuul1。这也标志着 zuul 已经渐渐被 Spring Cloud 抛弃，不建议使用了。
Zuul1 和 Zuul2 对比？
从编程模型上来看：Zuul1 同步阻塞编程模型简单，⻔槛低，开发运维⽅便，容易调试定位问题；Zuul2 异步非阻塞模型复杂，⻔槛⾼，调试不⽅便。
从埋点来看：Zuul1 监控埋点容易，⽐如和调⽤链监控⼯具 CAT 集成；而 Zuul2 监控埋点困难，比如用就 CAT 不好埋点；
从成熟度来看：Zuul1 开源了很久，稳定成熟，坑基本被踩平；而 Zuul2 2018 年才开源，实际落地案例不多，可能有 bug 需要踩坑。
从请求量来看：Netflix 是要应对每⽇千亿级流量，如果公司连亿级都达不到，也没必要用 Zuul2；
Zuul 的改进：Zuul1 可以使⽤ Servlet 3.0 规范⽀持的 AsyncServlet 进⾏优化，进而实现前端异步，⽀持更多的连接数，达到和 Zuul2 ⼀样的效果了；并且还不用引入太多异步复杂性
Spring Cloud Gateway
SpringCloudGateway 是由 WebFlux+Netty+Reactor 实现的响应式的 API ⽹关。
Spring Cloud Gateway 旨在为微服务架构提供⼀种简单且有效的 API 路由管理⽅式，并基于 Filter 的⽅式提供⽹关的基本功能，例如说安全认证、监控、限流等等；
Spring Cloud Gateway 定位于取代 Netflix Zuul，成为 SpringCloud ⽣态系统的新⼀代⽹关；相⽐ Zuul 来说，SpringCloudGateway 提供更优秀的性能，更强⼤的有功能。
Spring Cloud Gateway 的几个核心概念：
路由：路由是⽹关最基础的部分，路由信息由⼀个 ID、⼀个⽬的 URL、⼀组断⾔和⼀组 Filter 组成。如果断⾔路由为真，则说明请求的 URL 和配置匹配。
断⾔：作为路由的匹配条件。
过滤器：过滤器 Filter 将会对请求和响应进⾏修改处理。
总结
网关通常作为微服务的门面统一请求的入口，以方便鉴权、协议匹配、整合微服务等操作；可用的网关技术包括两大类：
不关注业务代码的独立网关：像 nginx、OpenResty；
在意业务代码的实现语言的业务网关：像 Zuul、Spring Cloud Gateway；
一般 SpringCloud 生态选择使用 Spring Cloud Gateway；对于很多不上微服务的项目，常使用 nginx 做多个实例的统一入口；对于一些需要在 nginx 中做定制功能的，往往选择 Nginx + Lua 脚本的方式。
欢迎加我微信 lvceshikaifa，免费面试辅导、学习资料、简历模板获取。也可加入学习群，聊面试，聊技术，一起学习，一起加薪。