微服务把单体拆成多个独立部署的服务，带来弹性扩展与独立迭代，也带来分布式带来的复杂性。本讲讲清微服务的适用边界、核心组件与落地陷阱，帮你判断"该不该上、怎么上"。
代码库巨大，改一行要全量回归，构建发布动辄几十分钟，迭代被拖垮。
某个模块出问题，整个应用不可用，故障影响面被无限放大。
几十人改一个仓库，冲突不断、发布排队，谁都不敢动核心代码。
按业务域拆分为独立服务，各自负责、独立演进。
Nacos/Eureka 等服务注册中心，服务间动态寻址。
API 网关统一入口，鉴权、路由、限流、聚合一处管理。
熔断、限流、降级与超时，保证故障不扩散。
消息队列连接服务，削峰填谷、最终一致性。
日志、指标、链路追踪三件套，分布式系统可排查。
没有绝对好坏，只有适不适合当前阶段。对照着看，别拍脑袋。
| 维度 | 模块化单体 | 微服务 |
|---|---|---|
| 开发启动 | 快，一套代码一个仓库 | 慢，基础设施先落地 |
| 发布部署 | 一次构建全量上线 | 按服务独立发布 |
| 故障隔离 | 一处故障影响全局 | 故障边界隔离 |
| 扩展能力 | 整体扩容浪费资源 | 按服务精准扩容 |
| 团队协作 | 大仓库冲突多 | 服务边界清晰 |
| 运维复杂度 | 低 | 监控/链路/日志全套 |
| 适合阶段 | 起步期 / 中小规模 | 团队大 / 业务复杂期 |
绝大多数项目单体足够，先把单体做好、模块化清晰，别为微服务而微服务。
按业务域逐步拆分高变动、高负载模块，保持每步可上线可回滚。
先落地注册中心、网关、配置中心、可观测性与 CI/CD，再拆服务。
从模块化单体 → 少量服务 → 按需扩展，用数据验证收益再继续。
业务域多、团队大、迭代频繁，微服务让各团队独立交付。
订单、库存、营销服务独立扩容，大促弹性伸缩不互相拖累。
不同团队负责不同服务，技术栈可选、发布解耦、职责清晰。
配合容器与编排，服务弹性调度、滚动更新，基础设施现代化。
