单体架构和微服务怎么选

单体和微服务是两种架构，不是微服务更好，按规模选。 这篇讲清区别和选择。

单体 vs 微服务

单体和微服务是两种系统架构风格，核心区别在于"功能的组织方式"。

单体架构

单体架构是把所有功能（用户管理、订单、支付、报表等）都放在一个应用里，打包成一个整体部署。

优势

• 简单：开发、测试、部署都简单，一个项目一个包，不用考虑服务间通信。
• 成本低：开发运维都省，不需要复杂的基础设施。
• 性能：内部调用是函数调用，比微服务的网络调用快得多。

劣势

• 规模大难维护：代码量一大就臃肿，新人上手难，改一处可能影响全局。
• 扩展难：只能整体扩展，不能只扩某个热点服务。
• 一处问题全影响：一个小 bug 可能导致整个应用崩溃。

微服务架构

微服务架构是把系统拆成多个独立的小服务（用户服务、订单服务、支付服务），每个服务独立部署、独立扩展，服务之间通过接口（HTTP、RPC）通信。

优势

• 灵活扩展：哪个服务流量大就扩哪个，不用整体扩展。
• 团队分工：不同团队负责不同服务，并行开发、互不干扰。
• 隔离：一个服务出问题不影响其他服务，故障隔离性好。

劣势

• 复杂：部署、运维、服务发现、链路追踪、配置管理都复杂得多。
• 成本高：开发和运维成本都显著高于单体，需要更多基础设施。
• 一致性难：跨服务的事务一致性（分布式事务）是公认的难题。

怎么选

选单体

适合这些情况：

• 中小项目：功能不多、用户量不大的项目，单体足够。
• 小团队：几个人到十几个人的团队，微服务的分工优势用不上。
• 快速验证：MVP 阶段需要快速上线验证，单体开发快。

选微服务

适合这些情况：

• 大型项目：功能多、系统复杂、单体已经维护不动。
• 大团队分工：几十人甚至上百人的开发团队，需要按服务分工。
• 高并发/要灵活扩展：某些服务流量远超其他，需要独立扩展。

演进

架构不是一成不变的，可以演进：

• 起步单体：项目初期用单体快速跑起来。
• 规模大了演进到微服务：当单体确实扛不住时，再逐步拆分微服务。
• 别一开始就微服务（过度设计）：很多项目从第一天就上微服务，结果开发慢、成本高、问题多，实际上单体完全够用。

别踩的坑

• 小项目用微服务：几个人的团队、几千用户的应用，硬上微服务，开发效率反而下降、运维成本翻倍，典型的过度设计。
• 为微服务而微服务：觉得微服务"先进"，不管实际需求就上，不解决任何实际问题，反而带来一堆复杂度。
• 忽视微服务复杂度：只看到微服务的灵活和扩展性，忽视了部署、运维、分布式事务的复杂度，上线后被运维问题拖垮。
• 单体扛大流量：该用微服务的场景坚持用单体，扛不住流量，频繁出故障。

成本参考

微服务的成本不只是开发成本，还包括部署基础设施（容器、编排、监控）、运维人力、服务间通信开销。同样一个功能，微服务的总成本可能是单体的 2-3 倍。

怎么选

1. 评估项目规模和团队：先看清项目的规模、用户量、团队人数。
2. 中小用单体：中小项目、小团队，单体简单高效。
3. 大型/大团队用微服务：大型项目、大团队、高并发，微服务灵活扩展。
4. 起步单体，需要时演进：不确定的话，起步用单体，规模到了再演进。

广州市汉诺雷斯（HNREIS）帮企业做架构选型，按规模务实选单体或微服务，不过度设计。把你的系统需求告诉我们，我们给出架构建议。