微服务还是单体，你的团队适合哪一种

技术圈有个有趣的现象：五年前大家都在讨论"怎么拆微服务"，这两年又开始讨论"怎么把微服务合回去"。不是因为微服务不好，而是因为很多团队在错误的时机选了它。

技术选型不是追潮流，而是匹配。微服务和单体没有优劣之分，只有合适不合适。

单体架构的真实样子

单体架构不是"落后"的代名词。它的意思是：整个应用是一个部署单元，代码在一个仓库里，发布时一起打包、一起上线。

单体的好处很实在：

• 开发简单，本地一个进程就能跑起来，调试方便
• 部署简单，一个包扔上去就行，不需要编排工具
• 测试简单，功能之间的调用都在进程内，不需要处理网络超时、重试
• 性能简单，模块之间调用是函数调用，不是 HTTP 请求

单体的代价也很真实：

• 代码量大了以后，改一处要理解全局，新人上手慢
• 发布频率被拖慢，哪怕只改了一行代码，也要把整个应用重新部署
• 技术栈被锁死，想用个新框架都得等整体重构
• 某个模块的性能瓶颈会拖累整个应用，没法单独扩容

微服务架构的真实样子

微服务的意思是：把应用拆成一组小服务，每个服务独立部署、独立数据库，服务之间通过 HTTP 或消息队列通信。

微服务的好处很诱人：

• 每个服务可以独立发布，一个服务改了不用重启其他服务
• 每个服务可以用不同的技术栈，适合它的场景选它的语言
• 每个服务可以独立扩容，哪个模块压力大就给哪个加机器
• 团队可以按服务划分，每个小组负责几个服务，自主决策

微服务的代价很沉重：

• 分布式系统的复杂性：网络会断、消息会丢、数据会不一致
• 运维成本飙升：几十个服务要监控、要日志、要链路追踪
• 测试变难：一个业务流程跨多个服务，集成测试环境搭建复杂
• 部署门槛高：需要容器化、编排工具、持续交付流水线
• 数据一致性难保证：跨服务的事务要分布式事务，或者最终一致性

什么时候该选单体

团队小于 10 人。微服务需要团队按服务边界划分，每个服务至少要有一个人负责。10 个人的团队拆成 5 个小组，每组 2 人，每人要懂业务、写代码、做运维、处理线上问题——人手不够。

业务还在探索期。产品方向没定，功能频繁调整，这时候最重要的是快速试错。单体架构改起来快，部署起来简单，能让你一天发三个版本验证想法。

技术团队没有专职运维。微服务架构下，服务之间的调用链很长，出了问题要能快速定位是哪个环节。这需要监控、日志、链路追踪的基础设施。如果没有专人维护这些，出了问题排查要半天。

业务量还不大。日活一万以内，单体架构完全扛得住。过早优化是万恶之源，等流量真的到了瓶颈再拆也不迟。

什么时候该选微服务

团队超过 20 人，且按业务线分组。20 人的团队一起改一个代码仓库，代码冲突会频繁到影响效率。按业务线拆成独立服务，每个小组自主决策、独立发布，协作效率会显著提升。

业务已经稳定，功能边界清晰。你知道订单是一个独立的领域，支付是另一个领域，它们之间的接口是什么。这时候拆微服务，边界是自然的，不是硬切的。

不同模块的性能需求差异大。比如搜索模块需要大量 CPU，而用户模块主要是 IO 密集。单体架构下只能整体扩容，微服务可以单独给搜索模块加机器。

发布频率被拖累。一个应用有 50 个功能，每个功能每周都要改一次。单体架构下每天要部署好几次，每次都要全量回归。微服务架构下每个服务独立发布，互不影响。

拆微服务的三个前提

如果你决定拆，先检查这三个前提是否满足：

有容器化和持续交付的基础设施。微服务拆出来后，可能有 20 个服务要部署。手工部署不现实，必须有自动化的 CI/CD 流水线，必须有容器编排工具（如 Kubernetes）。

有可观测性的基础设施。服务之间的调用链变长了，出了问题要能快速定位。必须有集中式日志、指标监控、链路追踪。否则一个服务挂了，你要花两小时排查是哪个环节出了问题。

团队有能力处理分布式系统的问题。网络超时怎么处理？消息丢失怎么重试？数据不一致怎么对账？这些问题在单体架构下不存在，在微服务架构下是日常。

拆错了怎么办

如果你已经拆了微服务，但发现维护成本太高、团队吃不消，合回去也不丢人。有些公司的做法是：把几个关系紧密的服务合并成一个，减少服务数量，但保留独立部署的能力。这不是"回到单体"，而是"找到合适的粒度"。

架构不是一次性决策，而是持续演进。关键是能感知到当前的问题，有勇气调整方向。

读完能做什么决定

• 微服务和单体没有优劣，只有匹配不匹配
• 团队小于 10 人、业务在探索期、没有专职运维、业务量不大——选单体
• 团队超过 20 人、业务稳定边界清晰、性能需求差异大、发布频率被拖累——选微服务
• 拆微服务前要有三个前提：容器化 CI/CD、可观测性、分布式系统经验
• 架构不是一次性决策，拆错了可以合回去，关键是能感知问题并调整