【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。

本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
THE END
分享
二维码
< <上一篇
下一篇>>