架构设计(二) 互联网网关平台对比

现在在新的公司基础服务组（中台）待了快一年了，主要折腾公司的网关平台生态，我们公司网关平台是基于SpringCloud Gateway为基础构建的，属于从零到一构建整个网关平台的生态，目前核心服务基本完成，后期新的需求，POC和MVP都在路上，同时也觉的有必要看一看业界开源网关产品(排除几大共有云厂商的网关服务)，这也是写这篇博客的出发点。

主要分析对比下：Nginx，Zuul2，Spring Cloud Gateway, Kong,  APISIX

1. Nginx

网址：https://www.nginx.com/

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

网址：https://konghq.com/

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

网址：https://apisix.apache.org/

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阶段使用自定义负载均衡算法。
自定义路由：支持用户自己实现路由算法。