一、APISIX 是什么

APISIX 是一个云原生 API 网关，Apache 顶级项目。2019 年开源，用 NGINX + etcd 做底座，主要解决微服务架构下流量入口的问题。客户端请求先到 APISIX，由它决定这个请求该转发给谁、要不要拦、要不要限速、要不要记日志。微服务之间互相调用，也可以走 APISIX 来治理。现在 GitHub 上自带 100 多个插件。性能方面，单核 QPS 能到 18000 左右，延迟增加大概 0.2 毫秒。荣耀的网关平台基于 APISIX 构建，峰值能扛住数百万 QPS，自研了近 100 个插件。

二、架构上几个关键选择

APISIX 的架构有几处和传统网关不太一样的地方。

配置存在 etcd 里，不是 MySQL。 传统网关大多用数据库存路由和插件配置，改一条配置要等轮询刷新，几秒甚至几十秒才生效。APISIX 用 etcd 的 watch 机制，配置一改，所有网关节点毫秒级收到通知。同花顺的 HxApisix 生产环境实测，配置变更后不到 1 秒生效。这个差异在生产环境改配置的时候特别明显。

数据面和控制面分开。 数据面只负责转发流量，本身不存配置，挂了随时可以拉起来。控制面管配置下发。etcd 如果出问题，数据面靠已有配置还能继续跑，不会整个网关直接躺下。

插件热加载。 插件装了、改了、删了，不用重启进程。同花顺的实践里，网关 Pod 以 Deployment 形式跑在 K8s 上，插件链的调整不需要重启实例。这点看起来小，但生产环境重启一次网关的代价有时候挺大。

路由匹配用前缀树（Radix Tree）。 路由数量涨到几万条，查找性能也不会明显掉。APISIX 和 Kong 的对比测试里，路由数量达到 5000 条时，APISIX 的 QPS 通常比 Kong 高出 30% 到 50%。

请求进来之后，插件按阶段执行：rewrite → access → before_proxy → header_filter → body_filter → log。每个插件可以挂在其中一个或多个阶段，优先级可以配，顺序能控制。

三、主要功能

路由和负载均衡。 按路径、Host、参数、Cookie 等条件把请求分发到不同的上游。APISIX 支持用 NGINX 内置变量作为路由条件，比如用 cookie、args 来匹配，做金丝雀和 A/B 测试的时候很灵活。负载均衡支持轮询、一致性哈希、指数加权，带主动和被动健康检查，节点挂了自动摘掉。

认证和安全。 key-auth、JWT、Basic Auth、OIDC 这些认证方式都有现成插件。IP 黑白名单、UA 限制、Referer 限制、CORS、URI 阻断、请求校验也都齐。WAF 方面可以集成 Chaitin SafeLine，也可以走 Wasm 的 Coraza。

限流熔断灰度。 按请求数或并发数限流，熔断，灰度发布，流量镜像，流量切分。同花顺的网关里做了三级插件链（Route → Service → Global），认证、限流、改写、代理按顺序执行。

可观测性。 Prometheus 指标直接暴露，支持 OpenTracing、Zipkin、SkyWalking 做链路追踪。腾讯游戏这边的做法是走 OpenTelemetry 插件，数据先到 OpenTelemetry Collector，最终写进 ClickHouse。访问日志能导出到 HTTP、Kafka、TCP/UDP。

协议支持。 HTTP/HTTPS 是基础。gRPC 代理和 HTTP 转 gRPC 转码、WebSocket、Dubbo、MQTT 都支持。MQTT 可以按 client_id 做负载均衡，兼容 MQTT 3.1.* 和 5.0。TCP/UDP 的四层代理也有。HTTP/3 和 QUIC 在跟进。

四、插件机制

插件是 APISIX 扩展能力的主要方式。一个插件可以绑在 Route、Service、Consumer 或者 Plugin Config 上，作用范围可以很细。插件中心目前有 100 多个现成插件，覆盖认证、安全、流量控制、转换、可观测性这些分类。

比较特别的一点是多语言支持。官方插件用 Lua 写，跑在 LuaJIT 上性能最好。但不想学 Lua 的团队可以用 Java、Python、Go、JavaScript 写插件，通过外部 Plugin Runner 加载，也支持 Wasm 运行时。后端工程师用自己顺手的语言就能扩展网关，这个门槛降得很低。同花顺的实践里就是用自定义 Lua 插件实现了 MCP 代理，把传统 REST API 包装成 AI Agent 能调用的接口。

插件之间还能编排。根据前一个插件的执行结果决定后面走哪条路。条件认证、动态限流这类逻辑不用写代码，配出来就行。

五、应用场景

统一 API 入口。 所有 API 走网关，认证、限流、日志、协议转换这些事在网关层统一处理，后端服务只管业务。Software Mind 帮一个客户把原来五个不同的 Ingress Controller 合并成一个 APISIX，新路由上线时间缩短了 50%，故障排查快了 60%。

Kubernetes Ingress。 当 Ingress Controller 用，Ingress 资源自动转成网关路由。2.0 版本引入了 Gateway API 的完整支持，包括 TCPRoute、UDPRoute、GRPCRoute 和 TLSRoute。相比默认的 Ingress Controller，插件和流量控制能力丰富不少。

服务网格。 东西向流量场景，微服务之间调用的服务发现、熔断、限流可以交给 APISIX。腾讯游戏这边虽然依赖 K8s 环境，但考虑到 Ingress Controller 和 APISIX 版本的强耦合，以及配置状态不够透明的问题，他们选择了 Helm Chart 方式部署，不走 Ingress Controller。

游戏网关。 AWS 的博客里介绍过用 EKS + APISIX + Graviton 构建游戏网关的方案。运维入口走 Admin API，玩家流量走 API Gateway 路由到 Game Server 或 Platform Service。用 Graviton 机型跑 APISIX 来压性能。

AI 网关。 这块是近两年在拓展的方向。APISIX 的插件中心有 ai-proxy、ai-proxy-multi、ai-rate-limiting 等 AI 相关插件。ai-proxy 简化了到 OpenAI 兼容端点的代理，ai-proxy-multi 在它基础上加了负载均衡、重试、fallback 和健康检查。ai-rate-limiting 按 token 消耗做限流，不是按请求数。同花顺的 HxApisix 也在做 MCP 代理，让 AI Agent 能调用现有业务接口。

六、和 Kong 对比

两者都基于 OpenResty 构建，但在几个关键点上走了不同路线。

配置存储。 APISIX 用 etcd，Kong 默认用 PostgreSQL。etcd 的 watch 机制让 APISIX 的配置变更更实时。但反过来说，如果团队已经熟 PostgreSQL，Kong 的运维负担反而更小；etcd 集群本身也是要维护的。

性能。 路由数量少的时候（几百条以内），两者差距不明显。路由数量上到几千条，APISIX 的路由匹配优势就出来了，QPS 能高出 30% 到 50%，延迟低 20% 左右。

扩展方式。 Kong 的插件生态更成熟，很多第三方安全厂商专门做了 Kong 插件。APISIX 的插件数量增长快，多语言支持和 Wasm 是它的特点。如果需要 Java 或 Go 写网关插件，APISIX 更顺手。

选型建议。 已经在用 Kong 且对 PostgreSQL 运维熟悉，继续用是合理的。新项目、K8s 环境、追求性能和动态配置能力，优先评估 APISIX。两边都有开源版和企业版，功能边界不完全一样，评估的时候要看清楚。

七、部署方式

部署方式有 Docker、K8s Helm Chart、RPM 包、源码编译，Docker 最快。

curl -sL https://run.api7.ai/apisix/quickstart | sh

这个命令会在本地 Docker 里跑起 APISIX 和 etcd，两者都用 host 网络模式，本地就能访问。

先搞明白四个概念：Route、Upstream、Service、Plugin。Route 是匹配请求的规则，Upstream 是后端服务地址，Service 是可复用的服务抽象，Plugin 是挂在 Route 或 Service 上的功能扩展。

配置通过 Admin API 或者 YAML 文件管。Admin API 默认只允许本地访问，生产环境记得改默认密钥。

实践路径建议从官方文档的 Getting Started 开始，建一条路由到 httpbin.org，绑一个限流插件，发请求看它怎么被处理和转发。跑通这一遍，基本就理解 APISIX 的工作方式了。

八、生产环境要注意的几个点

Admin API 的安全。 默认密钥必须改，网络暴露要限制。同花顺的做法是运维入口和玩家入口走独立的 ELB，Admin API 不直接暴露给公网。

etcd 的运维。 etcd 是 APISIX 配置的唯一来源，挂了虽然数据面还能跑，但新配置下不去。etcd 集群的备份和恢复方案要提前想好。如果不想要 etcd 的运维负担，APISIX 也支持 Standalone 模式，配置直接放内存，通过专用 Admin API 管理，不需要 etcd。

配置变更的流程。 腾讯游戏这边的经验是，用 Helm Chart 部署时把路由配置放在 apisix-configmap.yaml 里，通过 hash 注解触发 ConfigMap 更新，APISIX 定时读本地文件刷新内存配置，不需要重启 Deployment。而涉及运行时参数的 config-configmap.yaml 改了，就需要重启实例。

K8s 环境下的版本耦合。 用 Ingress Controller 的话，APISIX 版本和 Controller 版本有兼容矩阵，不能随便升。腾讯游戏就是因为这个原因放弃了 Ingress Controller，走 Helm Chart 路线