11 - 真实生产怎么做：业务打镜像 + 数据买云服务

前面我们搞清楚了：业务（无状态）和数据（有状态）要分开对待。那真实的生产环境里，到底是怎么落地的？这一章把整个主流思维讲透——不展开技术细节，重在建立全局认知。

先认识一个”理论上的完美答案”：Kubernetes（K8s）

当容器多到一定规模（几十上百个、跨多台服务器），你会需要一个”容器总指挥”来自动管理：

• 哪台机器资源够，就把容器调度到哪
• 某个容器挂了，自动拉起一个新的
• 流量大了自动扩容，流量小了自动缩容
• 滚动更新、负载均衡……

这个”总指挥”就是 Kubernetes（简称 K8s），它是大规模容器编排的事实标准。

但是：K8s 太重了

K8s 很强，但对绝大多数团队（尤其是中小团队、AI 创业项目）来说，它太重了：

• 概念极多、学习曲线陡峭（Pod、Service、Deployment、Ingress……一大堆）
• 自己搭建和维护一套 K8s 集群，需要专门的运维团队
• 杀鸡用牛刀：你可能就几个服务，犯不上上这么重的体系

所以——知道有 K8s 这个东西、它解决什么问题就够了，大多数情况下你不需要一上来就碰它。

主流的务实做法（重点记这个）

绝大多数团队，尤其是 AI 应用团队，实际是这么干的：

自己的业务代码 → 打包成 Docker 镜像 → 部署运行； 数据库、缓存、对象存储这些 → 直接买云服务商的托管服务。

拆开看：

1. 业务部分：打成 Docker 镜像去跑

• 你的 FastAPI / AI 服务，就用前面学的方式打成镜像。
• 部署到云上时，可以用各家云的”容器服务”（如阿里云 ACK/Serverless 容器、AWS ECS、各种 PaaS 平台），甚至直接在一台云服务器上 docker run。
• 因为业务是无状态的，所以可以随便重启、随便多开几份来扛流量——这正是容器最擅长的。

2. 数据部分：直接买云上的托管服务

• 数据库 → 买云数据库（如 RDS、云 MySQL/PostgreSQL）
• 缓存 → 买云 Redis
• 向量数据库 → 买托管的向量库服务
• 文件/模型存储 → 买对象存储（如 OSS、S3）

为什么买云服务，而不是自己用容器跑？ 因为云厂商帮你搞定了最难、最不能出错的部分：

• 自动备份、容灾、高可用
• 故障自动恢复、专业团队 7×24 运维
• 一键扩容、性能监控

你花点钱，把”数据绝对不能丢”这件最操心的事外包给专业的人，自己只专注写业务。这对小团队是性价比极高的选择。

把整条思维线串起来

到这里，整个知识体系就完整了：

单个容器        →  docker run            （学会跑一个服务）
多个容器(本地)   →  docker compose        （本地一键拉起整套环境）
            ↓  到了生产，业务和数据要分开
生产环境：
   业务(无状态)  →  打成 Docker 镜像，部署到云/容器平台，可随意扩缩
   数据(有状态)  →  直接买云厂商的托管服务（数据库/缓存/存储）
   超大规模      →  才需要 K8s 这种重型编排（多数团队用不上）

最终的核心认知

• Docker（镜像 + 容器）是地基：把业务打包成”到处能跑”的标准件，这是你最该练熟的。
• Compose 是本地开发利器：一键拉起多容器环境，方便开发测试。
• 生产环境讲究分层：无状态业务用容器灵活伸缩，有状态数据交给专业托管服务。
• K8s 是大规模才需要的重武器：知道它存在、解决什么问题即可，别过早陷进去。

对你们做 AI 应用的人来说，记住这条最实用的路线就够了：

把 AI 业务打成 Docker 镜像部署，数据库/向量库/存储统统买云服务，把精力留给真正创造价值的业务和模型。

小结

• K8s = 大规模容器”总指挥”，强但重，多数团队用不上，知道即可。
• 主流务实做法：业务打镜像跑，数据买云托管服务。
• 背后逻辑：无状态的灵活伸缩，有状态的交给专业的人保管。
• 这套思维，比记住任何一条命令都重要。

上一章 ← 10 - Compose 的局限：业务与数据要分开 ｜ 回到 README 目录