很多工程师学AI和学架构是"两条线"——学架构时没AI，学AI时不谈架构。
但AI应用上了生产，该遇到的问题一个不少：高并发、服务拆分、缓存、消息队列……
这篇文档把传统架构概念和AI场景一一对应，每个配一个真实案例，说清楚怎么结合、为什么这样结合。
一、微服务架构 → AI 服务拆分
传统概念
把单体应用拆成独立部署、独立演进的服务，每个服务负责一个业务域，通过API通信。
AI场景结合
AI应用不是"一个模型接口"就完事了。一个完整的AI应用至少拆成：模型推理服务、Prompt编排服务、RAG检索服务、Agent调度服务、向量库服务——每个的扩缩容策略、故障模式、资源需求完全不同。
📋 案例：智能客服系统的微服务拆分
plaintext
用户请求
│
▼
API Gateway (限流/路由/鉴权)
│
├─→ Intent Service（意图识别 - 轻量模型，延迟要求极高）
│ └─ GPU: T4 即可，实例数 ×10（高频低算力）
│
├─→ RAG Service（知识检索 - 向量库 + Embedding）
│ └─ CPU密集，独立扩缩容，缓存策略完全不同
│
├─→ LLM Service（大模型推理 - 重度GPU）
│ └─ GPU: A100/H100，实例数 ×2（低频高算力）
│
├─→ Tool Service（工具调用 - 外部API编排）
│ └─ IO密集，无需GPU，按外部API限流
│
└─→ Session Service（对话状态管理）
└─ Redis + DB，纯状态服务
核心思路：意图识别用小模型快速响应（T4就够，但要多个实例扛并发），大模型推理用大GPU但实例少（一个A100顶十个T4），RAG单独拆出来做缓存优化。如果全塞一个服务，GPU资源要么浪费要么不够。
二、高并发 → AI 请求的流量治理
传统概念
系统在短时间内处理大量请求的能力，核心手段：限流、降级、异步、池化。
AI场景结合
LLM推理天然慢（一次请求2-30秒）且贵（按Token计费），高并发场景下不能像传统API一样硬扛。需要：请求排队 + 优先级调度 + 流式返回 + 语义限流。
📋 案例：AI写作助手的并发治理
plaintext
┌─────────────────┐
1000 req/s ────→ │ 请求网关 │
│ ┌───────────┐ │
│ │ 语义限流器 │ │ ← 不是按QPS限，而是按"意图"限
│ └───────────┘ │
│ ┌───────────┐ │
│ │ 优先级队列 │ │ ← VIP用户优先、实时对话 > 批量生成
│ └───────────┘ │
└────────┬────────┘
│
┌──────────────┼──────────────┐
▼ ▼ ▼
实时对话队列 文档生成队列 翻译队列
(P0, ≤5s) (P1, ≤30s) (P2, ≤60s)
│ │ │
▼ ▼ ▼
GPU Pool A GPU Pool B GPU Pool C
(A100×4) (A100×2) (T4×8)
关键设计：
语义限流：不是粗暴按QPS限，而是识别请求意图。100个"闲聊"请求可以限流，但1个"紧急工单处理"不能挡
分级队列：实时对话（打字时补全）延迟要求<500ms，文档生成可以30s，翻译可以1min——混在一起会互相拖慢
流式返回：SSE（Server-Sent Events）把30秒的等待变成"逐字出现"，体感延迟从30s降到0.5s
降级策略：A100打满时，非实时请求降级到小模型（Qwen-7B替代Qwen-72B），质量降但不断服
三、分布式系统 → AI 推理集群
传统概念
多台机器协同工作，核心挑战：一致性、分区容错、故障恢复、数据分片。
AI场景结合
大模型推理不是"一台机器跑一个模型"那么简单。大模型需要张量并行（一个模型切到多卡），小模型需要数据并行（多卡跑多份），还需要模型热切换（不停服换模型版本）。这是分布式系统的新战场。
📋 案例：多模型推理集群的部署架构
plaintext
┌──────────────────┐
│ Model Router │
│ (模型路由层) │
│ 按请求特征路由到 │
│ 最优推理实例组 │
└────────┬─────────┘
│
┌──────────────────┼──────────────────┐
▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Instance │ │ Instance │ │ Instance │
│ Group A │ │ Group B │ │ Group C │
│ │ │ │ │ │
│ Qwen-72B │ │ Qwen-7B×4 │ │ Embedding │
│ TP=4 (4卡) │ │ DP=4 (4实例) │ │ DP=2 │
│ A100×4 │ │ T4×4 │ │ T4×2 │
│ │ │ │ │ │
│ 长文本/复杂 │ │ 短对话/快速 │ │ 向量检索 │
└──────────────┘ └──────────────┘ └──────────────┘
TP = Tensor Parallelism (张量并行，一个模型切到多卡)
DP = Data Parallelism (数据并行，多卡跑多份)
关键设计：
TP（张量并行） ：72B模型太大，一张卡放不下，切成4份放到4张A100上协同推理——这就是分布式系统里的"分片"思想
DP（数据并行） ：7B模型一张卡就够，但并发高，跑4份——这就是"水平扩展"
模型路由：根据请求的token长度和复杂度，路由到不同的实例组——短对话走7B快而省，长文档走72B准而慢
故障恢复：Group A某卡挂了，整个Group A标记不可用（TP要求所有卡都在），请求自动路由到其他Group——和分布式系统的故障转移一个逻辑
四、缓存 → AI 的语义缓存
传统概念
用空间换时间，把计算结果存起来，下次相同请求直接返回。经典：Redis、CDN。
AI场景结合
传统缓存是精确匹配（key完全相同才命中），但LLM请求天然具有语义相似性——"Python怎么读文件"和"Python读取文件的方法"是同一个问题，精确匹配完全命中不了。需要语义缓存：用Embedding算相似度，超过阈值就返回缓存结果。
📋 案例：RAG客服系统的语义缓存
plaintext
用户A问："退货流程是什么？"
│
▼
Embedding → 向量 [0.12, 0.87, 0.34, ...]
│
▼
语义缓存查找 → 相似度 0.97（超过阈值0.95）
│
▼
缓存命中！直接返回，0.05秒（省了3秒推理+0.5秒检索+¥0.02 Token费）
---
用户B问："怎么办理退款？"
│
▼
Embedding → 向量 [0.11, 0.85, 0.33, ...]
│
▼
语义缓存查找 → 相似度 0.94（低于阈值0.95）
│
▼
缓存未命中 → 走完整RAG+LLM链路，3.2秒
│
▼
结果写入缓存（TTL=24h，按业务热度衰减）
缓存分层设计：
plaintext
┌────────────────────────────────────────┐
│ L1: 精确缓存 (Redis) │ 命中率 15%，延迟 <5ms
│ key = hash(prompt + system_prompt) │ 完全相同的问法
├────────────────────────────────────────┤
│ L2: 语义缓存 (Vector DB) │ 命中率 35%，延迟 ~50ms
│ key = embedding相似度 > 0.95 │ 不同问法但同一意图
├────────────────────────────────────────┤
│ L3: 组件缓存 (Redis) │ 命中率 40%，延迟 <10ms
│ 缓存RAG检索结果、Embedding结果 │ 检索结果不变则复用
└────────────────────────────────────────┘
总命中率 ~70%
每月Token费用降 60%+
关键洞察：传统缓存追求"命中率"，语义缓存还要追求"准确率"——相似度0.90的缓存结果可能是错的（用户问的是"退货"但缓存的是"换货"），阈值设高了命中率低、设低了准确率差，这是AI场景特有的权衡。
五、消息队列 → AI 异步任务编排
传统概念
生产者-消费者模式，解耦、削峰、异步。经典：Kafka、RabbitMQ、RocketMQ。
AI场景结合
AI任务天然适合异步——批量翻译、文档摘要、代码Review，用户不需要等。但AI异步任务比传统异步更复杂：每个任务可能调用多次LLM（Agent循环），需要中间状态追踪（进行到哪一步了），还有Token预算控制（一次任务花多少钱要可控）。
📋 案例：AI代码Review系统的异步编排
plaintext
开发者提交PR
│
▼
┌─────────────────────────────────────┐
│ Webhook → 消息队列 (Kafka) │
│ Topic: code-review-requests │
│ Message: {repo, pr_id, diff_url} │
└──────────────┬──────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ Review Coordinator (Consumer) │
│ 1. 拉取diff，按文件拆分子任务 │
│ 2. 每个子任务发到不同Topic │
└─────┬──────────┬──────────┬────────┘
│ │ │
▼ ▼ ▼
Topic: Topic: Topic:
security style logic
-check -check -check
│ │ │
▼ ▼ ▼
Security Style Logic
Agent Agent Agent
(LLM×1) (LLM×1) (LLM×3)
│ │ │
▼ ▼ ▼
Topic: review-results (汇总)
│
▼
┌─────────────────────────────────────┐
│ Aggregator (Consumer) │
│ 1. 等所有子任务完成（CountdownLatch）│
│ 2. 汇总结果，去重，排序 │
│ 3. 生成最终Review报告 │
│ 4. 回写PR Comment │
└─────────────────────────────────────┘
进度追踪：Redis Hash
key: review:{pr_id}
fields: {security: "done", style: "running", logic: "pending",
total_cost: ¥0.12, start_time: "10:00"}
关键设计：
任务拆分：一个大PR的Review不能一个LLM调用搞定——按关注点（安全/风格/逻辑）拆成子任务，并行执行
中间状态追踪：开发者随时能看到"安全检查完成、逻辑检查进行中"——传统消息队列没有这个，需要额外用Redis记录
Token预算：每个子任务设置max_tokens，Aggregator检查总花费，超预算就跳过剩余子任务返回已有结果
死信队列：某个Agent卡住了（LLM超时），超时后进DLQ，Aggregator用已有结果凑合交付，不卡整个流程
六、负载均衡 → AI 请求的智能路由
传统概念
把请求分发到多个后端实例，策略：轮询、加权、最少连接、一致性哈希。
AI场景结合
AI推理的负载均衡比传统场景多一个维度：不同请求的"成本"差异巨大。一个100 token的短对话和10000 token的长文档分析，占用的GPU时间和显存差100倍。传统"最少连接数"策略会严重不均。
📋 案例：多模型推理集群的智能路由
plaintext
请求进来
│
▼
┌──────────────────────────────────────────┐
│ Smart Router │
│ │
│ Step 1: 请求分类 │
│ - 短对话 (<500 token) → 轻量队列 │
│ - 长文档 (>5000 token) → 重量队列 │
│ - Embedding请求 → 向量队列 │
│ │
│ Step 2: 实例选择 │
│ - 轻量队列 → 剩余显存 > 4GB 的实例 │
│ - 重量队列 → 剩余显存 > 16GB 的实例 │
│ - 向量队列 → 最低队列深度的实例 │
│ │
│ Step 3: 预测性调度 │
│ - 当前队列预计等待时间 > 阈值？ │
│ → 降级到小模型 or 返回排队提示 │
│ - 某实例刚完成长请求？ │
│ → 冷却期，暂不分配长请求（KV Cache │
│ 还在清理，显存未完全释放） │
└──────────────────────────────────────────┘
与传统负载均衡的对比：
表格
七、API网关 → AI 网关
传统概念
统一入口，负责鉴权、限流、路由、日志、协议转换。经典：Nginx、Kong、Spring Cloud Gateway。
AI场景结合
AI网关在传统网关基础上，多了：Token计费、模型路由、Prompt注入、内容安全审核、多模型Fallback。它不只是"请求转发器"，更是"AI流量控制器"。
📋 案例：企业AI中台的统一网关
plaintext
所有AI请求统一入口
│
▼
┌──────────────────────────────────────────────┐
│ AI Gateway │
│ │
│ ① 鉴权 & 配额 │
│ - API Key / OAuth2 校验 │
│ - 按团队/项目设置Token配额 │
│ - 用量实时扣减（Redis原子操作） │
│ │
│ ② Prompt 管理 │
│ - 注入系统Prompt（角色设定、安全约束） │
│ - Prompt模板变量替换 │
│ - 敏感词过滤（输入 & 输出双向） │
│ │
│ ③ 模型路由 & Fallback │
│ - 主模型: GPT-4o │
│ - 降级链: GPT-4o → Claude → Qwen → 429 │
│ - 按成本/延迟/质量三维路由 │
│ │
│ ④ 可观测性 │
│ - 每次请求: 输入token数、输出token数、 │
│ 模型名、延迟、成本、是否缓存命中 │
│ - 实时Dashboard: QPS/成本/错误率 │
│ │
│ ⑤ 流式协议转换 │
│ - OpenAI格式 ↔ Anthropic格式 ↔ 自研格式 │
│ - 统一输出SSE流 │
└──────────────────────────────────────────────┘
关键设计：
Token计费：传统网关按请求次数计费，AI网关必须按Token计费——一个请求可能花¥0.001也可能花¥1，不按Token收费团队间根本算不清
Prompt注入：网关层统一注入安全Prompt（"你不能泄露公司内部信息"），应用层不需要各自写——防的的就是某个应用忘了加
多模型Fallback：GPT-4o挂了自动切Claude，Claude也挂了切本地Qwen——和传统网关的"上游故障转移"逻辑一样，但多了一个"降级不降断"的选择
八、可观测性 → AI 链路追踪
传统概念
Metrics（指标）、Logs（日志）、Traces（链路追踪）三位一体。经典：Prometheus + Grafana + ELK + Jaeger。
AI场景结合
AI应用的可观测性多了两个核心维度：Token消耗和LLM决策质量。传统链路追踪只关心"哪一步慢"，AI链路追踪还要关心"哪一步LLM产生了幻觉"、"哪一步工具调用选错了"。
📋 案例：Agent系统的全链路追踪
plaintext
用户问："帮我查一下订单12345的物流状态"
│
▼ Span: root (总耗时 4.2s, 总Token 856, 总成本 ¥0.08)
│
├─ Span: intent-recognition (0.3s, 120 tokens)
│ result: {intent: "logistics_query", entities: {order_id: "12345"}}
│ ✓ 意图识别正确
│
├─ Span: tool-selection (0.2s, 85 tokens)
│ result: selected_tool = "query_logistics"
│ ✓ 工具选择正确
│
├─ Span: tool-execution (0.8s, 0 tokens)
│ ├─ Span: api-call → 物流系统 (0.6s)
│ │ result: {status: "运送中", location: "北京分拨中心"}
│ │ ✓ API调用成功
│ │
│ └─ Span: api-call → 订单系统 (0.2s)
│ result: {order_id: "12345", product: "手机壳"}
│ ✓ API调用成功
│
├─ Span: response-generation (2.5s, 651 tokens)
│ result: "您的订单12345（手机壳）目前正在运送中..."
│ ✓ 回答准确，无幻觉
│
└─ Span: quality-check (0.4s, 0 tokens - 规则引擎)
result: PASS (事实与API返回一致)
AI场景特有的监控指标：
表格
关键洞察：传统可观测性回答"系统健不健康"，AI可观测性还要回答"AI靠不靠谱"。一个系统可能99.9%可用，但如果LLM 30%的时候在胡说，用户体验一样是灾难。
九、服务网格 → AI 服务治理
传统概念
以Sidecar模式治理服务间通信：流量控制、熔断、灰度发布、mTLS。经典：Istio、Linkerd。
AI场景结合
AI服务间的通信治理更复杂：模型版本灰度（新模型只放5%流量）、基于质量的熔断（错误率飙升时自动切回旧模型）、A/B测试（对比两个模型的效果）。
📋 案例：模型灰度发布 + 质量熔断
plaintext
┌──────────────────────────────────────────────┐
│ AI Service Mesh (Sidecar Proxy) │
│ │
│ 灰度策略: │
│ - Qwen-72B-v1 (旧版): 95% 流量 │
│ - Qwen-72B-v2 (新版): 5% 流量 │
│ │
│ 质量监控 (Sidecar实时统计): │
│ - v1: 幻觉率 2.1%, 平均延迟 3.2s │
│ - v2: 幻觉率 8.7%, 平均延迟 2.8s ← 注意! │
│ │
│ 熔断触发: │
│ - v2幻觉率 > 5% 持续 5分钟 → 熔断 │
│ - 自动将v2流量切回v1 │
│ - 告警通知模型团队 │
│ │
│ 逐步放量 (质量达标后): │
│ - Day 1: 5% → 10% → 25% │
│ - Day 2: 25% → 50% → 100% │
│ - 每个阶段观察30分钟，质量不达标自动回滚 │
└──────────────────────────────────────────────┘
与传统灰度的核心区别：传统灰度看"错误率"（HTTP 5xx），AI灰度看"质量"（幻觉率、工具调用成功率）。一个模型可能从不返回5xx，但回答完全不对——传统熔断发现不了这个问题。
十、数据库分库分表 → 向量数据库的水平扩展
传统概念
数据量大了单库扛不住，按业务或规则拆分。经典：按用户ID哈希分库、按时间分表。
AI场景结合
向量数据库的扩展比传统数据库更难：向量检索需要全局TopK，不能只查一个分片就返回。传统分库分表每个查询只走一个分片，向量检索每个查询要走所有分片再合并——这就是"散播-聚合"（Scatter-Gather）模式。
📋 案例：亿级文档的向量检索架构
plaintext
查询: "AI工程化最佳实践"
│
▼
┌────────────────────────────────────────┐
│ Query Router (查询路由) │
│ 1. Embedding查询向量 │
│ 2. 预过滤: 只查相关分片（按业务标签） │
└───────┬──────────┬──────────┬─────────┘
│ │ │
▼ ▼ ▼
Shard A Shard B Shard C
(技术文档) (产品文档) (运营文档)
TopK=20 TopK=20 TopK=20
│ │ │
└──────────┴──────────┘
│
▼
Global Re-Rank (全局重排)
60个候选 → Cross-Encoder精排 → TopK=5
│
▼
最终结果返回
分片策略对比：
表格
关键洞察：传统分库分表的目标是"每个查询只走一个分片"，向量分片做不到这点。所以AI场景的分片策略重点不是"怎么让查询只走一个分片"，而是"怎么让查询尽量少走分片"——业务标签预过滤是最实用的手段。
十一、DevOps/CI-CD → AI 工程的 MLOps
传统概念
持续集成/持续交付，代码提交→自动测试→自动部署。经典：Jenkins、GitHub Actions、GitLab CI。
AI场景结合
AI应用的"代码"不只是程序代码，还有Prompt、模型、向量数据、评测集。CI/CD需要扩展为：Prompt变更自动评测 → 模型切换自动灰度 → 向量数据变更自动验证。
📋 案例：AI应用的CI/CD流水线
plaintext
开发者提交代码 (含Prompt变更)
│
▼
┌─────────────────────────────────────────┐
│ Stage 1: 单元测试 (2min) │
│ - 工具调用逻辑测试 │
│ - Prompt模板渲染测试 │
│ - 向后兼容性测试（新Prompt能处理旧格式） │
└──────────────┬──────────────────────────┘
│ pass
▼
┌─────────────────────────────────────────┐
│ Stage 2: 评测集回归 (15min) │
│ - 跑500条标准评测集 │
│ - 对比新旧Prompt/模型的结果 │
│ - 关键指标: 准确率≥95%, 幻觉率≤3% │
│ - 任何指标下降 >2% → 流水线失败 │
└──────────────┬──────────────────────────┘
│ pass
▼
┌─────────────────────────────────────────┐
│ Stage 3: 灰度部署 (30min观察) │
│ - 5%流量到新版本 │
│ - 实时监控质量指标 │
│ - 质量不达标 → 自动回滚 │
└──────────────┬──────────────────────────┘
│ pass
▼
┌─────────────────────────────────────────┐
│ Stage 4: 全量发布 │
│ - 逐步放量到100% │
│ - 保留旧版本24h可快速回退 │
└─────────────────────────────────────────┘
与传统CI/CD的区别：
表格
十二、安全架构 → AI 安全部防
传统概念
认证、授权、加密、WAF、SQL注入防护、XSS防御。
AI场景结合
AI应用面临全新的攻击面：Prompt注入（让AI绕过安全约束）、数据泄露（从RAG中套取敏感信息）、模型窃取（通过大量请求反推模型）。传统的WAF和SQL注入防护完全防不住这些。
📋 案例：AI应用的安全纵深防御
plaintext
用户输入
│
▼
┌─────────────────────────────────────────┐
│ Layer 1: 输入过滤 (网关层) │
│ - Prompt注入检测（已知攻击模式匹配） │
│ - 敏感信息脱敏（身份证号、银行卡号） │
│ - 输入长度/格式限制 │
└──────────────┬──────────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ Layer 2: System Prompt 防护 (编排层) │
│ - System Prompt与用户输入严格隔离 │
│ - 明确安全边界指令 │
│ - 工具调用白名单（只能调用已注册工具） │
└──────────────┬──────────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ Layer 3: RAG权限控制 (检索层) │
│ - 向量检索注入用户权限标签 │
│ - 用户只能检索自己有权限的文档 │
│ - 防止越权查询：普通员工搜不到CEO文档 │
└──────────────┬──────────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ Layer 4: 输出审核 (网关层) │
│ - 输出敏感信息检测（是否泄露了内部数据）│
│ - 幻觉检测（回答是否与RAG检索结果一致） │
│ - 合规性检查（是否符合行业规范） │
└──────────────┬──────────────────────────┘
│
▼
安全的AI响应
AI特有攻击与防御：
表格
总结：一张图看全貌
plaintext
┌─────────────────────────────────────────────────────────────────┐
│ AI × 传统架构 结合全景图 │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 微服务 │───→│ AI服务 │ │ 高并发 │───→│ 语义限流 │ │
│ │ 架构 │ │ 拆分 │ │ 治理 │ │ 分级队列 │ │
│ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 分布式 │───→│ 推理集群 │ │ 缓存 │───→│ 语义缓存 │ │
│ │ 系统 │ │ TP/DP │ │ 策略 │ │ 三层缓存 │ │
│ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 消息队列 │───→│ 异步任务 │ │ 负载均衡 │───→│ 智能路由 │ │
│ │ │ │ 编排 │ │ 策略 │ │ 显存感知 │ │
│ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ API网关 │───→│ AI网关 │ │ 可观测性 │───→│ AI链路 │ │
│ │ │ │ Token计费│ │ 三件套 │ │ 质量追踪 │ │
│ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 服务网格 │───→│ 模型灰度 │ │ 分库分表 │───→│ 向量分片 │ │
│ │ │ │ 质量熔断 │ │ │ │ Scatter- │ │
│ └──────────┘ └──────────┘ └──────────┘ │ Gather │ │
│ └──────────┘ │
│ ┌──────────┐ ┌──────────┐ │
│ │ CI/CD │───→│ MLOps │ ┌──────────┐ │
│ │ │ │ 评测集 │ │ 安全架构 │───→│ AI安全 │ │
│ └──────────┘ │ 回归 │ │ │ │ 纵深防御 │ │
│ └──────────┘ └──────────┘ └──────────┘ │
└─────────────────────────────────────────────────────────────────┘
核心原则
AI应用是分布式应用——所有传统架构原则都适用，但每个都需要"AI化适配"
请求成本差异是最大变量——传统请求ms级且成本均匀，AI请求0.1s~30s且成本差100倍，这改变了几乎所有架构决策
质量是新的可用性——传统架构追求"不挂"，AI架构还要追求"不胡说"；99.9%可用但30%幻觉的系统，比95%可用但1%幻觉的系统更危险
缓存是AI省钱的命脉——语义缓存+组件缓存能把Token费用降60%+，这是AI场景ROI最高的优化
可观测性要覆盖"AI层" ——传统Metrics只看系统健康，AI场景还要看模型决策质量、Token消耗、缓存效果
评论区