10 - Compose 的局限：业务和数据要分开
Compose 很香，但你可能会产生一个误解：
“那我把业务、数据库、缓存全写进 docker-compose.yml，一键全起，生产环境也这么搞不就完了？”
本地开发这么玩没问题，但真到了生产环境，这是个危险的想法。 这一章讲清楚为什么。
关键区别：业务是”无状态”的，数据是”有状态”的
这是整个思维的核心，先记住这两个词：
- 业务服务（无状态 Stateless）：你的 FastAPI 代码，本身不保存数据。挂了重启一个一模一样的就行，随便删、随便加、随便换机器，没影响。
- 数据库（有状态 Stateful）：它保存着真实数据（用户、订单、向量……）。这些数据一旦丢了就是灾难，不能随便删、随便重建。
一句话：业务可以随时”扔掉重来”，数据不行。 这两类东西的”待遇”必须完全不同。
为什么不该把数据库塞进 Compose 一起跑（在生产）
把数据库当成一个普通容器跟业务捆在一起，会踩这些坑：
- 数据安全没保障：容器天生是”用完即弃”的。一个误操作
docker compose down -v，数据卷被删，数据全没了。生产数据经不起这种风险。 - 没有专业运维能力：真实数据库需要自动备份、故障恢复、主从复制、扩容、监控……自己用容器跑一个，这些全得你手动搞，极易出事。
- 业务和数据被绑死：你想重启/重新部署业务，结果数据库也跟着重启；想给业务扩容，数据库这种有状态的东西却没法简单地复制多份。两者的生命周期本就该独立。
- 性能与可靠性：数据库对磁盘 IO、内存很敏感，和业务挤在一起互相抢资源，出问题难排查。
正确的思维：分层对待
所以业界形成了一个清晰的原则：
业务服务（无状态）用容器跑，灵活、随时可重建； 数据（有状态）单独托管，交给专业、可靠的方案保管。
Compose 把一切都”容器化、一起跑”的模式，适合本地开发和测试（数据丢了无所谓，重建很方便），但不适合直接照搬到生产。
那生产环境里，“数据”这部分到底交给谁？业务这部分又用什么来扛大规模？这就是下一章要讲的——真实生产的主流做法。
小结
- 容器世界里要分清两类东西：无状态的业务 vs 有状态的数据。
- 业务可以随时扔掉重建；数据必须妥善保管，不能当普通容器随意对待。
- 把数据库塞进 Compose 跟业务一起跑：本地开发可以，生产环境危险。
- 正确思维：业务和数据分开，各用各的方案。
上一章 ← 09 - Compose 解决什么问题 ｜ 下一章 → 11 - 真实生产怎么做