一、APISIX 是个什么东西？

1.1 一句话介绍

APISIX 是 Apache 基金会顶级项目，基于 OpenResty（Nginx + LuaJIT） 构建的云原生 API 网关，专注于高性能、全动态、可扩展。

1.2 它的身世

是的你没看错，NASA 也在用。不知道是不是拿来管理火星探测器的 API（大概不是）。

1.3 核心架构

先来看看 APISIX 的整体架构，理解这张图是理解后面所有内容的基础：

关键点：

• 数据面（Data Plane）：就是 APISIX 本体，负责处理所有流量，基于 OpenResty
• 控制面（Control Plane）：etcd 存储所有配置，通过 Watch 机制实时推送变更
• 没有传统数据库：不需要 PostgreSQL，不需要 Cassandra，只要 etcd

这个架构设计是 APISIX 和 Kong 最本质的区别，后面会详细说。

二、入门：快速上手

2.1 安装（Docker 一把梭）

最快的入门方式，没有之一：

# 克隆 APISIX Docker 仓库
git clone https://github.com/apache/apisix-docker.git
cd apisix-docker/example

# 一键启动
docker-compose -p docker-apisix up -d

启动后你会得到：

2.2 第一个路由

让我们创建一个最简单的路由，把 /hello 的请求代理到 httpbin.org：

curl -i http://127.0.0.1:9180/apisix/admin/routes/1 \
  -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' \
  -X PUT -d '{
    "uri": "/hello",
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "httpbin.org:80": 1
        }
    }
}'

测试一下：

curl -i http://127.0.0.1:9080/hello

如果你看到了 httpbin 的响应，恭喜你，你已经完成了"入门"部分。

用时：5 分钟。

接下来开始漫长的"放弃之路"。

2.3 核心概念速览

在继续之前，先理清 APISIX 的几个核心概念，它们的关系如下：

简单翻译一下：

• Route（路由）：流量入口的规则定义，告诉 APISIX "什么样的请求应该去哪里"
• Upstream（上游）：后端服务的地址和负载均衡配置
• Service（服务）：Route 和 Upstream 之间的抽象层，方便复用
• Plugin（插件）：在请求生命周期中执行的逻辑，可以挂在 Route、Service、Consumer 上
• Consumer（消费者）：API 的调用方身份，通常配合认证插件使用
• Global Rule（全局规则）：对所有路由生效的插件配置

三、进阶：APISIX 的核心能力

3.1 插件系统

APISIX 的灵魂就是它的插件系统。目前内置了 80+ 插件，覆盖以下几大类：

3.2 插件执行顺序

这是很多人踩坑的地方。APISIX 的插件不是"先配先执行"，而是有严格的执行顺序：

关键知识点：每个插件都有一个 priority 值，数字越大越先执行。你可以在 conf/config-default.yaml 里找到完整的优先级列表。

3.3 多语言插件开发

APISIX 不仅支持 Lua 插件，还支持多种语言：

坦白说，性能最好的还是原生 Lua 插件。多语言 Runner 会引入额外的进程间通信开销（Unix Socket），在高并发场景下可能成为瓶颈。但如果你团队没人会写 Lua，用 Java/Go 写插件总比不用强。

四、APISIX vs Kong：一场正面对决

这可能是你最关心的部分。来，上硬货。

4.1 架构对比

这张图说明了一切。APISIX 用 etcd 的 Watch 机制，配置变更毫秒级生效；Kong 传统模式依赖数据库轮询，存在秒级延迟。

4.2 全面对比表

4.3 性能对比

根据多个第三方 benchmark 数据（注意：任何 benchmark 都有其局限性）：

⚠️ 以上数据仅为趋势示意，实际数值取决于硬件环境、测试方法和具体配置。APISIX 在路由数量增加时性能衰减更小，这主要归功于 radixtree 的 O(k) 匹配复杂度（k 为 URI 长度），而 Kong 的遍历匹配接近 O(n)。

4.4 选型决策树

五、生产实践：踩坑记录

5.1 etcd：成也萧何，败也萧何

APISIX 选择 etcd 作为配置中心是一把双刃剑。

好处：轻量、快速、Watch 机制完美。

坑：etcd 本身的运维不是省油的灯。以下是常见问题：

• etcd 磁盘空间暴涨：etcd 默认的 compaction 策略可能导致历史版本堆积。必须配置自动压缩：

  # etcd 配置
  auto-compaction-mode: periodic
  auto-compaction-retention: "1h"

• etcd 集群脑裂：3 节点挂了 2 个？APISIX 直接不可用。建议生产环境至少 3 节点，有条件上 5 节点
• etcd 版本兼容性：APISIX 对 etcd 版本有要求，升级前务必查看兼容性矩阵

5.2 自定义插件的坑

如果你打算写自定义 Lua 插件，以下是血泪教训：

-- ❌ 错误示范：在热路径中创建 table
function _M.access(conf, ctx)
    local data = {}  -- 每次请求都创建新 table，GC 压力山大
    for i = 1, 100 do
        data[i] = i
    end
end

-- ✅ 正确做法：使用 table pool
local tab_new = require("table.new")
local tab_clear = require("table.clear")

local _M = {}
local data = tab_new(100, 0)  -- 预分配，复用

function _M.access(conf, ctx)
    tab_clear(data)
    for i = 1, 100 do
        data[i] = i
    end
end

5.3 监控三件套

生产环境必须配好的监控组合：

重点关注的指标：

• apisix_http_status：按状态码统计请求量，5xx 突增要报警
• apisix_http_latency：请求延迟分布，P99 是关键
• apisix_bandwidth：带宽使用，防止被打满
• apisix_upstream_status：上游健康状态，及时发现后端故障

六、APISIX 在支付系统中的应用思考

作为一个天天和支付系统打交道的人，聊聊 APISIX 在金融/支付场景下的适用性。

优势：

• 全开源无 vendor lock-in：金融系统对自主可控要求高，APISIX 的 Apache 2.0 协议没有功能阉割
• 毫秒级配置生效：支付系统路由变更（比如灰度切流、紧急熔断）需要快速生效
• 精细化限流：可以按商户 ID、渠道、接口维度做独立限流，用 limit-count 插件的 group 功能实现
• 审计友好：kafka-logger 可以把所有请求/响应记录到 Kafka，满足金融审计要求

顾虑：

• etcd 的高可用保障需要额外投入
• Lua 插件的开发和调试体验不如 Java/Go，金融团队通常以 Java 为主
• 缺少开箱即用的 API 版本管理和 Developer Portal（Kong Enterprise 在这方面更成熟）

七、写在最后：到底要不要放弃？

来做个总结。

不要放弃 APISIX 的理由：

1. 性能真的很强，路由匹配效率在同类产品中数一数二
2. 全动态配置体验丝滑，不用半夜起来 reload Nginx
3. 完全开源不割韭菜，所有功能一视同仁
4. 云原生友好，K8s 部署体验好
5. 中文社区活跃，遇到问题有人答

可以考虑放弃 APISIX 的理由：

1. 你团队完全不想碰 Lua，也不打算学
2. 你需要开箱即用的 Developer Portal 和 API Marketplace
3. 你已经深度绑定了 Kong 生态
4. 你的场景对网关性能没那么敏感，稳定和生态更重要
5. 你觉得运维 etcd 集群是一种折磨

我的建议：如果你是从零开始选型，且团队对新技术接受度高，APISIX 是目前性价比最高的选择。如果你已经在用 Kong 且用得挺好，那就没必要为了追新而迁移。

毕竟，最好的技术选型不是选"最好的"，而是选"最适合的"。

📌 参考资料

• Apache APISIX 官方文档
• APISIX GitHub
• APISIX vs Kong Benchmark
• APISIX 插件中心