先一句话总览： 单体：所有模块打包成一个应用，共享进程、数据库；微服务：拆成多个独立小服务，独立部署、独立数据库，通过网络通信。
一、对比表
二、单体架构优点 & 缺点
✅ 优点
开发简单，本地调试方便，不用处理分布式问题
没有网络调用开销，性能更好
部署、运维简单，组件少
事务简单，数据一致性容易保证
❌ 缺点
代码耦合，模块边界模糊，越写越 “大泥球”
扩容浪费资源，只能整体水平扩展
发布风险高，任何改动都要全量发布，回归量大
技术栈统一，很难局部换技术
大团队协作冲突多
三、微服务架构优点 & 缺点
✅ 优点
高内聚低耦合，按业务域拆分，职责清晰
独立部署、独立扩缩容，资源利用率高
故障隔离，影响面小
技术异构：不同服务可以选用最合适的技术栈
支持小团队自治、快速迭代、灰度发布
❌ 缺点
分布式复杂度爆炸：网络不稳定、超时、重试、幂等
分布式事务难，很难做到强一致，大多只能最终一致
运维门槛陡增：注册中心、配置中心、网关、熔断限流、链路追踪、日志聚合
测试复杂：需要启动整套服务环境，联调成本高
服务依赖链路复杂，一个调用链跨好几个服务，排障麻烦
四、常见误区
❌ 微服务 = 更好、更先进
微服务是解决复杂度的方案，不是银弹。业务不大强行拆微服务，只会徒增大量分布式成本。很多项目优先单体，等单体成为瓶颈之后，再逐步拆。
❌ 微服务必须每个服务一个数据库
这是最佳实践，但不是硬性规定；内部可以适度共享库，但是要控制耦合。
❌ 单体就是落后
很多成熟产品（小 B 系统、内部管理平台）单体跑很多年，稳定、成本低，性价比极高。
五、选型建议
✅ 选单体：业务简单、团队 ≤5 人、流量平稳、快速上线、内部后台系统
✅ 选微服务：业务庞大、多团队并行、不同模块流量差异巨大、需要独立迭代发布、高可用要求高
六、补充：过渡方案（很多公司在用）
模块化单体 → 垂直拆分 → 微服务 先在单体内部做好包 / 模块边界，接口规范，不直接一步拆微服务；等模块边界稳定、流量出现瓶颈后，再逐步抽离成独立服务（绞杀者模式）。
本文原创作者：易君召，详见：https://www.yijunzhao.cn/authors/yijunzhao，转载请注明出处。
原文链接
欢迎访问 小易撩挨踢