Day 01 / 共 20 天 · 第 1 周 全景与请求生命周期

项目全景：从一个痛点讲起

今天不急着背概念。先从"一个真实的运维麻烦"出发，一步步推出：为什么需要 API 网关、APISIX 凭什么"又快又能热更新"、一个请求进来到底怎么走。看完你会拿到一张贯穿 20 天的地图。

📍 你在整门课的位置（这条链贯穿全部 20 天，每天开头点亮你所在的格子）
Day1 全景· 请求生命周期（W1）· 路由/配置/上游（W2）· 插件系统（W3）· 子系统/运维（W4）
L01

先看一个真实痛点

🤔 场景：你有几十个后端服务，怎么统一管流量？ 你的公司有几十个微服务（订单、用户、支付…）。现在要：给某些接口加限流、给某些加鉴权、把 /api/v2/* 灰度到新版本、加个监控。难道每个服务各写一套？改一次要重启几十个服务？
📝 传统 Nginx 的痛点 用 Nginx 做入口——加一条路由要：编辑 nginx.conf → nginx -s reload。
改一个限流参数：又编辑 → 又 reload。
😰 reload 有开销、有风险，几十个节点逐个改容易出错，配置散在文件里难管理。
💡 需要一个"总入口 + 动态可编程"的东西 把所有"进入公司的流量"都过一个统一入口，在这里集中做路由/鉴权/限流/监控，而且改配置要能立即生效、不用重启。这个东西就是 API 网关——APISIX 是其中最流行的开源实现之一（README.md："Apache APISIX API Gateway ｜ AI Gateway"）。
L02

网关就是"总入口保安 + 调度台"

外部客户端 📱 💻 APISIX 网关 🔐 鉴权 🚦 限流 🎯 路由 · 📊 监控 内部微服务 订单服务 用户服务 支付服务
API 网关是所有外部流量的"总入口"：在这里集中做鉴权、限流、路由、监控，再转发到内部服务。
💡 网关处理"南北向流量" "南北向"= 外部客户端进入你的服务（上下方向）；"东西向"= 服务之间互相调用（左右方向，那是 service mesh 的事）。APISIX 专注南北向——它是你系统的"大门保安 + 调度台"。所有"进门的人"都在这里过一遍安检和分流。
L03

为什么"快"：OpenResty 内核

🤔 网关在关键路径上，慢一点全公司都卡——怎么做到快？ 每个请求都过网关，网关的性能就是全系统的上限。
💡 APISIX 建在 OpenResty 上，OpenResty = Nginx + LuaJIT Nginx：世界上最流行的高性能 Web 服务器（C 写的，极快）。LuaJIT：一个超快的 Lua 即时编译器。OpenResty 把 LuaJIT 嵌进 Nginx，让你能用 Lua 在 Nginx 的各个处理阶段编程。
一句话 APISIX = 用 Lua 在 OpenResty 上写出来的一整套网关逻辑。底层是 Nginx 的 C 级性能，热点靠 LuaJIT 即时编译——所以又快又能编程。整个 apisix/ 目录几乎全是 .lua。这就是"快"的根源。
L04

为什么"动态"：etcd 配置中心

🤔 回到 L01 的痛点：改配置怎么才能"不重启就生效"？ 传统 Nginx 改 nginx.conf 要 reload。APISIX 怎么免掉这步？
💡 配置存 etcd，每个网关节点 watch 变化 etcd 是一个分布式键值存储（Kubernetes 也用它），特点：强一致 + 支持 watch（订阅某个 key，一变就主动推给你）。APISIX 把路由/上游/插件都存 etcd，每个网关节点 watch 变化——配置一改，所有节点秒级 watch 到、内存里更新，立即生效，零 reload。
📝 全动态的爽点 调 Admin API 加一条路由 → 写进 etcd → 所有节点 watch 到 → 内存更新 → 新路由立即可用
全程无需 nginx -s reload、无需重启。加路由、改限流、换证书都是瞬时的。这直接解决了 L01 的运维痛点。
两大支柱记牢：OpenResty 给性能（Nginx+LuaJIT）、etcd 给动态（配置中心+watch 热更新）。APISIX 的一切都建在这两根柱子上。
L05

一个请求的旅程（全课主线图）

一个请求进入 APISIX，会走这条链——后面 20 天几乎都在讲这条链上的某一环，请记牢：

请求进入access 阶段 D2-4 匹配路由radixtree D6 选插件+鉴权filter D11 · consumer D14 跑插件各阶段run_plugin D12 负载均衡balancer D10 上游 🔑 配置全程来自 etcd watch 的内存（读走内存=快，写走 etcd=动态）
请求旅程：进入 → 匹配路由 → 选插件+鉴权 → 跑插件 → 负载均衡 → 转发上游。每格标了教学日。
读法：这条链就是本课主线。第 1 周走通它（全景 + Nginx 阶段 + 启动 + 生命周期），后面逐环展开。核心入口是 init.lua 的 http_access_phase（Day 04 精读）。
L06

六大抽象对象：配置的"名词"

APISIX 用几个核心对象描述配置（都存 etcd，Day 08 详讲）。先建立印象：

对象大白话
Route 路由"什么请求（uri/host）→ 用哪些插件 → 转发到哪"，中心枢纽
Upstream 上游"后端服务集群 + 怎么分流"（负载均衡）
Service 服务"可复用的插件+上游套餐"，多个 Route 共享
Consumer 消费者"API 调用方的身份 + 凭据"（谁能访问）
Plugin Config"可复用的一组插件配置"
Global Rule"对所有请求生效的插件"（全局限流/监控）
Route 是核心 Route 把"匹配什么 → 怎么处理 → 转发到哪"三件事串起来。其余对象（Service/Upstream/Plugin Config）是"可复用的零件"，避免每条路由重复配。这套模型和上一站 Higress Console 的路由/服务/插件相通——网关的共性。
L07

和 Envoy/Higress 对照：两条路线

路线 A：Envoy/Higress（控制面+数据面分离） 控制面 istiod 算配置 xDS 下发 数据面 Envoy(C++) 超大规模强，架构复杂 路线 B：APISIX（单体 + etcd） 每节点自己 watch etcd APISIX 节点(Lua) 部署轻、上手快
两大网关流派：Envoy/Higress "控制面算好+xDS下发数据面"；APISIX "每节点自己连 etcd"。
没有绝对优劣，看场景 Envoy/Higress（C++/xDS）：适合超大规模、多语言扩展，但要维护控制面（istiod）；APISIX（Lua/etcd）：架构简单、部署轻、Lua 上手快，节点自给自足。如果你学过 higress-group 系列，这一站正好是"另一条路线"的对照——理解两种设计哲学，比只会一个更值钱。Day 20 会做完整对比。
L08

目录地图（课程表）+ 动手

apisix/
  init.lua        ★ 请求生命周期总控（各 Nginx 阶段的 Lua 入口）→ Day 2-5
  router.lua      ★ 路由（radixtree）                            → Day 6
  core/config_etcd.lua  配置中心 watch                          → Day 7
  schema_def.lua  六大对象定义 + 校验                            → Day 8-9
  balancer/       负载均衡                                        → Day 10
  plugin.lua      ★ 插件系统（加载/过滤/运行）                    → Day 11-15
  plugins/        104 个插件
  discovery/ admin/ control/ stream/ ssl/  子系统                → Day 16-19
  cli/            启动命令行                                      → Day 3, 20

🧠 今天你应该能回答（大白话）

  • 为什么需要 API 网关？传统 Nginx 的痛点是什么？
  • APISIX 的两大支柱："快"来自谁、"动态"来自谁？
  • 一个请求的旅程有哪几步？
  • 六大对象里 Route 为什么是核心？和 Envoy/Higress 两条路线的差异？

✋ 动手

cd /Users/bitmart/work/codes/github/apisix
sed -n '20,40p' README.md
ls apisix/
ls apisix/plugins/ | wc -l          # 插件数量（104）
ls apisix/core/
明天预告 · Day 02：读懂 APISIX 的前提是理解"Nginx 处理请求的阶段"。APISIX 的所有逻辑，本质就是"在 Nginx 的某个阶段挂一段 Lua"——Day 02 把这套阶段模型讲清，你就有了阅读 init.lua 的地图。