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

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

文章目录

​​一、网关概述​​

​​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、微服务网关的作用？

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

提供统一的​​访问入口​​，类似于门面，所有的请求都会先经过网关这一层，​​降低了服务器的受攻击面积​​；不管微服务怎么拆分，域名都不会变；也降低了客户端重构的难度。提供统一的​​跨域问题解决方案​​；提供统一的​​日志记录​​操作，进行用户打点，做用户画像，进行​​统一的监控​​；提供​​统一的协议​​：如果后端微服务使用的协议不同，或存在一些对前端不友好的协议，可以在网关中转换为浏览器友好的、统一的协议。​​认证授权​​；黑白名单机制，做路由转发。​​限流​​，保护微服务；​​整合微服务​​：API网关层可以把后端的多个服务进行整合，提供统一的业务接口，形成若干套业务系统。​​请求转发​​：可以根据不同的请求路径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

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

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

2、Nginx

官网地址：​​nginx -s reload。在微服务的体系之下，Nginx被越来越多的项目所采用，作为网关来使用，配合Lua做限流、熔断等控制。

此外，Nginx可以用来做正向代理、反向代理；

正向代理：

1、正向代理​​“代理”的是客户端​​​，​​客户端知道⽬标​​，⽽⽬标不知道客户端是通过VPN访问的；2、由于防⽕墙的原因，我们并不能直接访问⾕歌，那么我们可以借助VPN来实现。

反向代理：

1、反向代理​​“代理”的是服务器端​​​，这⼀个过程对于客户端⽽⾔是透明的； 2、当我们在外⽹访问google的时候，google会进⾏⼀个转发，代理到他们内⽹去，这就是所谓的反向代理；

3、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

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

Kong的三大组件

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

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

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

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

Nginx是模块化设计的反向代理软件，C语⾔开发;OpenResty是以Nginx为核⼼的Web开发平台，可以解析执⾏Lua脚本；Kong是⼀个OpenResty应⽤，⼀个api gateway。

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

Kong和Traefik对比

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

从开源社区活跃度、成熟度来看：Kong和Traefik都⽐较好；从性能⻆度来看：Kong的性能要领先一些；从状态存储来看：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对比？

从编程模型上来看：Zuul1 同步阻塞编程模型简单，⻔槛低，开发运维⽅便，容易调试定位问题；Zuul2 异步非阻塞模型复杂，⻔槛⾼，调试不⽅便。从埋点来看：Zuul1 监控埋点容易，⽐如和调⽤链监控⼯具 CAT 集成；而 Zuul2监控埋点困难，比如用就CAT 不好埋点；从成熟度来看：Zuul1开源了很久，稳定成熟，坑基本被踩平；而Zuul2 2018年才开源，实际落地案例不多，可能有 bug 需要踩坑。从请求量来看：Netflix 是要应对每⽇千亿级流量，如果公司连亿级都达不到，也没必要用Zuul2；**Zuul的改进：**Zuul1可以使⽤ Servlet 3.0 规范⽀持的 AsyncServlet 进⾏优化，进而实现前端异步，⽀持更多的连接数，达到和 Zuul2 ⼀样的效果了；并且还不用引入太多异步复杂性

6、Spring Cloud Gateway

官网地址：​​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。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。