FDE W7D6 学习手册 · 单一调用链设计与部署交付基础

W7 Day6 · B 级（部署交付核心）· 4h · 学完能讲清"为什么只用一层路由/重试/成本统计 + Docker 部署 AI 服务的关键点"

一、企业 AI 调用链总览：为什么需要"统一调用链"

1.1 问题来源

一个企业 AI 平台，调用会穿过多个组件：业务应用、应用框架（Spring AI）、网关（LiteLLM）、模型服务。每一层都可能"好心"地加上路由、重试、成本统计——结果就是重复做、互相冲突、账目混乱。

1.2 核心原则

二、企业模式：业务 → Spring AI → LiteLLM → 模型

2.1 调用链

2.2 各层职责（企业模式）

三、学习/自研模式：业务 → 自研 Model Adapter → 模型

3.1 调用链

3.2 适用场景

对应 D4/D5 的"自研 Gateway"路线：公司没有/不用 LiteLLM，自己写一层 Model Adapter 统一各家调用、做简单路由与重试。常见于已有强 Java 治理体系、不愿引入 Python 组件的情况。

3.3 与企业的区别

• 企业模式：治理在独立网关，Adapter 很薄（Spring AI 直接对接）。
• 自研模式：治理在自研 Adapter 里，要自己实现路由/重试/（可能）成本——责任更重（呼应 D5 自研成本）。

四、为什么只用一层路由（避免两层路由冲突）

4.1 两层路由的问题

若 Spring AI 业务侧做一层路由（"这个请求走模型 A"），网关又做一层路由（"这个 Key 走模型 B"），两者可能决策冲突或叠加：

• 业务选 A，网关因预算/白名单改到 B，业务不知道，结果不符合预期。
• 两层都按不同策略路由，行为不可预测、难调试。

4.2 正确做法

五、为什么只用一层重试（避免重试风暴与重复统计）

5.1 两层重试的灾难

Spring AI 重试 3 次、网关又重试 3 次 → 一次失败最多产生 3×3=9 次 实际请求。这叫重试放大 / 重试风暴：

• 模型侧压力被放大多倍，可能压垮模型或触发厂商限速。
• 成本被放大（重试也花钱）。
• 延迟叠加（每层都等超时）。

5.2 重试该放哪层

六、成本统计只在一层做（避免 double count）

6.1 重复统计的后果

若 Spring AI 侧记录"本次花费"、网关（LiteLLM）也记录"本次花费"，同一请求被记两次 → 成本报表翻倍，Chargeback 算错，业务线互相甩锅。

6.2 唯一可信来源

• 网关层有真实 token 数 + 厂商单价 → 唯一权威。
• 应用层若想看成本，应从网关拉报表，而不是自己再算一遍。
• 应用层只记录"本次用了哪个模型、多少 token（估计）"用于自身 Trace，不作为结算依据。

七、Docker 基础：AI 服务容器化

7.1 为什么用 Docker 部署 AI 服务

• 环境一致：开发、测试、生产同一镜像，避免"我本地能跑"。
• 隔离：模型服务/网关/业务各自容器，互不污染。
• 可移植：K8s（D7）直接编排容器。

7.2 镜像要点（AI 场景）

八、Docker Compose 编排多服务

8.1 什么时候用

单机演示 / PoC / 小团队：用 docker-compose.yml 一把起"网关 + 数据库 + 业务"多个容器，定义网络和依赖顺序。

# 简化示例：网关 + 数据库
services:
  litellm:
    image: ghcr.io/berriai/litellm:main
    ports: ["4000:4000"]
    environment:
      - DATABASE_URL=postgresql://user:pass@db:5432/litellm
    depends_on: [db]
    secrets: [litellm_master_key]
  db:
    image: postgres:16
    volumes: ["pgdata:/var/lib/postgresql/data"]
volumes: { pgdata: {} }

8.2 局限

Compose 适合单机，没有自动扩缩容、自愈、多节点。生产上这些交给 K8s（D7）。

九、环境隔离（dev / staging / prod）

9.1 为什么隔离

开发、测试、生产必须隔离，否则：测试数据污染生产、实验性 Prompt 影响真实用户、密钥混用导致越权。

9.2 隔离维度

十、Secret 管理（API Key / 数据库密码）

10.1 原则

• 绝不进代码/镜像/Compose 明文：厂商 Master Key、DB 密码走 Secret 管理。
• 外部 Secret 管理：K8s Secret / Vault / 云 Secret Manager，运行时注入环境变量或挂载文件。
• 最小权限：每个服务只拿到它需要的 Secret。
• 可轮换：Key 泄露能快速轮换，不重启业务（呼应 D5 虚拟 Key）。

10.2 对比

十一、Health Check 与 Readiness Check 的区别

11.1 两个探针

11.2 为什么 AI 服务特别要区分

• 大模型加载权重要几十秒~几分钟，进程活了但模型没就绪——此时应 Readiness=false，别接流量，但别重启（Liveness=true）。
• 网关依赖的 DB 短暂不可达，Readiness=false 暂时摘流，恢复后自动加回。

十二、AI 服务部署的工程交付 Checklist

12.1 上线前清单

十三、面试达标线①：只用一层路由/重试/成本

十四、面试达标线②：Docker 部署 AI 服务的关键点

1. 镜像：模型权重走挂载不进镜像、非 root、依赖锁版本。
2. 编排：Compose 做演示，K8s 做生产（扩缩容/自愈）。
3. 隔离：dev/staging/prod 网络+配置+数据+密钥全隔离。
4. Secret：不落代码，走 Vault/云，etcd 加密 + RBAC + 轮换。
5. 探针：Liveness（重启）与 Readiness（摘流）分开，阈值适配模型加载。
6. 降级/可观测/资源限：网关挂有兜底、Trace 串联、GPU/内存设限。

十五、W7D6 自测清单

十六、高频面试题速记卡