微服务还是单体：中小企业技术架构选型思考

软件架构大师 Martin Fowler 在其经典文章 MonolithFirst 中一针见血地指出："几乎所有成功的微服务案例都始于一个变得过于庞大而被拆分的单体应用。"而那些从零开始就采用微服务的项目，往往陷入了分布式系统的复杂性泥潭。这一观察在 2026 年仍然极具指导意义。

微服务的真实成本——MicroservicePremium

Fowler 提出了一个关键概念——微服务溢价（MicroservicePremium）：微服务带来的运维开销——服务发现、负载均衡、分布式事务、链路追踪、日志聚合——这些基础设施的搭建和维护需要专门的 DevOps 能力。对于 5-15 人的小团队而言，这些额外的工作量可能超过微服务带来的模块化收益。

我们的建议：如果团队在 15 人以下，业务领域相对集中，用户量在百万级别以内，一个设计良好的模块化单体（Modular Monolith）完全够用。代码层面实现模块解耦，保留未来拆分为微服务的架构弹性。

模块化单体：被低估的务实之选

模块化单体是在同一个部署单元中，按业务领域（Bounded Context）划分为清晰的模块。每个模块有自己的数据访问层、业务逻辑和 API 接口，模块间通过明确的接口而非直接方法调用通信。这种架构保留了微服务"高内聚低耦合"的核心优势，同时避免了分布式系统的运维地狱。

当业务发展到需要独立扩缩容某个模块时，可以自然地演进为微服务——这是一个基于证据的决策，而非基于假设的架构过度设计。

真的有"微服务场景"吗？

微服务真正不可替代的场景包括：团队规模较大（20+ 开发者）需要独立开发部署；不同模块技术栈差异大（核心系统 Java，AI 服务 Python）；部分模块需要独立扩缩容（电商的搜索服务和订单服务的流量模型完全不同）；需要独立的合规边界和数据治理（如金融核心交易 vs 营销活动）。

Fowler 的忠告："在你的团队拥有足够的微服务系统构建经验之前，不要从微服务开始。"对于绝大多数中小企业而言，过早引入微服务不是技术升级，而是技术负债。