单体还是微服务：该选哪种架构？

很少有技术辩论像单体对微服务这样引发如此多的困惑（和如此多的糟糕决策）。多年来，微服务被吹捧为每家企业都应采用的现代架构，许多企业在并不需要的情况下贸然拆分了自己的系统，从而继承了巨大的复杂性。现实更为微妙：每种方案都有其适用之处，而选错可能会拖慢开发或让成本飙升。关键在于理解每种方案各自解决什么问题。

在本文中，我们比较这两种架构、各自的优势与弊端，并说明何时适合哪一种。

什么是单体架构

在单体架构中，整个应用作为单一单元进行构建和部署：一个包含系统全部逻辑的统一代码库。这是传统的做法，而且往往是起步时最明智的做法。它的优势是简单（在初期更容易开发、测试和部署）、运维成本更低，以及便于对整个系统进行推理。它的局限在系统大幅增长时显现：庞大的代码库可能变得难以维护，也难以按部分扩展。

什么是微服务

在微服务架构中，应用被拆分为许多小而独立的服务，每个服务各司其职，可单独部署。它的优势是选择性扩展（只扩展需要扩展的那部分）、团队的独立性（每个团队负责自己的服务）以及韧性（一个服务出故障不会拖垮全部）。代价是它们引入了相当大的复杂性：服务间通信、协调部署、分布式监控，以及要求高得多的运维。

关键差异

以下这些因素最能体现两种方案之间的差异：

• 复杂性：单体简单；微服务运维复杂。
• 扩展：单体作为整体扩展；微服务按部分扩展。
• 初期速度：单体在初期能让你推进得更快。
• 团队：微服务更适合许多大型团队。
• 部署：一个对多个协调部署。
• 运维成本：单体较低，微服务较高。

何时选择哪一种

对大多数项目来说，尤其是起步阶段，单体是更好的选择：它能让你快速推进，运维成本更低，而且在产品还在定义阶段时更容易修改。微服务在系统真正壮大时才有意义：许多互相牵绊的团队、扩展需求差异极大的部分，或需要不同技术的组件。过早采用它们会增加一种拖慢而非帮助的复杂性。

微服务的隐藏成本

需要意识到，微服务把复杂性从代码转移到了运维，而这种成本几乎总是被低估。在单体中只是简单的函数间调用，在微服务中却是一次可能失败、有延迟、需要重试的网络通信。除此之外，还要编排部署、监控几十个服务、管理分散的数据，以及维护复杂得多的基础设施。对于没有成熟运维团队和工具的组织，这种复杂性消耗的时间可能比它节省的还多，以至于许多在并不需要时迁移到微服务的企业最终又回到了更简单的设计。这并非微服务的缺陷，而是一个信号：只有当问题真正需要它们时，它们才能发挥作用。

模块化单体：两者兼得

有一个非常值得推荐的折中点：模块化单体，即单一应用但被良好组织成边界清晰的模块。它既提供单体的运维简单性，又让系统做好准备，在某天真正需要时抽取出具体的服务。从模块化单体起步，只把真正有理由的部分迁移到微服务，几乎总是最明智的路径，也是当今许多专家推荐的做法。

在 AxiomTech，我们为每种情况设计合适的架构，不追风潮：从简单起步，只在微服务带来真正价值时才向其演进。如果你不知道你的项目需要什么架构，找我们聊聊，我们会不带偏见地为你出谋划策。