早期创业（单体胜出）
使用场景: 选择首个架构的创始人 / CTO
一个小团队、一个产品、快速迭代
单体：跨模块改动一个 PR 解决
一个数据库、简单事务
单次部署、单个 staging 环境
微服务开销会拖慢这个团队
这样组织的原因: 早期几乎总选单体——图表左侧就是你应交付的形态，因为快速迭代的单团队从进程内函数调用中获益远大于服务间的网络边界。
真实案例
扩展瓶颈（单体崩溃）
使用场景: 单体已成为瓶颈的团队
一个仓库里多个团队互相踩脚
部署队列：任何改动都得在他人后面排队
一条慢查询拖垮一切
无法独立扩缩——整个应用一起扩
技术栈锁定：一种语言、一个框架
这样组织的原因: 扩展瓶颈是你开始感到坚守单体代价的时刻——图表左侧变成负担，因为协作、部署和事故都共用一个瓶颈。
渐进抽取（绞杀者模式）
使用场景: 不重写迁移到微服务的团队
保持单体运行
每次抽取一个有界上下文为服务
API 网关把新流量路由到已抽取的服务
每次抽取伴随数据库拆分
随被替换而下线单体的路由
这样组织的原因: 绞杀者模式避免大爆炸式重写——图表数月内演化，左侧单体逐步收缩，右侧微服务每次扩大一个服务。
模块化单体（中间地带）
使用场景: 想要模块边界但不想付运维成本的团队
一次部署，但代码内严格的模块边界
模块间通过内部 API 契约通信
可选：一个数据库内每模块独立 schema
确实需要时再抽取更容易
无网络调用、无每服务运维开销
这样组织的原因: 模块化单体保留左侧的运维简单性、同时引入右侧的纪律——模块通过稳定接口对话但一起发布，把微服务的成本推迟到确实需要时。
使用技巧
- 两侧始终展示同一业务领域（用户/订单/商品）——领域不同就掩盖了真正的差异。
- 把数据库边界画明确——左侧共享、右侧独立——因为这是运维上最具影响的单一差异。
- API 网关只在微服务侧画；放进单体会混淆对比。
- 标注部署、数据库、进程的数量——这些数字正是图表在讲的运维故事。
在线开始编辑
回到模板页，直接替换成你的课程主题、章节和复习重点，就可以继续使用这套结构。
使用这个模板： /editor/new?template=microservices-vs-monolith
编辑此对比模板