架构设计(二) 互联网网关平台对比
现在在新的公司基础服务组(中台)待了快一年了,主要折腾公司的网关平台生态,我们公司网关平台是基于SpringCloud Gateway为基础构建的,属于从零到一构建整个网关平台的生态,目前核心服务基本完成,后期新的需求,POC和MVP都在路上,同时也觉的有必要看一看业界开源网关产品(排除几大共有云厂商的网关服务),这也是写这篇博客的出发点。
主要分析对比下:Nginx,Zuul2,Spring Cloud Gateway, Kong, APISIX
1. Nginx
Nginx由内核和模块组成,内核的设计非常微小和简洁,完成的工作也非常简单,仅仅通过查找配置文件与客户端请求进行 URL 匹配,用于启动不同的模块去完成相应的工作。 Nginx架构大概如下图
Nginx 的模块直接被编译进 Nginx,因此属于静态编译方式。启动 Nginx 后,Nginx 的模块被自动加载,不像 Apache,首先将模块编译为一个 so 文件,然后在配置文件中指定是否进行加载。在解析配置文件时,Nginx 的每个模块都有可能去处理某个请求,但是同一个处理请求只能由一个模块来完成。
Nginx 在启动后,会有一个 Master 进程和多个 Worker 进程,Master 进程和 Worker 进程之间是通过进程间通信进行交互的,如图所示。Worker 工作进程的阻塞点是在像 select()、epoll_wait() 等这样的 I/O 多路复用函数调用处,以等待发生数据可读 / 写事件。Nginx 采用了异步非阻塞的方式来处理请求,也就是说,Nginx 是可以同时处理成千上万个请求的。一个 Worker 进程可以同时处理的请求数只受限于内存大小,而且在架构设计上,不同的 Worker 进程之间处理并发请求时几乎没有同步锁的限制,Worker 进程通常不会进入睡眠状态,因此,当 Nginx 上的进程数与 CPU 核心数相等时(最好每一个 Worker 进程都绑定特定的 CPU 核心),进程间切换的代价是最小的。
nginx优缺点
Nginx优点: 1、工作在网络7层之上,可针对http应用做一些分流的策略,如针对域名、目录结构,它的正规规则比HAProxy更为强大和灵活,所以,目前为止广泛流行。 2、Nginx对网络稳定性的依赖非常小,理论上能ping通就能进行负载功能。 3、Nginx安装与配置比较简单,测试也比较方便,基本能把错误日志打印出来。 4、可以承担高负载压力且稳定,硬件不差的情况下一般能支撑几万次的并发量,负载度比LVS小。 5、Nginx可以通过端口检测到服务器内部的故障,如根据服务器处理网页返回的状态码、超时等,并会把返回错误的请求重新提交到另一个节点。 6、不仅仅是优秀的负载均衡器/反向代理软件,同时也是强大的Web应用服务器。LNMP也是近些年非常流行的Web架构,在高流量环境中稳定性也很好。 7、可作为中层反向代理使用。 8、可作为静态网页和图片服务器。 9、Nginx社区活跃,第三方模块非常多,相关的资料在网上比比皆是。 Nginx缺点: 1、适应范围较小,仅能支持http、https、Email协议。 2、对后端服务器的健康检查,只支持通过端口检测,不支持url来检测。比如用户正在上传一个文件,而处理该上传的节点刚好在上传过程中出现故障,
Nginx会把上传切到另一台服务器重新处理,而LVS就直接断掉了,如果是上传一个很大的文件或者很重要的文件的话,用户可能会因此而不满。
Nginx应用场景: HTTP服务器, 静态服务器,反向代理, 负载均衡, 动静分离
2. Zuul2
网址:https://github.com/Netflix/zuul
Zuul是Netflix开源的微服务网关组件,它可以和Eureka、Ribbon、Hystrix等组件配合使用。Zuul的核心是一系列的过滤器,这些过滤器可以完成以下功能:
身份认证与安全:识别每个资源的验证要求,并拒绝那些与要求不符的请求。
审查与监控:与边缘位置追踪有意义的数据和统计结果,从而带来精确的生产视图。
动态路由:动态地将请求路由到不同的后端集群。
压力测试:逐渐增加指向集群的流量,以了解性能。
负载分配:为每一种负载类型分配对应容量,并弃用超出限定值的请求。
静态响应处理:在边缘位置直接建立部分响应,从而避免其转发到内部集群。
多区域弹性:跨越 AWS Region 进行请求路由,旨在实现 ELB(Elastic Load Balancing,弹性负载均衡)使用的多样化,以及让系统的边缘更贴近系统的使用者。
Zuul1是基于Servlet 框架构建,采用的是阻塞和多线程方式,即一个线程处理一次连接请求,这种方式在内部延迟严重、设备故障较多情况下会引起存活的连接增多和线程增加的情况发生。
正式基于此,Netflix公司积极推出了2.0版本。Zuul2.x 最大的改进就是基于Netty Server 实现了异步IO来接入请求,同时基于Netty Client 实现了到后端业务服务API的请求。这样就可以实现更高的性能、更低的延迟。此外也调整了filter类型,将原来的三个核心filter 显式命名为:Inbound Filter、Endpoint Filter 和 Outbound Filter。
Zuul2的核心功能:Service Discovery,Load Balancing,Connection Pooling。Status Categories,Retries,Request Passport,Request Attempts,Origin Concurrency Protection,HTTP/2,Mutual TLS,Proxy Protocol,GZip,WebSockets
Zuul2的应用场景:io密集的任务,大请求或者大文件,队列的流式数据,超大量的连接
3. Spring Cloud Gateway
网址:https://docs.spring.io/spring-cloud-gateway/docs/current/reference/html/
Spring Cloud Gateway 基于 Java 8、Spring 5.0、Spring Boot 2.0、Project Reactor,发展的比 Zuul 2 要早,目前也是 Spring Cloud 全家桶的一部分。SpringCloud Gateway 作为 Spring Cloud 生态系统中的网关,目标是替代 Zuul,在Spring Cloud 2.0以上版本中,没有对新版本的Zuul 2.0以上最新高性能版本进行集成。而为了提升网关的性能,SpringCloud Gateway是基于WebFlux框架实现的,而WebFlux框架底层则使用了高性能的Reactor模式通信框架Netty。Spring Cloud Gateway 的目标,不仅提供统一的路由方式,并且基于 Filter 链的方式提供了网关基本的功能,例如:安全,监控/指标,和限流。
SpringCloud官方,对SpringCloud Gateway 特征介绍如下:
(1)基于 Spring Framework 5,Project Reactor 和 Spring Boot 2.0
(2)集成 Hystrix 断路器
(3)集成 Spring Cloud DiscoveryClient
(4)Predicates 和 Filters 作用于特定路由,易于编写的 Predicates 和 Filters
(5)具备一些网关的高级功能:动态路由、限流、路径重写
Spring Cloud Gateway应用场景:反向代理, 鉴权,流量控制,熔断, 日志监控, 编辑请求头和请求体, 编辑响应体的参数, 黑白名单, 路径重写
接下来要介绍的两个网关平台是近几年比较火的网关平台
4. Kong
Kong 的基本架构
Kong基于Nginx来实现Api Gateway基本的负载均衡、反向代理等功能。由C语言编写的Nginx有着超高的性能和低内存开销
OpenResty是一个基于Nginx的库,它将Nginx进行封装,并提供了整个生命周期的Hook( 钩子 ),使得开发者可以通过Lua脚本对Nginx进行插件化管理
Kong使用PostgreSQL或Cassandra来对其配置文件进行持久化存储,使得可以进行集群管理
Kong提供了插件模型,使用Lua脚本来对Nginx整个生命周期进行扩展。实现了一些常用插件( 限流、熔断、验权等 )
Kong的特点
Cloud-Native:与平台无关,Kong可以在任何平台上运行-从裸机到容器-并且可以在本机上的每个云上运行。 Kubernetes-Native:使用官方的Ingress Controller通过本地Kubernetes CRD声明性地配置Kong,以路由和连接所有L4 + L7通信。 动态负载平衡:跨多个上游服务对流量进行负载平衡。 基于哈希的负载平衡:具有一致的哈希/粘性会话的负载平衡。 熔断器:智能跟踪不健康的上游服务。 运行状况检查:主动和被动监视您的上游服务。 服务发现:在第三方DNS解析器(例如Consul)中解析SRV记录。 无服务器:直接从Kong调用和保护AWS Lambda或OpenWhisk功能。 WebSockets:通过WebSockets与您的上游服务进行通信。 gRPC:与gRPC服务进行通信,并通过日志记录和可观察性插件观察流量 OAuth2.0:轻松将OAuth2.0身份验证添加到您的API。 日志记录:通过HTTP,TCP,UDP或磁盘记录对系统的请求和响应。 安全性:ACL,僵尸程序检测,允许/拒绝IP等… Syslog:登录到系统日志。 SSL:为基础服务或API设置特定的SSL证书。 监视:实时监视提供关键的负载和性能服务器指标。 转发代理:使Kong连接到中间透明HTTP代理。 认证:HMAC,JWT,基本等。 速率限制:基于许多变量来阻止和限制请求。 转换:添加,删除或处理HTTP请求和响应。 缓存:在代理层缓存并提供响应。 CLI:从命令行控制Kong群集。 REST API:Kong可以使用其RESTful API进行操作,以实现最大的灵活性。 地理复制:跨不同区域的配置始终是最新的。 故障检测和恢复:如果您的Cassandra节点之一发生故障,则Kong不会受到影响。 集群:所有Kong节点自动加入集群,并在各个节点之间更新其配置。 可扩展性:Kon本质上是分布式的,只需添加节点即可水平扩展。 性能:Kong通过扩展和使用NGINX作为核心轻松处理负载。 插件:可扩展的体系结构,用于向Kong和API添加功能。
5. APISIX
APISIX 是一个云原生、高性能、可扩展的微服务 API 开源网关,基于OpenResty(Nginx+Lua)和etcd来实现,对比传统的API网关,具有动态路由和热插件加载的特点。系统本身自带前端,可以手动配置路由、负载均衡、限速限流、熔断、金丝雀发布、身份验证、可监控等插件,操作方便。可以使用Apache APISIX来处理传统的南北流量,以及服务之间的东西流量。它也可以用作k8s入口控制器。
您可以将Apache APISIX用作处理所有业务数据的流量入口,包括动态路由,动态上游,动态证书,A / B测试,金丝雀发布,蓝绿色部署,限制速率,防御恶意攻击,指标,监视警报,服务可观察性,服务治理等。
支持所有平台
原生云:与平台无关,无供应商锁定,APISIX可以从裸机运行到Kubernetes。
运行环境:同时支持OpenResty和Tengine。
支持ARM64:不用担心基础技术的锁定。
多协议
TCP / UDP代理:动态TCP / UDP代理。 动态MQTT代理:支持按client_id负载均衡,同时支持MQTT 3.1.*,5.0。 gRPC代理:代理gRPC通信。 gRPC转码:支持协议转码,以便客户端可以使用HTTP / JSON访问您的gRPC API。 代理Websocket代理协议代理Dubbo:基于Tengine的Dubbo代理。 HTTP(S)转发代理。 SSL:动态加载SSL证书。
全动态
热更新和热插件:不断更新其配置和插件,而无需重新启动
代理重写:在发送到上游之前,支持重写主机,uri,架构,enable_websocket,请求标头。
响应重写:为客户端设置自定义的响应状态代码,正文和标头。
无服务:在APISIX的每个阶段调用功能。
动态负载均衡:循环负载均衡。
基于哈希的负载均衡:具有一致的哈希会话的负载均衡。
健康检查:在上游节点上启用健康检查,并在负载均衡期间自动过滤不正常的节点,以确保系统稳定性。
熔断器:智能跟踪不健康的上游服务。
代理镜像:提供镜像客户端请求的功能。
细粒度路由
支持全路径匹配和前缀匹配。 支持所有Nginx内置变量作为路由条件,因此您可以使用cookie,args等作为路由条件来实现金丝雀发布,A / B测试等。 支持各种运算符作为判断条件用于路由,例如{“ arg_age”,“>”,24} 支持自定义路由匹配功能 IPv6:使用IPv6来匹配路由。 支持TTL 支持优先级 支持批量Http请求
安全认证
身份验证:密钥身份验证,JWT,基本身份验证,wolf-rbac IP白名单/黑名单 引用白名单/黑名单 IdP:支持外部身份验证服务,例如Auth0,okta等,用户可以使用它来连接到OAuth 2.0和其他身份验证方式。 Limit-req : 请求限流(基于漏桶算法) Limit-count : 连接数限流 Limit-conn : 并发限流 Anti-ReDoS(正则表达式拒绝服务):Anti ReDoS的内置策略,无需配置。 CORS为您的API启用CORS(跨域资源共享)。 URI阻断:按URI阻止客户端请求。 请求验证
友好便捷运维
OpenTracing:支持Apache Skywalking和Zipkin 结合第三方服务发现的组件一起使用:除了内置的etcd外,它还支持Consul和Nacos DNS发现模式,以及Eureka 监控和统计:Prometheus 集群:APISIX节点是无状态的,创建了配置中心,请参阅etcd集群指南。 高可用:支持在同一集群中配置多个etcd地址。 控制台:内置控制台可在控制台上操作APISIX。 版本控制:支持操作回滚。 CLI:通过命令行启动\停止\重新加载APISIX。 独立模式:支持从本地yaml文件加载路由规则。在kubernetes(k8s)下,更加友好。 全局规则:允许针对所有请求运行任何插件,例如:限流插件,IP黑白名单等。 高性能:单核QPS达到18k,平均延迟小于0.2毫秒。 故障注入 REST Admin API:使用REST Admin API控制Apache APISIX(默认情况下仅允许127.0.0.1访问),您可以修改conf / config.yaml中的allow_admin字段以指定允许调用IP的IP列表。
管理员API。另请注意,Admin API使用密钥身份验证来验证调用方的身份。部署前需要修改conf / config.yaml中的admin_key字段,以确保安全。 支持日志导出:将访问日志导出到外部日志管理工具。 (HTTP记录器,TCP记录器,Kafka记录器,UDP记录器)
高度可扩展
自定义插件:允许hook在公共阶段,例如rewrite, access, header filer, body filter and log阶段等,还允许hooK在balancer阶段。
自定义负载均衡算法:可以在balancer阶段使用自定义负载均衡算法。
自定义路由:支持用户自己实现路由算法。