【云原生】Gateway网关选型

网关一般分为流量网关和业务网关，流量网关负责接入所有的流量，并分发给不同的子系统，那在具体的业务接入之前，还有一层业务网关。

流量网关提供全局性的、与后端业务应用无关的策略，例如 HTTPS证书卸载、Web防火墙、全局流量监控、日志记录、黑白名单控制、接入请求到业务系统的负载均衡等，比如Kong。

业务网关业务紧耦合的、提供单个业务域级别的策略，如服务治理、身份认证,权限控制、日志输出、数据加密、熔断限流等等，比如K8s的Ingress。

流量网关负责南北向流量调度及安全防护，业务网关负责东西向流量调度及服务治理。

这张图展示了一个多层 Gateway 架构，其中有一个总的 Gateway 接入所有的流量(流量网关)，并分发给不同的子系统，还有第二级 Gateway 用于做各个子系统的接入 Gateway(业务网关)。可以看到，网关所管理的服务力度可粗可细。通过网关，我们可以把分布式架构组织成一个星型架构，由网络对服务的请求进行路由和分发。但是随着k8s的普及，Ingress 成为 K8s 生态的网关标准，促使流量网关和业务网关，合二为一。

常见的网关

• Nginx

k8s已经将Nginx与Ingress Controller合并为一个组件: ingress-nginx-controller

• OpenResty

Nginx + Lua 的高性能 Web 平台，其内部集成了大量精良的 Lua 库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态 Web 应用、Web 服务和动态网关。

• Kong

It is based on Nginx and OpenResty. Kong or Kong API Gateway is a cloud-native, platform-agnostic, scalable API Gateway distinguished for its high performance and extensibility via plugins.

By providing functionality for proxying, routing, load balancing, health checking, authentication (and more), Kong serves as the central layer for orchestrating microservices or conventional API traffic with ease.

Kong runs natively on Kubernetes thanks to its official Kubernetes Ingress Controller.

The top Kong features include:

• Advanced routing, load balancing, health checking - all configurable via a RESTful admin API or declarative configuration.

• Authentication and authorization for APIs using methods like JWT, basic auth, OAuth, ACLs and more.

• Proxy, SSL/TLS termination, and connectivity support for L4 or L7 traffic.

• Plugins for enforcing traffic controls, rate limiting, req/res transformations, logging, monitoring and including a plugin developer hub.

• Sophisticated deployment models like Declarative Databaseless Deployment and Hybrid Deployment (control plane/data plane separation) without any vendor lock-in.

• Native ingress controller support for serving Kubernetes.

• Apisix

It is based on Nginx and OpenResty. APISIX 是一个微服务API网关，具有高性能、可扩展性等优点。它基于 nginx（openresty）和 Lua 实现功能，借鉴了Kong的思路，将Kong底层的关系型数据库（Postgres）替换成了NoSQL型的 etcd，这使得 APISIX 相较于 Kong 在性能上有了很大提升，在启用各类插件的情况下，Apache APISIX 的性能是 Kong 的 10 倍，且Apisix是100%开源的，它的功能和Kong收费版的功能相当。

功能	APISIX	KONG
反向代理和路由	支持	支持
负载均衡	支持	支持
身份验证和授权	支持	支持
IP列表白名单/黑名单	支持	支持
限速和流控	支持	支持
请求变形	支持	支持
版本控制	支持	支持
断路器	支持	支持
多协议支持	支持	支持
缓存	支持	支持
数据库存储	etcd	Postgres/Cassandra

• Zuul

Zuul是Netflix公司开源的，使用了一系列不同类型的过滤器，被构建来支持动态路由、监视、弹性和安全性，使我们能够快速灵活地将功能应用到服务中。Zuul采用同步阻塞架构，依赖多线程来支持吞吐量的增长，性能较低。

• Zuul2

Netflix宣布了通用API网关Zuul的架构转型。Zuul原本采用同步阻塞架构，转型后叫作Zuul2，采用异步非阻塞架构。Zuul2和Zuul1在架构方面的主要区别在于，Zuul2运行在异步非阻塞的框架上，比如Netty。性能比Zuul高20%左右。

• Spring Cloud Gateway

SpringCloud Gateway是基于WebFlux框架实现的，而WebFlux框架底层则使用了高性能的Reactor模式通信框架Netty。在于高并发 非阻塞式通信的话就非常有优势了。它的目标是提供统一的路由方式且也是基于 Filter 链的方式提供了网关基本的功能，例如:安全，监控/指标,和限流、反向代理、鉴权、流量控制、熔断、日志监控... 是SpringCloud团队研发的，能够很好的融入到SpringCloud产品中。

• Envoy

Envoy was purpose-built to have a dynamic configuration API (no more config files and hot-reloads with dropped connections!), fine-grained visibility into backends with Service/Endpoint Discovery, and exceptional performance and tight tail-latency since it’s based on C++. These are very important considerations for organizations using modern proxy technology in performant and highly dynamic (ie, cloud) environments.

Lastly, Envoy is supported by hundreds of companies and is also where the innovation is happening in L7 proxies. Envoy was one of the first proxies to support HTTP2/gRPC on both sides of the connection, Web Assembly (for dynamic extension), and more recently, the HTTP 3 protocol.

性能对比

基于 Java 的异步化 API 网关

Kong

APISIX

Envoy Gateway

从以上性能数据可以看出，相同条件下：

• Envoy 的 TPS 可以达到 12W 左右；

• 基于 Java 的异步化 API 网关最高可到 2.8W 左右；

• 基于 Nginx 的 Kong，TPS 可以到 5W 左右；

• 基于 Nginx 并相较 Kong 有一定优化的 APISIX 可以到 9W 左右。

小结

1、Zuul2和SpringCloudGateway性能不够，且对应用框架有侵入，不考虑

2、Kong 和 Apisix 都是基于 Lua + nginx(OpenResty) 的，这在2010年之前是常见的方式，插件也丰富，非常实用，而且 Apisix 的性能也很强劲。但是随着不断拥抱云原生，他们的这种技术则变得过时老旧。

3、Envoy毕业于CNCF孵化器，是继Kubernetes和Prometheus之后的第三位CNCF毕业生，重新定义了网关的定位和能力，被誉为云原生网关，甚至被称之为下一代网关，已经有很多公司(Google、Alibaba、Wangyi)在积极布局做背书

• 它是一个轻量级的7层服务代理，围绕应用程序运行，通常采用sidecar样式，并提供服务发现和动态配置功能以及支持gRpc的负载平衡功能。

• 并且Envoy还对前端/边缘代理支持，在边缘使用相同的软件有很大的好处（可观察性、管理、相同的服务发现和负载平衡算法等）。 Envoy 具有一个功能集，使其非常适合作为大多数现代 Web 应用程序用例的边缘代理。这包括HTTP/1.1 HTTP/2 和 HTTP/3 支持，以及 HTTP L7 路由(能够根据路径、权限、内容类型、运行时及参数值等对请求进行路由和重定向)。

基于这两点，Envoy可以让南北和东西流量合并，不仅可以用做统一的流量网关，也可类似Service Mesh，采用sidecar样式，对应用做些基础设施的功能，比如负载均衡，降级熔断等。