文章目录
- 一、网关概述
- 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
官网地址: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的三大组件
- 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
官网地址: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。