从单体应用到微服务
单体和微服务不是非黑即白，而是一条演进路径。
flowchart LR
A[单体应用] --> B[模块化单体]
B --> C[拆出基础能力]
C --> D[按领域拆服务]
D --> E[微服务治理]
单体是什么
单体应用的特点很直接：
- 一个主工程
- 一起开发、一起部署
- 大部分业务共用同一套运行环境
单体的优点
- 起步快
- 调试简单
- 部署成本低
- 本地事务和数据一致性更容易处理
所以对小团队、早期项目来说，单体通常是最省成本的选择。
单体为什么后面会痛
规模一大，常见问题就出现了：
- 模块耦合越来越重
- 一个小改动也要整站发布
- 热点模块没法单独扩容
- 多团队协作容易互相阻塞
问题不一定是“单体有罪”，很多时候是因为边界没管好，最后变成失控的单体。
微服务是什么
微服务的核心不是“服务越小越好”，而是：
按业务能力拆分，让服务可以独立开发、独立部署、独立扩容。
常见表现是：
- 外部请求先到网关
- 用户、订单、支付、库存等服务分别独立
- 服务之间通过 API 或消息协作
微服务带来的收益
- 哪个服务压力大就扩哪个
- 一个服务发布不必拖着整个系统
- 团队可以按领域分工
- 故障更容易隔离
微服务的代价
- 调用从函数变成网络调用
- 数据一致性更难
- 监控、日志、链路追踪必须跟上
- 发布治理和接口兼容更复杂
所以微服务不是“拆代码”，而是“拆代码 + 补工程体系”。
什么时候适合拆
- 业务边界已经稳定
- 不同模块负载差异明显
- 发布冲突已经是瓶颈
- 团队和基础设施足够成熟
什么时候先别拆
- 团队还很小
- 业务还在快速变化
- 现在最大的痛点是代码质量，不是架构形态
总结
更稳的做法通常不是“直接上微服务”，而是：
先把单体做成模块化单体，再把真正值得独立的部分拆出去。