一句话定义：单体架构（Monolithic Architecture）是把整个应用打包成一个部署单元、一起上线；微服务（Microservices）是把它拆成若干能各自独立部署的小服务，服务之间通过网络接口调用。
打个比方：单体像一间大开间办公室，所有人坐在一起，喊一嗓子就沟通完了；但谁接个电话全屋都听得见，搬一张桌子要全屋停工。微服务像分成几个楼层，每层有自己的门禁和作息，互不干扰；代价是跨楼层沟通得发邮件，邮件可能延迟、可能丢失，还得有人专门管收发室。所以拆分的收益是“互不拖累”，成本是“沟通变贵、变慢、变不可靠”。
拆的到底是什么：不是代码文件，而是部署单元。判断标准很朴素：改一个小功能，要不要把整个系统重新发一遍？如果答案是“要”，那它就是单体，哪怕代码分了二十个模块。
| 维度 | 单体 | 微服务 |
|---|---|---|
| 发布 | 一次全量发布，改动互相牵连 | 各自发布，节奏独立 |
| 故障 | 一处崩溃可能全站不可用 | 局部故障，但要防连锁雪崩 |
| 数据 | 通常一个库，事务简单 | 各管各的数据，一致性变难 |
| 团队 | 共享代码库，协作成本随人数上升 | 边界清晰，可各自负责 |
| 排查问题 | 一个日志文件里翻 | 需要链路追踪等配套工具 |
和相邻概念的区别：模块化（Modularity）只是代码层面的分层和解耦，仍然是同一个部署包；微服务是把部署也拆开。SOA（面向服务架构）是更早的同类思路，通常依赖较重的企业总线；微服务更像它的轻量版实践。另外，微服务不等于“服务越小越好”，粒度应按团队和变更频率来划，而不是按代码行数。
对从业者的意义：微服务不是先进性的标志，而是一种组织手段。它解决的是“人多了以后，发布排队、故障连坐、改动互相踩脚”的问题。如果团队只有几个人、发布一天没几次，拆开只会凭空增加网络调用、分布式事务、监控告警的负担。反过来，当多个团队被迫在同一个发布窗口里排队、每次上线都要全员待命时，拆分的收益就开始超过成本。迁移也没有“一键切换”，常见做法是先模块化收边界，再把变更最频繁、最容易拖累别人的部分先拆出去。具体选型与工具能力，以各家官方文档为准。