拆分要按业务边界与团队边界，而不是按功能多少。稳定的核心、独立的生命周期、明确的依赖，才是值得拆的服务。
微服务的代价是分布式复杂度：网络、数据一致性、链路追踪、服务治理，每一项都要有方案，团队没能力就别硬拆。
理性判断：中小团队/单体应用不该为“先进”拆微服务。先问“问题真的是规模导致的吗”。
微服务的诱惑在于独立部署、独立扩展、技术异构；但它带来的分布式复杂度——网络、数据一致性、链路追踪、服务治理——每一项都要真金白银地投入。
理性看待：架构是工程选择，不是技术潮流。先想清楚“问题是不是真的由规模导致”，再决定要不要拆，比急着赶时髦重要得多。
微服务架构的关键能力。
按边界拆分服务。
RPC/消息异步通信。
服务注册与发现。
统一入口与路由。
限流、熔断、降级。
链路追踪与监控。
从判断到落地。
确认是规模/团队驱动，而非追技术热点。
按业务域与团队边界拆，明确接口契约。
注册发现、网关、配置中心、链路追踪。
限流熔断、灰度发布、监控告警逐步完善。
两种架构的取舍。
| 维度 | 单体 | 微服务 |
|---|---|---|
| 复杂度 | 低 | 高（分布式） |
| 部署 | 简单 | 独立但复杂 |
| 扩展 | 整体扩展 | 按服务扩展 |
| 适合 | 中小规模 | 大规模/多团队 |
团队足够大、服务边界清晰、单体已阻碍迭代时。规模未到，拆了只会增加成本。
分布式事务成本高。优先事件驱动 + 最终一致，用事务边界最小化强一致需求。
靠链路追踪 + 统一日志 + 监控告警，可观测性是微服务的必修配套。
不建议。团队小、服务不多时单体 + 模块化足够，等规模到了再演进。
团队规模大到影响协作、单一发布节奏拖累迭代、明确的服务边界出现时。规模没到，拆了只会增加成本。
微服务是 SOA 的演进：更强调小、独立、去中心化治理。理解了 SOA 的“服务化”思想，能帮你少走弯路。
“我们在单体里靠模块化撑到了几十人团队，才在边界清晰后逐步拆微服务，踩坑少很多。”
— 某中型团队 · 技术负责人“链路追踪和统一日志配齐后，跨服务排查问题终于不再是“大海捞针”。”
— 某电商平台 · 后端工程师“先想清楚再拆，比先拆了再补课，成本低一个数量级。”
— 某 SaaS 公司 · 架构师