【SCG | 微服务网关一】为什么要有网关、生产环境如何选择网关

一、网关概述

1、如果没有网关？

相信一些老程序原都经过没有网关的日子，不使用网关时，会有很多问题：

1、前后端分离，页面会对接很多域（微服务），客户端处理的复杂性很高；

2、存在安全隐患，随着微服务暴露接口的增加，服务器的受攻击面积也会增加；

3、重复鉴权；服务鉴权功能分布在每个微服务中处理，客户端对于每个服务的提供者都需要重复鉴权；

4、客户端需要针对不同的请求协议做适配：因为在后端的微服务架构中，可能不同的服务采用的协议不同，比如：HTTP、RPC等；客户端调用多个服务时，需要对不同的协议进行适配；

5、跨域问题；

6、客户端难以重构，因为微服务是动态拆分的，域名会改变；

2、微服务网关的作用？

针对没有网关时的缺点，微服务网关的诞生恰恰是解决这些问题的；

1. 提供统一的访问入口，类似于门面，所有的请求都会先经过网关这一层，降低了服务器的受攻击面积；不管微服务怎么拆分，域名都不会变；也降低了客户端重构的难度。

2. 提供统一的跨域问题解决方案；

3. 提供统一的日志记录操作，进行用户打点，做用户画像，进行统一的监控；

4. 提供统一的协议：如果后端微服务使用的协议不同，或存在一些对前端不友好的协议，可以在网关中转换为浏览器友好的、统一的协议。

5. 认证授权；黑白名单机制，做路由转发。

6. 限流，保护微服务；

7. 整合微服务：API网关层可以把后端的多个服务进行整合，提供统一的业务接口，形成若干套业务系统。

8. 请求转发：可以根据不同的请求路径pattern，进行请求的转发，并且可以基于网关实现内网 和 外网的隔离。外网采用HTTP提供服务，内网之间使用RPC通信（RPC通信更快）。

3、网关分类

网关大体上分为两类：独立网关和业务网关；

• 独立网关：像nginx、Kong、Trsefik属于独立网关，不关注业务代码；

• 业务网关：像Zuul、Gateway属于业务网关，他们在意业务代码的实现语言；

二、网关技术选型

服务网关是所有微服务的唯一入口，在做技术选型时，网关组件应该具备的特性：

1、高可用：保证7 * 24 小时可用，提供提供稳定可靠的服务；

2、高性能；所有的请求都会经过服务网关，它要承受的压力是很大的，所以它必须具备良好的性能，以应对高并发请求。

3、高安全性：要能防止外部的恶意访问，确保内网各个微服务的安全。

4、高可扩展性：服务网关是一个非业务的模块，除了要提供流量管控、路由转发、日志监控、认证鉴权等能力；同时要对以后非业务功能的扩展提供良好的兼容性。

现在的一些网关技术：traefix、Nginx、OpenResty、Kong、Zuul、Spring Cloud Gateway等。

1、traefix

官网地址：https://www.traefik.tech/。

Traefik 是⼀款开源的边缘路由器，可让我们轻松地发布服务；traefik 与众不同的点在于它能够⾃动发现适合服务的配置；并发现哪个服务应该服务于哪个请求；其⽆需维护和同步配置⽂件：所有操作都会⾃动实时完成（⽆重启，不⽤中断服务）；我们只需花时间于系统开发和部署新功能，⽽不需要配置和维护其⼯作状态。

另外：Traefik ⽀持多种集群技术，如 Kubernetes，Kubernetes, Docker, Docker Swarm, AWS, Mesos, Marathon，⽀持列表 ; 并且可以同时处理多个 providers。（它甚⾄适⽤于在裸机上运⾏的传统软件。）所以它主要用于云原生中。

2、Nginx

官网地址：http://nginx.org/en/

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会进⾏⼀个转发，代理到他们内⽹去，这就是所谓的反向代理；

3、OpenResty

官网地址：https://openresty.org/cn/；

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耦合度非常低。

4、Kong

官网地址：https://docs.konghq.com/

Kong是⼀款基于OpenResty（Nginx + Lua模块）编写的⾼可⽤、易扩展、开源的API Gateway。Kong基于NGINX和Apache Cassandra / PostgreSQL构建，提供提供易于使⽤的RESTful API来操作和配置API管理系统；它可以⽔平扩展多个Kong服务器，通过前置的负载均衡配置把请求均匀地分发到各个Server，来应对⼤批量的⽹络请求。

Kong的三大组件

1. Kong Server：基于nginx的服务器，用来接收API请求；
2. Apache Cassandra / PostgreSQL：用来存储操作数据；
3. Kong dashboard：官方推荐UI管理工具；

Kong采⽤插件机制进⾏功能定制，插件集（可以是0或N个）在API请求响应循环的⽣命周期中被执⾏。插件使⽤Lua编写，⽬前已有⼏个基础功能：HTTP基本认证、密钥认证、CORS（Cross-Origin Resource Sharing，跨域资源共享）、TCP、UDP、⽂件⽇志、API请求限流、请求转发以及Nginx监控。

Nginx、OpenRetry、Kong三个项目的关系

Nginx、OpenRestry、Kong这三个项⽬紧密相连：

1. Nginx是模块化设计的反向代理软件，C语⾔开发;

2. OpenResty是以Nginx为核⼼的Web开发平台，可以解析执⾏Lua脚本；

3. Kong是⼀个OpenResty应⽤，⼀个api gateway。

OpenResty与Lua的关系类似于Jvm与Java，不过OpenResty是基于nginx的，主要⽤于Web、API类应⽤。

Kong和Traefik对比

Kong 和 Traefik 不依赖于后端服务的语⾔，是⽐较独⽴的⽹关服务，经常被⽤于云原⽣服务。

1. 从开源社区活跃度、成熟度来看：Kong和Traefik都⽐较好；
2. 从性能⻆度来看：Kong的性能要领先一些；
3. 从状态存储来看：Traefik通过Kubernetes存储状态，Kong需要使⽤Postgres 或 Cassandra来存储状态；

所以如果应用是基于K8S来发布部署的，最好还是使⽤Traefik，会更⽅便⼀些。

而：Zuul 和 Spring Cloud Gateway 结合 Spring Cloud ⽣态 使⽤效果⽐较好，并且这两者和业务结合⽐较紧密。

5、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对比？

1. 从编程模型上来看：Zuul1 同步阻塞编程模型简单，⻔槛低，开发运维⽅便，容易调试定位问题；Zuul2 异步非阻塞模型复杂，⻔槛⾼，调试不⽅便。

2. 从埋点来看：Zuul1 监控埋点容易，⽐如和调⽤链监控⼯具 CAT 集成；而 Zuul2监控埋点困难，比如用就CAT 不好埋点；

3. 从成熟度来看：Zuul1开源了很久，稳定成熟，坑基本被踩平；而Zuul2 2018年才开源，实际落地案例不多，可能有 bug 需要踩坑。

4. 从请求量来看：Netflix 是要应对每⽇千亿级流量，如果公司连亿级都达不到，也没必要用Zuul2；

5. **Zuul的改进：**Zuul1可以使⽤ Servlet 3.0 规范⽀持的 AsyncServlet 进⾏优化，进而实现前端异步，⽀持更多的连接数，达到和 Zuul2 ⼀样的效果了；并且还不用引入太多异步复杂性

6、Spring Cloud Gateway

官网地址：https://spring.io/projects/spring-cloud-gateway#learn

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、Kong、Traefik；

• 在意业务代码的实现语言的业务网关：像Zuul、Spring Cloud Gateway；

一般SpringCloud生态选择使用Spring Cloud Gateway；云原生中处于方便使用Traefik；对于很多不上微服务的项目，常使用nginx做多个实例的统一入口；对于一些需要在nginx中做定制功能的，往往选择Nginx + Lua脚本的方式，即OpenResty、Kong。