【云原生&微服务＞SCG网关篇一】为什么要有网关、生产环境如何选择网关

迷南。 2023-09-28 14:47 42阅读 0赞

#### 文章目录 ####

*  一、网关概述
 *   *  1、如果没有网关？
     *  2、微服务网关的作用？
     *  3、网关分类
 *  二、网关技术选型
 *   *  1、traefix
     *  2、Nginx
     *  3、OpenResty
     *  4、Kong
     *   *  Nginx、OpenRetry、Kong三个项目的关系
         *  Kong和Traefik对比
     *  5、Zuul
     *   *  Zuul1和Zuul2对比？
     *  6、Spring Cloud Gateway
 *  三、总结

## 一、网关概述 ##

### 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 ###

![在这里插入图片描述][961055c8f3154e95ba71e06f20a723df.png]

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

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

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

### 2、Nginx ###

![在这里插入图片描述][e57309b9645e45cabed5ba8947e8d9ce.png]

官网地址：[http://nginx.org/en/][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 ###

![在这里插入图片描述][e0dda76cae3d4ab09830b3fd2b56da72.png]

官网地址：[https://openresty.org/cn/][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 ###

![在这里插入图片描述][2518d23002554556b78fa7efcf9ec242.png]

官网地址：[https://docs.konghq.com/][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组成，它定义了四种标准类型的过滤器，对应于请求的整个生命周期：

![在这里插入图片描述][f1b853b4b4cb48d9aae34195e095182c.png]

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][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。

[961055c8f3154e95ba71e06f20a723df.png]: https://img-blog.csdnimg.cn/961055c8f3154e95ba71e06f20a723df.png
[https_www.traefik.tech]: https://www.traefik.tech/
[e57309b9645e45cabed5ba8947e8d9ce.png]: https://img-blog.csdnimg.cn/e57309b9645e45cabed5ba8947e8d9ce.png
[http_nginx.org_en]: http://nginx.org/en/
[e0dda76cae3d4ab09830b3fd2b56da72.png]: https://img-blog.csdnimg.cn/e0dda76cae3d4ab09830b3fd2b56da72.png
[https_openresty.org_cn]: https://openresty.org/cn/
[2518d23002554556b78fa7efcf9ec242.png]: https://img-blog.csdnimg.cn/2518d23002554556b78fa7efcf9ec242.png
[https_docs.konghq.com]: https://docs.konghq.com/
[f1b853b4b4cb48d9aae34195e095182c.png]: https://img-blog.csdnimg.cn/f1b853b4b4cb48d9aae34195e095182c.png
[https_spring.io_projects_spring-cloud-gateway_learn]: https://spring.io/projects/spring-cloud-gateway#learn