Day 20 / 共 20 天 · 第 4 周 高级子系统与运维

部署与收官串讲

恭喜读完 APISIX！今天讲部署，回顾四周主线，最后把 APISIX 和 higress-group（Envoy/Higress）做一次终极三网关对比——理解两大网关流派的技术路线取舍。

📍 你在整条链的位置（第 4 周 · 全课收官）
SSL/secret/wasm D19→ 部署与收官串讲→ 三网关大对比→ 毕业 🎓
L01

部署形态

🤔 痛点：源码看懂了，可它到底怎么跑起来？ 20 天读了一堆 Lua，但生产上怎么装、依赖啥、K8s 里怎么办？部署这关不过，学的都是纸上谈兵。
💡 本质：一个主体 + 一个仓库，三种"铺面" APISIX 部署像开一家连锁店：店员就是 APISIX 本体，账本就是 etcd——最小组合只要这两样（不像 Envoy/Higress 还要独立控制面这个"总部大脑"）。铺面可以是裸机（自己租店面装修）、Docker（预制集装箱店）、K8s（连锁总部统一调度）。standalone 模式（Day 07）连 etcd 账本都省了，用纯文件——最轻的路边摊。
  • 裸机/VM：装 OpenResty + APISIX + etcd，apisix start。
  • Docker：官方镜像（docker/ 目录），docker compose 起 APISIX + etcd。
  • Kubernetes：Helm chart 或 apisix-ingress-controller（用 CRD 管配置，呼应 higress-group 的 K8s 路线）。
最小依赖：APISIX + etcd APISIX 本身是单体（不像 Envoy/Higress 要控制面），核心依赖只有 etcd。裸机部署超简单。K8s 上用 apisix-ingress-controller 后，你写 K8s CRD（ApisixRoute 等）→ controller 转成 Admin API 调用 → 写 etcd——这时它就有了"控制面"的味道（和 Higress 的 Ingress→配置类似）。standalone 模式（Day 07）甚至不用 etcd，纯文件——最轻。
L02

config.yaml

conf/config.yaml 是启动配置（Day 03 生成 nginx.conf 的输入），关键项：

apisix:
  node_listen: 9080          # 数据面端口（处理业务请求）
  enable_admin: true
  router:
    http: radixtree_uri      # 路由算法（Day 06）
deployment:
  role: traditional          # 部署角色
  etcd:
    host: ["http://127.0.0.1:2379"]   # etcd 地址（Day 07）
plugins:                     # 启用哪些插件（Day 11 load 读它）
  - key-auth
  - limit-count
  - prometheus
读法：这个 YAML 决定"用哪个 etcd、监听什么端口、启用哪些插件、用什么路由算法"。它是运维配置（启动时定）；业务配置（路由/上游）走 Admin API + etcd（运行时动态）。两者分开：config.yaml 改要重启，etcd 里的配置改是热更新。
📝 两类配置对号入座 改 node_listen: 9080→8080（运维配置，config.yaml）→ 必须 apisix reload/restart 才生效。
改"给 /hello 加一条 limit-count"（业务配置，走 Admin API 写 etcd）→ watch 秒级热更新，零重启。分不清时记住：启动才定的进 config.yaml，运行中要改的进 etcd。
L03

完整请求链回顾

请求进入（Nginx access 阶段 → init.lua http_access_phase，W1）
  → 创建 api_ctx（tablepool + 惰性变量，W1 Day 05）
    → router 匹配路由（radixtree，W2 Day 06）
      → 合并 plugin_config/service/consumer 配置（W3 Day 13）
        → filter 选插件 → run_plugin rewrite（含鉴权识别 consumer，W3 Day 11-14）
          → run_plugin access（限流等拦截，W3 Day 15）
            → balancer 选上游实例（W2 Day 10，可能 discovery 动态，W4 Day 16）
              → 转发 → header_filter/body_filter 改响应 → log 收尾释放 ctx
（配置全程来自 etcd watch 的内存，改配置秒级热更新，W2 Day 07）
这条链贯穿全课——每一环你都读过源码了。
🧠 记忆口诀：进 → 建 → 配 → 插 → 转 「进门建上下文，配好合并选插件，插件跑完选上游，转发改响应收尾」——进（access 入口）、建（api_ctx）、配（路由匹配+配置合并）、插（filter+run_plugin 鉴权限流）、转（balancer 转发+header/log）。五个字背下来，一个请求的一生就串起来了。
L04

四周主线

W1 全景与请求生命周期：OpenResty/etcd → Nginx 阶段 → 启动 → http_access_phase → api_ctx（tablepool+惰性变量）
W2 路由/配置/数据面：radixtree 路由 → etcd watch 热更新 → 六大对象 → schema 校验 → upstream/balancer
W3 插件系统：load/priority → filter 选插件 → run_plugin 各阶段 → 配置合并 → consumer 鉴权 → 典型插件
W4 高级子系统：服务发现 → Admin/control API → stream L4 → SSL/secret/wasm/pubsub
L05

设计智慧总结

  1. OpenResty + etcd 双支柱：Nginx 给性能、LuaJIT 给灵活、etcd 给动态。
  2. 读写分离 + 版本化缓存：请求走内存（快）、配置走 etcd watch（动态）、用 modifiedIndex 保证缓存一致。
  3. 处处"策略/适配器模式"：路由/配置中心/负载均衡/限流/服务发现/密钥都是"接口统一、实现可换"。
  4. tablepool + 惰性求值 + 编译缓存：把重复计算和 GC 压力压到最低。
  5. 内核小、插件多：核心只做路由+插件链+转发，功能全靠 104 个插件。
能迁移到你项目的思想 "用现成设施当配置中心（etcd）""读写分离 + 版本号失效缓存""策略模式应对多变体""对象池抗 GC""内核小插件多"——这些在任何高性能/高可扩系统里都通用。看懂 APISIX 怎么用，你写自己的系统时也能借鉴。
L06

三网关大对比

Envoy / Higress：控制面 + 数据面分离 控制面（istiod / Higress Core） xDS 下发 数据面 Envoy 数据面 Envoy 总部算好、下发给门店（超大规模/mesh 强） APISIX：单体节点 + etcd etcd（共享账本） 各节点自己 watch APISIX 节点 APISIX 节点 每店自给自足、直接读账本（部署轻/上手快）
两种架构的根本差异：一边"总部算好 xDS 下发"，一边"节点各自 watch etcd"。下表逐维展开。
维度Envoy/HigressAPISIX
语言C++ 数据面Lua（OpenResty）
架构控制面(istiod/Higress Core) + 数据面分离单体（每节点自给自足）+ etcd
配置分发控制面生成 xDS 下发节点直接 watch etcd
配置模型K8s Ingress/CRD → 翻译etcd 里的 Route/Upstream/…（或 CRD）
扩展Wasm / C++ filterLua 插件（也支持 Wasm）
动态性xDS 增量下发etcd watch 热更新
上手较复杂（要懂 xDS/istiod）较简单（Lua + etcd）
规模超大规模 service mesh 强API 网关场景轻快
两条路线殊途同归 它们解决同一问题（南北向 API 网关 + AI 网关），但技术路线不同：Envoy/Higress 是"控制面算好、xDS 下发数据面"的分离架构（适合超大规模、多语言、service mesh）；APISIX 是"单体节点 + etcd"的自给架构（部署轻、Lua 上手快、动态强）。而且两者越来越像——APISIX 支持 Wasm 和 xDS（config_xds）、K8s CRD；Higress 也在简化。都全面拥抱了 AI 网关。
L07

怎么选

没有银弹，看场景 选 APISIX：想要轻量部署、团队熟 Lua、快速迭代插件、纯 API 网关场景、不想维护 istiod。
选 Higress/Envoy：已在 Istio/service mesh 生态、需要 C++ 级性能和超大规模、多语言 Wasm 扩展、东西向+南北向统一。

关键是理解两种架构的取舍，而非记结论。你学完 higress-group（Envoy/Istio/Higress/Console/wasm-go）+ APISIX，就完整看过了业界两大网关流派——这个视野比"用哪个"更值钱。

👶 小白：一句话，我到底该选谁？

👨‍🏫 老师：不在 mesh 生态、就想要一个轻快好上手的 API 网关 → APISIX；已经在 Istio/K8s service mesh、要 C++ 级性能和超大规模、东西向+南北向统一 → Envoy/Higress。但更重要的是：它们在互相靠拢——APISIX 也支持 Wasm、xDS、K8s CRD，Higress 也在简化，两家都全面拥抱 AI 网关。看懂"为什么这样设计"，换哪个都能快速上手。

L08

毕业 + 动手

🎓 20 天后，你已经能

  • 说清 APISIX 的 OpenResty+etcd 架构和"全动态"原理。
  • 追踪一个请求从 access 到转发的完整生命周期源码。
  • 理解路由(radixtree)/配置(etcd watch)/插件(load/filter/run)/上游(balancer) 四大子系统。
  • 掌握插件机制并能读懂/编写一个 Lua 插件。
  • 把 APISIX 和 Envoy/Higress 两大网关流派做架构对比。

✋ 毕业动手

cd /Users/bitmart/work/codes/github/apisix
# 用 docker compose 跑一套（需要 Docker）
ls docker/
# 追一条请求的完整链路
sed -n '602,758p' apisix/init.lua        # http_access_phase
# 试着读/改一个插件，感受插件化的威力
cat apisix/plugins/echo.lua 2>/dev/null | head -60
系列进度：higress-group 5 站 + APISIX 全部完成。你已通读两大网关流派。若还想深入，可写个自定义 Lua 插件、或对比 apisix-dashboard 与 Higress Console 的实现差异。感谢跟到最后！🎉
← Day 19 返回总目录 →