微服务架构：什么时候该用

微服务很火，但不是银弹。

单体 vs 微服务

单体架构

优点：

• 开发简单
• 部署方便
• 调试容易
• 事务一致

缺点：

• 耦合度高
• 扩展困难
• 技术栈单一

微服务架构

优点：

• 独立部署
• 技术多样
• 弹性扩展
• 故障隔离

缺点：

• 复杂度高
• 运维成本
• 数据一致性
• 网络延迟

什么时候上微服务

✅ 适合的场景

• 团队规模 > 20 人
• 业务复杂度高
• 需要快速迭代
• 不同模块负载差异大

❌ 不适合的场景

• 初创公司（<10 人）
• 业务模式未验证
• 简单应用
• 缺乏 DevOps 能力

拆分原则

1. 按业务域：用户服务、订单服务、支付服务
2. 高内聚低耦合：服务间依赖最小化
3. 数据库独立：每个服务自己的数据库
4. 渐进式：从单体开始，逐步拆分

核心挑战

• 服务发现：Consul/Etcd
• API 网关：Kong/APISIX
• 链路追踪：Jaeger/Zipkin
• 配置中心：Nacos/Apollo

我的建议

先单体，后微服务。

90% 的项目用不到微服务。先把单体做好，等遇到瓶颈再拆分。

架构是演进的，不是设计的。