docs(arch): routing & failover strategy — random/sticky/health, max 3 switches (v0.2)

docs/architecture.md

@@ -1,5 +1,6 @@
 # AITokenPool 架构设计
 
+> v0.2（2026-08-15）· 新增 4.2.1 路由与故障转移策略（随机初始选择 / 粘性 / 静默故障转移 / 3 次切换上限 / 5 秒健康冷却 / 健康优先）
 > v0.1（2026-08-13）· 基于 openlocalrouter 演进
 
 ## 1. 定位
@@ -64,6 +65,20 @@
 - 公共：分享者上传 key → 进共享池
 - key 状态：可用/失效/限额/撤销
 
+#### 4.2.1 路由与故障转移策略（v0.2，宿主 2026-08-14 定案）
+
+当消费者请求某模型 M 时，网关从多个分享者提供的该模型 key 中选择（公共版共享池；企业版 key 池同规则）。定案规则共 7 条：
+
+1. **初始选择（随机）**：用户首次请求模型 M 时，从 M 的**健康** key 池中**随机**选择一个（如 B1 或 B2）；
+2. **粘性（Sticky）**：选定后，该用户**后续请求都复用这个 key**，直到它不可用；
+3. **不可用判定**：key 下架（分享者删除 / 暂停）、key 报错（上游错误 / 鉴权失败 / 额度用尽）等；
+4. **故障转移（静默）**：当前 key 不可用时，**静默**选择下一个健康 key（用户无感，不打断请求）；
+5. **切换上限**：**每次路由最多允许 3 次切换**；3 次都失败 → 报错返回（如「该模型暂无可用 key」）；
+6. **健康标记**：任何**在用的 key 报错 → 标记为「非健康」5 秒**（5 秒内不参与选择）；
+7. **健康优先**：选择 key 时**优先选择当前健康**的 key（非健康 key 排除，5 秒冷却后可重新进入候选）。
+
+**示例流程**：A 请求模型 M → 随机选 B1（健康）→ A 的后续请求粘性复用 B1 → B1 报错（额度用尽）→ 静默切换 B2（第 1 次）→ B2 也报错 → 切换 B3（第 2 次）→ 成功返回；若 B1/B2/B3 均失败（第 3 次也失败）→ 返回「该模型暂无可用 key」。B1 报错后标记非健康 5 秒，冷却后可重新参与选择。
+
 ### 4.3 计量引擎
 - 每次调用记录：用户、模型、输入/输出 token、成本
 - 换算点数（按模型单价）