抛弃Nginx？还是干掉Kong？聊聊为什么Apache APISIX现在这么火，看完这篇你就懂了！
昨晚又是加班，不为别的，就为了给客户提供无微不至的服务。有个微服务上线的配置写错了，导致流量没切过去，大半夜的还得爬起来改 Nginx 配置，reload，提心吊胆盯着日志看有没有报错。那一刻我就在想，咱们做运维的，日子真不该过得这么苦逼。
也就是这时候，我想到了今天想跟大伙聊的这个东西——Apache APISIX。
最近群里总有人问我：“现在那个 APISIX 好像很火啊，到底是干啥的？我有 Nginx 了，还要它干嘛？”
这问题问得好。咱们很多做运维的，手里拿着 Nginx 这把锤子，看什么都是钉子。虽然 Nginx 确实是神，但在云原生这一波浪潮下，这尊神有时候也显得有点“腿脚不便”。
今天咱们不整那些虚头巴脑的概念，我就结合我自己的踩坑经历，给大家好好唠唠，这个 Apache APISIX 到底是何方神圣，为啥我现在强烈建议大家都在生产环境试一试。
官网地址：https://apisix.apache.org/zh/docs/apisix/getting-started/README/
从“改配置重启”的噩梦说起
咱们先别急着说 APISIX，先回想一下，咱们平时是怎么用 Nginx 的。
业务要加个新域名？改 nginx.conf。
后端服务扩容了，IP 变了？改 upstream。
要做个黑白名单防刷？改配置，加 Lua 脚本。
改完之后呢？nginx -t 测试一下，然后 nginx -s reload。
看起来很流畅是吧？但是兄弟们，当你的业务量上来之后，当你的 upstream 有几千个的时候，当你一天要变更几百次配置的时候，这个 reload 就是个定时炸弹。
我之前遇到过一个坑，Nginx 在高并发下 reload，新的 worker 进程起来了，旧的 worker 还在处理长连接，这时候系统负载会瞬间飙升，甚至导致这一瞬间的请求处理延迟极高，客户端直接超时。那种感觉，就像是给一辆正在高速公路上飞奔的赛车换轮胎，太特么吓人了。
而且，它是静态的。哪怕你只是想改一个限流的参数，从每秒 100 改成 200，你都得重载进程。
这时候你可能会说：“那我用 Kong 啊，Kong 不是动态的吗？”
没错，Kong 是个好东西，也是基于 OpenResty 搞的。但是当年我用 Kong 的时候，最让我头疼的是它那个数据库依赖。Kong 默认很多配置是扔在 PostgreSQL 或者 Cassandra 里的。
我就想问问，做一个网关，为啥要我维护一个关系型数据库？一旦 DB 挂了，或者 DB 响应慢了，网关就跟着抖。虽然后来 Kong 也有了 DB-less 模式，但那套架构对我来说，还是重。
这就轮到 APISIX 出场了。
APISIX 到底是什么？
用官方的话说，它是一个动态、实时、高性能的 API 网关。
用我的话说，它就是一个“甚至不需要你 reload，就能随意控制流量、随意插拔插件的超级 Nginx”。
它底子还是 Nginx（确切地说是 OpenResty），所以性能上你完全不用担心，Nginx 能扛多少，它基本就能扛多少。甚至在某些场景下，因为它的路由算法优化得好，性能比原生的 Nginx 配置还要猛。
但它最牛逼的地方在于两个字：动态。
它是怎么做到的？
这就得提它的架构了。APISIX 放弃了传统的数据库，转而拥抱了 etcd。
做 K8s 的兄弟对 etcd 肯定不陌生，它是 K8s 的大脑。APISIX 选 etcd 做配置中心简直是神来之笔。为什么？
- 快：etcd 是基于 Raft 协议的，数据一致性强，而且对这种 KV 类型的配置读取速度极快。
- 推送机制：这是重点！Nginx 读取配置是启动时读文件的，而 APISIX 是通过 etcd 的
watch机制。一旦你在 etcd 里改了配置（或者通过 APISIX 的 Admin API 改了配置），etcd 会瞬间把变更推送到所有的 APISIX 节点。
整个过程毫秒级，而且是热更新。
不需要 nginx -s reload！
不需要 nginx -s reload！
不需要 nginx -s reload！
重要的事情说三遍。你的长连接不会断，你的业务没有任何感知，配置就生效了。
安装教程
APISIX 可以借助 quickstart 脚本快速安装并启动：
curl -sL https://run.api7.ai/apisix/quickstart | sh
该命令启动 apisix-quickstart 和 etcd 两个容器，APISIX 使用 etcd 保存和同步配置。APISIX 和 etcd 容器使用 Docker 的 host 网络模式，因此可以从本地直接访问。
如果一切顺利，将输出如下信息：
✔ APISIX is ready!
验证
你可以通过 curl 来访问正在运行的 APISIX 实例。比如，你可以发送一个简单的 HTTP 请求来验证 APISIX 运行状态是否正常：
curl http://127.0.0.1:9080 --head | grep Server如果一切顺利，将输出如下信息：
Server: APISIX/Version
这里的 Version 是指你已经安装的 APISIX 版本，比如 APISIX/3.3.0。
现在，你已经成功安装并运行了 APISIX！
APISIX 提供内置的 Dashboard UI，可访问 http://127.0.0.1:9180/ui 使用。更多指南请阅读 Apache APISIX Dashboard。
咱们拆开来看看里面都有啥
这玩意儿里面全是宝。
1. 路由（Route）——比 Nginx 灵活太多了
在 Nginx 里，我们写 location，正则匹配有时候写得头皮发麻。APISIX 的路由匹配算法用的是 Radix Tree（基数树）。这玩意儿不仅快，而且支持各种花式匹配。
你可以根据 HTTP Header、Query 参数、甚至 Cookie 来进行路由分发。
举个真实例子，咱们做灰度发布（金丝雀发布）。
以前在 Nginx 里，你可能得写一大堆 if 或者用 split_clients 模块，配置看着就晕。
在 APISIX 里，你只需要调一下 API，发个 JSON 过去：
“嘿，把 Header 里带着 version: v2 的请求，或者 ID 尾号是 1 的用户，转到这个新服务去。”
这就完事了。想停？再发个 API，立马切回来。
2. 插件（Plugin）——这才是核心生产力
APISIX 之所以叫“全生命周期管理”，靠的就是插件。它自带了几十上百个插件，咱们日常运维需要的，基本都有。
- 限流限速：
limit-req，limit-count。不怕被刷爆了。 - 身份认证：Key-auth，JWT，Basic-auth。以前这些逻辑可能要写在业务代码里，现在全扔给网关，业务服务只管处理逻辑，多爽。
- 可观测性：这个我太喜欢了。一键开启 Prometheus 插件，Metrics 直接暴露出来，Grafana 面板都不用自己画，官方给你现成的。还有 SkyWalking、Zipkin 这种链路追踪，配置一下 IP 端口就能连上。
- 安全：IP 黑白名单、CORS、URI 阻断，甚至还有 WAF（Web应用防火墙）功能的插件。
而且，它的插件架构设计得很“散装”。什么意思呢？就是你可以给每一个路由单独配插件。
比如 A 接口重要，我给它配个鉴权 + 链路追踪；B 接口是公共查询，我给它配个限流 + 缓存。互不干扰。
3. 多语言支持——别再逼我学 Lua 了
虽然 OpenResty 是 Lua 也就是 LuaJIT 的天下，但说实话，Lua 这语言，写点小脚本还行，逻辑复杂了维护起来真得掉头发。
APISIX 这点做得特别鸡贼（褒义）。它支持 Plugin Runner。
你是写 Java 的？写 Go 的？写 Python 的？没事，你可以用你熟悉的语言写插件，然后通过 RPC 的方式跟 APISIX 通信。
最近它还支持了 Wasm (WebAssembly)。这就更猛了，把插件编译成 Wasm 跑在网关里，既安全又快，还不用受语言限制。
为什么说它适合云原生？
现在大家都在搞 K8s，搞微服务。
传统的 Nginx 在 K8s 里用也就是做个 Ingress Controller。
APISIX 也有 APISIX Ingress Controller。
但它比官方那个 Nginx Ingress Controller 强在哪？
官方那个 Nginx Ingress，每次你改个 Ingress 资源，它其实是在后台偷偷改 nginx.conf 然后 reload。如果你集群大，Ingress 经常变，那 Nginx 就不停地 reload，性能抖动很明显。
APISIX 的 Ingress Controller 是全动态的。你改了 K8s 的资源，它直接转化成 APISIX 的配置通过 etcd 下发，全程无 reload。这就是为什么大厂上了 K8s 之后，很多都把网关换成了 APISIX。
我的一次实战经历
光说不练假把式。聊聊我去年做的一个迁移项目。
当时客户有个独立站老系统，流量特别大，平时 QPS 大概在 2万左右，大促能翻好几倍。原来前面顶着的是一套魔改的 Nginx，里面塞满了各种乱七八糟的 Lua 脚本，用来做鉴权和分流。
那个 nginx.conf 打开，几千行，谁都不敢动。也就是传说中的“屎山”。
后来业务要搞微服务拆分，这个网关成了瓶颈。每次发版都要找运维改配置，改错了就全站 502，开发骂，老板吼。
我就拍板，换 APISIX。
刚开始那几天也虚啊。毕竟是新东西，怕不住。我们先搭了一套 APISIX 集群，用 Nginx 做流量镜像（Mirror），把生产流量复制一份给 APISIX，看看它会不会挂，结果处理得稳如老狗。
然后开始切流量。先切 1%，再切 5%，最后全量。
切完之后的效果是立竿见影的：
- 开发爽了：我们给开发开了 Dashboard（APISIX 自带的一个控制台界面），他们要改路由、加限流，自己去点点点，或者调 API，不用再求着运维改文件了。
- 排错快了：以前 Nginx 日志得去服务器上 grep，现在直接看 SkyWalking 的链路图，哪个节点慢，一目了然。
- 睡得香了：这是重点。热更新真的太香了。以前大促前封网，谁都不许动配置，现在随时可以动态调整限流策略，稳得一匹。
还有点小缺点
咱也不能光吹彩虹屁，客观得说说它的一些门槛。
首先，etcd 的维护。虽然 APISIX 帮你解决了网关的问题，但你得去维护一个高可用的 etcd 集群。etcd 这玩意儿，数据量大了或者磁盘 I/O 慢了，也是会闹脾气的。你得有懂 etcd 的人。
其次，文档和学习曲线。虽然现在文档中文很全了（毕竟是中国团队开源的，必须点赞），但里面的概念比如 Service、Upstream、Route、Consumer 之间的关系，初学者上来还是容易晕。不像 Nginx，一个 location 走天下。你得花点时间去理解它的设计逻辑。
总结一下
所以，Apache APISIX 到底是什么？
它不是用来简单的替代 Nginx 静态文件服务的，它是为了微服务和动态流量而生的操作系统。
如果你的系统很简单，就两台服务器，跑个博客，那你用 Nginx 挺好，别折腾。
但如果你的系统是微服务架构，跑在 K8s 上，有频繁的发布需求，有复杂的流量控制需求，或者你深受 Nginx reload 之苦，那么 APISIX 绝对是你该去看的方案。
它就像是一个装备精良的现代特种兵，比起手里只有一把步枪的老兵（Nginx），它能应对的战场更复杂，战术更灵活。
技术在变，咱们运维的工具箱也得更新。别守着老黄历过日子，该尝试的时候就得尝试。而且这还是 Apache 的顶级项目，背后有一大帮大佬在维护，社区活跃度极高，遇到问题去 GitHub 上提个 Issue，回复速度那是相当快。
今天就大概聊这么多。关于 APISIX 怎么安装、怎么配 Dashboard，甚至怎么写个自定义插件，后面有机会我专门写个实操系列的教程，手把手教大家搭建一套高可用的网关集群。
觉得这篇对你有启发的，别忘了点个赞，转发给身边还在苦逼改 nginx.conf 的兄弟们看看。
最后，记得关注 @运维躬行录，咱们不讲空话，只聊运维一线的真枪实弹。我是悠悠，咱们下期见！
公众号：运维躬行录
个人博客：躬行笔记
