开源API网关，到底哪个强？

cpus: ‘1’

memory: 256M

reservations:

memory: 256M

K6 通过 Nginx 网关的测试结果如下：

图片

每秒处理的请求数量是 1093，和不通过网关转发相比非常接近。

从功能上看，Nginx 可以满足用户对于 API 网关的大部分需求，可以通过配置和插件的方式来支持不同的功能，性能非常优秀。

缺点是没有管理的 UI 和管理 API，大部分的工作都需要手工配置 config 文件的方式来进行。商业版本的功能会更加完善。

Kong

====

Kong 是基于 NGINX 和 OpenResty 的开源 API 网关。

Kong 的总体基础结构由三个主要部分组成：NGINX 提供协议实现和工作进程管理，OpenResty 提供 Lua 集成并挂钩到 NGINX 的请求处理阶段。

而 Kong 本身利用这些挂钩来路由和转换请求。数据库支持 Cassandra 或 Postgres 存储所有配置。

图片

Kong 附带各种插件，提供访问控制，安全性，缓存和文档等功能。它还允许使用 Lua 语言编写和使用自定义插件。

Kong 也可以部署为 Kubernetes Ingress 并支持 GRPC 和 WebSockets 代理。

NGINX 提供了强大的 HTTP 服务器基础结构。它处理 HTTP 请求处理，TLS 加密，请求日志记录和操作系统资源分配（例如，侦听和管理客户端连接以及产生新进程）。

NGINX 具有一个声明性配置文件，该文件位于其主机操作系统的文件系统中。

虽然仅通过 NGINX 配置就可以实现某些 Kong 功能（例如，基于请求的 URL 确定上游请求路由），但修改该配置需要一定级别的操作系统访问权限，以编辑配置文件并要求 NGINX 重新加载它们。

而 Kong 允许用户执行以下操作：通过 RESTful HTTP API 更新配置。Kong 的 NGINX 配置是相当基本的：除了配置标准标头，侦听端口和日志路径外，大多数配置都委托给 OpenResty。

在某些情况下，在 Kong 的旁边添加自己的 NGINX 配置非常有用，例如在 API 网关旁边提供静态网站。在这种情况下，您可以修改 Kong 使用的配置模板。

NGINX 处理的请求经过一系列阶段。NGINX 的许多功能（例如，使用 C 语言编写的模块）都提供了进入这些阶段的功能（例如，使用 gzip 压缩的功能）。

虽然可以编写自己的模块，但是每次添加或更新模块时都必须重新编译 NGINX。为了简化添加新功能的过程，Kong 使用了 OpenResty。

OpenResty 是一个软件套件，捆绑了 NGINX，一组模块，LuaJIT 和一组 Lua 库。

其中最主要的是 ngx_http_lua_module一个NGINX 模块，该模块嵌入 Lua 并为大多数 NGINX 请求阶段提供 Lua 等效项。

这有效地允许在 Lua 中开发 NGINX 模块，同时保持高性能（LuaJIT 相当快），并且 Kong 用它来提供其核心配置管理和插件管理基础结构。

Kong 通过其插件体系结构提供了一个框架，可以挂接到上述请求阶段。从上面的示例开始，Key Auth 和 ACL 插件都控制客户端（也称为使用者）是否应该能够发出请求。

每个插件都在其处理程序中定义了自己的访问函数，并且该函数针对通过给定路由或服务启用的每个插件执行 kong.access()。

执行顺序由优先级值决定，如果 Key Auth 的优先级为 1003，ACL 的优先级为 950，则 Kong 将首先执行 Key Auth 的访问功能，如果它不放弃请求，则将执行 ACL，然后再通过将该 ACL 传递给上游 proxy_pass。

由于 Kong 的请求路由和处理配置是通过其 admin API 控制的，因此可以在不编辑底层 NGINX 配置的情况下即时添加和删除插件配置。

因为 Kong 本质上提供了一种在 API 中注入位置块（通过 API 定义）和配置的方法。它们通过将插件，证书等分配给这些 API。

我们使用以下的配置部署 Kong 到容器中（省略四个微服务的部署）：

version: ‘3.7’

volumes:

kong_data: {}

networks:

kong-net:

external: false

services:

kong:

image: “${KONG_DOCKER_TAG:-kong:latest}”

user: “${KONG_USER:-kong}”

depends_on:

- db

environment:

KONG_ADMIN_ACCESS_LOG: /dev/stdout

KONG_ADMIN_ERROR_LOG: /dev/stderr

KONG_ADMIN_LISTEN: ‘0.0.0.0:8001’

KONG_CASSANDRA_CONTACT_POINTS: db

KONG_DATABASE: postgres

KONG_PG_DATABASE: ${KONG_PG_DATABASE:-kong}

KONG_PG_HOST: db

KONG_PG_USER: ${KONG_PG_USER:-kong}

KONG_PROXY_ACCESS_LOG: /dev/stdout

KONG_PROXY_ERROR_LOG: /dev/stderr

KONG_PG_PASSWORD_FILE: /run/secrets/kong_postgres_password

secrets:

- kong_postgres_password

networks:

- kong-net

ports:

- “8080:8000/tcp”

- “127.0.0.1:8001:8001/tcp”

- “8443:8443/tcp”

- “127.0.0.1:8444:8444/tcp”

healthcheck:

test: [“CMD”, “kong”, “health”]

interval: 10s

timeout: 10s

retries: 10

restart: on-failure

deploy:

restart_policy:

condition: on-failure

db:

image: postgres:9.5

environment:

POSTGRES_DB: ${KONG_PG_DATABASE:-kong}

POSTGRES_USER: ${KONG_PG_USER:-kong}

POSTGRES_PASSWORD_FILE: /run/secrets/kong_postgres_password

secrets:

- kong_postgres_password

healthcheck:

test: [“CMD”, “pg_isready”, “-U”, “${KONG_PG_USER:-kong}”]

interval: 30s

timeout: 30s

retries: 3

r