Day 08 / 共 20 天 · 第 2 周 路由/配置/数据面

六大抽象对象（配置模型）

配置从 etcd 同步进内存了，今天看"配置长什么样"——APISIX 的六大核心对象。理解它们的字段和引用关系，就理解了 APISIX 的配置模型。schema 都在 schema_def.lua。

📍 你在整条链的位置
etcd 配置 D7→ 六大对象（配置模型）→ schema 校验 D9→ 上游 D10
L01

etcd 里的组织

每类对象在 etcd 有自己的前缀，一个对象一个 key（Day 07）：

/apisix/routes/{id}          Route 路由        → schema_def.lua:553
/apisix/services/{id}        Service 服务      → :684
/apisix/upstreams/{id}       Upstream 上游     → :756
/apisix/consumers/{name}     Consumer 消费者   → :715
/apisix/plugin_configs/{id}  Plugin Config    → :1018
/apisix/global_rules/{id}    Global Rule      → :905
读法：各子系统 watch 自己那个前缀（Day 07）。对象的 schema（有哪些字段、什么类型）定义在 schema_def.lua。
L02

Route：中心枢纽

schema_def.lua:553-680。核心字段：

字段含义
uri / uris / host / methods / vars匹配条件（什么请求）
priority优先级（多路由匹配时）
plugins这条路由启用的插件（怎么处理）
upstream / upstream_id内联上游 或 引用上游（转发到哪）
service_id / plugin_config_id引用可复用配置
💡 Route 把三件事绑一起 匹配什么（uri/host/methods）→ 怎么处理（plugins）→ 转发到哪（upstream）。它可以内联一切，也可引用 service/upstream/plugin_config 复用。Day 04 的 matched_route 就是它。
L03

Service：可复用套餐

schema_def.lua:684-714：含 plugins + upstream/upstream_id（和 Route 类似，但没有匹配条件）。

Service = "插件+上游套餐" 20 条路由都指向同一组后端、用同样的限流/鉴权？与其重复配 20 遍，不如建一个 Service 装好，20 条路由都 service_id: X 引用它。改一次 Service，20 条路由全生效。Day 04 的 merge_service_route 就是运行时把 Service 合并进 Route。Service 没有"匹配条件"——匹配是 Route 的职责，Service 只管"处理和转发"。
L04

Upstream：上游

schema_def.lua:756（upstream_schema）核心字段：nodes（后端实例 host:port + weight）、type（负载均衡算法）、scheme（http/https/grpc）、checks（健康检查）、discovery_type（服务发现）、timeout、retries。

读法：Upstream 描述"一组后端 + 怎么在它们之间分流"。nodes 可以是静态列表，也可留空用 discovery_type（Day 16 服务发现动态获取）。Day 10 的负载均衡就是在 nodes 里按 type 挑一个。Route/Service 都能引用 upstream_id 复用。
L05

Consumer：调用方身份

schema_def.lua:715-755：username + plugins（consumer 专属插件，通常是鉴权凭据如 key-auth 的 key）+ group_id。

📝 一个 consumer 长这样 
{ "username": "alice",
  "plugins": { "key-auth": { "key": "alice-secret-123" } } }
请求带 key: alice-secret-123 → 鉴权插件识别出"这是 alice" → 能给 alice 用专属配置（Day 04 的二次合并、Day 14）。
Consumer = "谁在调 API" 用 username（非数字 id）做 key（/apisix/consumers/alice）。Day 14 详讲鉴权。
L06

Plugin Config / Global Rule

  • Plugin Config（:1018）：可复用的一组插件配置（只有 plugins，比 Service 更轻、不含上游）。Route 用 plugin_config_id 引用。
  • Global Rule（:905）：对所有请求生效的插件（不绑任何路由）。Day 04 "匹配路由前后都跑 global_rules" 就是它。
三种复用/全局层次 Plugin Config = "可复用插件套餐"；Service = "插件+上游套餐"；Global Rule = "全站生效的插件"（如全局 prometheus 监控、全局限流）。层层递进的复用粒度，不用到处重复配置。还有 Consumer Group（:1039，一组 consumer 共享配置）。
L07

引用关系（合并优先级）

Route（中心） Plugin Config Service（→Upstream） Upstream Consumer（鉴权识别） plugin_config_id service_id upstream_id 合并优先级（越具体越优先）：PluginConfig < Service < Route < ConsumerGroup < Consumer
Route 引用 plugin_config/service/upstream 复用；consumer 鉴权后合并。越具体的层优先级越高。
合并顺序（Day 04 见过，Day 13 细讲） Route 基础 → 合并 plugin_config → 合并 service → 识别 consumer 后合并 consumer 配置。越具体的覆盖越通用的（consumer > route > service）。这套引用+合并模型让配置既能复用又能精细定制——和上一站 Higress Console 相通。
L08

今日小结 + 动手

🧠 今天你应该能回答

  • 六大对象在 etcd 怎么组织？schema 在哪定义？
  • Route 为什么是"中心枢纽"？绑定了哪三件事？
  • Service / Plugin Config / Global Rule 的复用粒度差异？
  • Consumer 怎么代表"调用方身份"？合并优先级链？

✋ 动手

cd /Users/bitmart/work/codes/github/apisix
sed -n '553,620p' apisix/schema_def.lua      # route
sed -n '684,760p' apisix/schema_def.lua      # service/consumer/upstream
grep -n "^_M\." apisix/schema_def.lua | head -30
明天预告 · Day 09：这些对象存入前要校验字段合法性——schema 校验。看 core/schema.lua 怎么用 JSON Schema 校验，以及"在写入端挡住坏配置"的设计。
← Day 07 Day 09 · schema →