单体架构和微服务有什么区别？什么时候应该拆分服务？

知识点详解：什么时候拆，拆完怎样才算有收益

单体不等于一团代码，微服务不等于清晰边界

假设系统有账号、内容与通知模块。即使同一个进程部署，也能分别维护接口和数据访问规则，不让任意模块直接修改别人的状态。

若微服务全部共享数据库，随意读写对方表，并要求一起改一起发布，部署数量增加了，耦合未必减少。

边界先反映职责和变化原因，再映射到部署单元。不能按 Controller、Service、DAO 三层拆成三个远程服务。

独立扩缩与发布，需要真实独立性

假设通知发送负载波动明显，且允许异步处理，拆出通知能力可能方便独立扩容和发布。

但如果一次用户操作串行跨越很多服务，每一步都依赖下游，整体延迟和可用性会受到调用链影响。需要超时、重试、隔离与降级，而不是把本地方法机械变成 HTTP。

服务数据所有权也要清楚。跨服务需求通过契约协作，必要时采用事件或读模型，并接受明确的一致性边界。

模块化单体适合先把不确定性关在内部

当领域边界还在调整，进程内改模块接口和重构通常比跨部署迁移容易。统一测试和本地事务也相对直接。

这不意味着永远不拆。可以先建立模块边界、观测负载和依赖，找到需要独立演进的部分，再渐进拆分。

也别把团队小当作绝对禁止微服务的理由。已有平台、明确隔离需求和成熟团队可能改变成本；重点是把条件说出来。

拆分验收，看能不能独立变更和恢复

检查修改一个模块是否要求全体协调发布，某服务故障是否拖垮所有请求，以及排查一次跨服务失败能否找到链路。

容量要测真实瓶颈：数据库、存储、外部接口和串行调用不一定随着服务数量改善。上线流程还要覆盖契约兼容、回滚和数据迁移。

面试里给一个“为什么这里拆、那里暂时不拆”的判断，比单纯站单体或微服务更有说服力。

本题机制参考：Fowler Monolith First、Azure 领域分析。

面试官继续追问

单体可以水平扩容吗？

可以部署多个实例，只要状态、会话和共享资源等设计支持。

微服务必须每个服务一种数据库吗？

不必每种能力选不同技术，但数据所有权和访问边界应明确；同一物理集群也不等于任意共享表。

服务越小越好吗？

不一定。拆得太细可能增加聊天式调用和协调成本，粒度按内聚与演进需求判断。

面试速记卡

• 形式：单体一个部署单元，不等于无模块。
• 收益：独立演进、扩缩与隔离，需要明确边界。
• 成本：网络失败、契约、数据一致性和运维。
• 起点：条件允许时模块化单体，再渐进拆分。
• 验收：独立发布、故障范围、真实瓶颈和诊断能力。