从原型到生产的鸿沟
写个Demo容易，上线生产难。原型可能只需要100行代码，但生产系统需要考虑：高并发、容错、监控、安全、成本、可维护性。
原型 vs 生产的核心差异：
| 维度 | 原型 | 生产 |
|---|---|---|
| 并发 | 1个用户 | 1000+并发 |
| 容错 | 出错就报错 | 自动重试、降级、熔断 |
| 监控 | print调试 | 日志、指标、告警、追踪 |
| 安全 | 硬编码API key | 密钥管理、权限控制、审计 |
| 成本 | 无所谓 | 预算控制、用量限制 |
| 部署 | 本地运行 | CI/CD、容器化、自动扩缩容 |
生产级AI系统的核心组件：
- API层：RESTful API或gRPC，统一入口
- 缓存层：Redis缓存常见查询结果
- 队列层：RabbitMQ/Kafka处理异步任务
- 模型服务：GPU集群或云API
- 监控层：Prometheus + Grafana
- 日志层：ELK Stack (Elasticsearch + Logstash + Kibana)
API设计与缓存策略
API设计原则：
1. 幂等性：同一请求多次调用，结果相同。POST/PUT应该是幂等的。实现：每个请求带唯一ID，服务端去重。
2. 版本控制：/v1/chat, /v2/chat。避免破坏性更新影响现有用户。
3. 限流：Token Bucket或Leaky Bucket算法。防止单个用户耗尽资源。
4. 超时与重试：设置合理的超时时间（如30秒）。失败时指数退避重试：1s, 2s, 4s, 8s。
缓存策略：
1. 结果缓存：相同输入直接返回缓存结果 适用：常见问题、固定知识查询 TTL: 1小时~1天 2. 向量缓存：缓存Embedding结果 适用：重复查询的文本 节省：Embedding API调用费用 3. 会话缓存：缓存对话历史 适用：多轮对话 避免：每次请求重复发送历史 4. 多级缓存： L1: 本地内存 (Redis) - 10ms L2: 分布式缓存 (Redis Cluster) - 50ms L3: 数据库 - 200ms
参数表：
| 参数 | 含义 | 典型值 | 太大/太小 |
|---|---|---|---|
| 缓存TTL | 缓存过期时间 | 1h~24h | 太长→数据陈旧；太短→缓存失效 |
| 限流QPS | 每秒最大请求数 | 10~1000 | 太高→资源耗尽；太低→用户体验差 |
| 超时时间 | 最大等待时间 | 30s~60s | 太长→资源占用；太短→正常请求失败 |
代码实战：生产级API服务
练习：工程整合
Q1：为什么生产系统需要幂等性？如何实现请求的幂等性？
Q2：缓存的TTL设置需要考虑哪些因素？如果TTL=1秒和TTL=1天分别有什么问题？
Q3：限流的Token Bucket和Leaky Bucket算法有什么区别？
Q4：为什么生产API需要版本控制（/v1/, /v2/）？如果不做版本控制会怎样？
Q5：设计一个AI客服系统的架构。需要哪些组件？如何处理高并发？
查看答案
A1：幂等性防止重复操作。网络超时后客户端重试，如果没有幂等性，同一个请求可能被执行多次（如扣款两次）。实现：每个请求带唯一ID，服务端记录已处理的ID，重复请求直接返回之前的结果。
A2：TTL需要考虑数据更新频率和用户期望。TTL=1秒：缓存几乎失效，每次都要重新计算，缓存失去意义。TTL=1天：数据可能陈旧，用户看到过期信息。平衡：频繁变化的数据TTL短（分钟级），稳定数据TTL长（天级）。
A3：Token Bucket：桶里有固定数量的token，每个请求消耗一个token，token以固定速率补充。允许突发流量（桶里有token就能处理）。Leaky Bucket：请求进入桶，以固定速率流出。平滑流量，不允许突发。Token Bucket更灵活，Leaky Bucket更严格。
A4：版本控制允许平滑升级。不做版本控制：修改API后，旧客户端可能崩溃。例如：把字段name改成full_name，旧客户端找不到name字段就报错。版本控制让新旧客户端共存。
A5：组件：API网关（限流、认证）、AI服务（LLM + RAG知识库）、对话管理（维护会话状态）、缓存层（Redis）、消息队列（异步任务）、监控告警（Prometheus）、日志系统（ELK）。高并发：水平扩展（多实例负载均衡）、缓存热点问题、异步处理非实时任务、数据库读写分离。