第2章：常见API网关介绍 - Nginx、Kong、APISIX

聊到API网关，很多人第一个想到的就是Nginx。确实，Nginx是这个领域的基石，但它不是唯一的选择。这些年我在不同的项目里用过好几款网关，各有各的脾气。这一章，咱们就掰开揉碎了看看这三款主流网关：Nginx、Kong和APISIX。

2.1 Nginx：老牌经典，灵活但门槛高

Nginx本身不是专门的API网关。它是个高性能的Web服务器和反向代理。很多人把它当网关用，说白了就是看中它那变态的并发处理能力。

我最早接触网关就是从Nginx开始的。那时候还在用裸Nginx加Lua脚本，边写边骂，但不得不说，一旦玩熟了，这东西真的很香。

Nginx的核心特性

• 事件驱动架构：单进程处理海量连接，内存占用极低。我遇到过一台2核4G的机器，扛住了3万QPS。
• 反向代理：最基础也最核心的功能，把客户端请求转发给后端服务。
• 负载均衡：内置轮询、最少连接、IP哈希等策略。
• 静态文件服务：虽然不是网关专属，但在实际项目里经常用来挡掉静态资源请求。
• 可扩展性：通过Lua脚本（OpenResty）或C模块扩展功能。

Nginx的局限性

• 原生不支持动态配置，修改配置要reload，这在微服务高频变更的场景下很痛苦。
• 没有内置的认证授权模块。你需要自己写Lua脚本或者集成第三方插件。
• 集群管理几乎是空白。要么靠keepalived做高可用，要么自己搭管理平台。

2.2 Kong：插件生态的先行者

Kong是在Nginx基础上长出来的“真正”的API网关。我2016年第一次接触Kong，那时候它还叫Mashape Kong。当时就觉得，嗯，这才是我想要的网关——开箱即用，功能齐全。

Kong本质上是OpenResty（Nginx + LuaJIT）的一个应用层封装。它把Nginx的能力抽象成插件系统，再配上RESTful管理API，大大降低了使用门槛。

Kong的架构

组件	说明
Kong Gateway	核心代理层，处理所有流量。默认监听8000端口。
Admin API	管理接口，用于动态创建路由、服务、插件等。监听8001端口。
插件系统	内置认证、限流、日志、转换等插件。支持自定义。
数据库	PostgreSQL或Cassandra，存储配置数据。

Kong的插件生态

这是Kong最大的卖点。社区提供了上百个插件，常用的有：

• Key-Auth：最简单的认证。
• JWT：JWT令牌验证，我做的几个微服务项目都用这个。
• Rate-Limiting：限流，支持本地和集群模式。
• IP-Restriction：IP黑白名单。
• CORS：跨域资源共享处理。
• Logging：支持HTTP日志、TCP日志、文件日志。

我在一个电商项目里遇到过一个问题——某个活动接口被刷了。当时我是怎么处理的？打开Kong的管理界面，给那个路由加了个Key-Auth插件，再配合Rate-Limiting，五分钟解决问题。这就是Kong插件生态的威力。

2.3 APISIX：后起之秀，性能与扩展的平衡

APISIX是Apache软件基金会的顶级项目，也是最近几年社区最活跃的网关之一。我第一次认真研究APISIX是在2020年，当时它的路由匹配性能就让我印象深刻——基于前缀树（Radix Tree）的实现，在海量路由场景下表现惊人。

APISIX和Kong一样，都是基于OpenResty。但它的设计更激进，性能优化做得更彻底。

APISIX的亮点

• 极致的路由性能：内置的Radix Tree路由器，实测10万条路由，匹配时间依然在微妙级。
• 动态配置：所有配置变更通过Admin API或控制面板，无需reload。这比Nginx强太多了。
• 多语言支持：插件可以用Lua、Java、Go、Python、Wasm等编写。我给团队写过几个Java插件，开发效率确实高。
• 内置服务发现：原生支持Nacos、Consul、Eureka、K8s，省去了集成适配的麻烦。
• 无DB模式：可以通过etcd直接加载配置，减少系统依赖。

APISIX的插件开发

很多朋友问我为什么选APISIX而不是Kong。我的答案很直接——插件开发体验差太多。APISIX的插件模板很清晰，开发文档也写得好。我举个例子，一个简单的限流插件大概是这样：

-- apisix/plugins/my-rate-limit.lua
local plugin_name = "my-rate-limit"

local _M = {
    version = 0.1,
    priority = 1000,
    name = plugin_name,
    schema = {
        type = "object",
        properties = {
            count = { type = "integer", minimum = 0 },
            time_window = { type = "integer", minimum = 0 }
        },
        required = { "count", "time_window" }
    }
}

function _M.access(conf, ctx)
    -- 这里写限流逻辑
    ngx.log(ngx.INFO, "rate limit: ", conf.count, " in ", conf.time_window, "s")
end

return _M

这段代码放到APISIX的插件目录，重启一下就能用。对于要频繁定制网关功能的团队来说，这种开发效率非常关键。

2.4 三者对比：到底怎么选？

好了，三款网关的核心特性都讲完了。你可能会想，到底选哪个？我的经验是，先问自己三个问题：

1. 团队技术栈：有人精通Nginx配置吗？还是更习惯用REST API管理？
2. 功能复杂度：只是做基础路由和限流？还是需要复杂的认证、鉴权、日志分析？
3. 运维成本：有资源维护一个完整的网关集群吗？还是希望“开箱即用”？

下面这张图是我自己对三款网关的定位总结，你看完应该能有个大致判断。