微服务与单体之外：架构决策的认知约束

在过去的十年里，“微服务”几乎成了先进架构的代名词，而“单体架构”则被视为技术债务的象征。然而，这种二元对立的叙事掩盖了真正重要的问题：架构选择本质上是一种组织设计，而非单纯的技术选型。很多团队在没有搞清自身系统复杂度和团队规模的情况下，盲目地拆解服务，最终陷入分布式地狱。与此同时，一些老练的团队开始回归“模块化单体”，却发现它其实承载了微服务的许多优点。本文将从认知约束和信息流的角度，重新审视这场争论，提出一个独立观点：微服务与单体并非对立，而是系统演化过程中的两个端点，中间存在一条被大多数人忽视的连续光谱。

传统上，微服务的优点被概括为独立部署、弹性伸缩和故障隔离，但这些优势往往被低估的成本所抵消。每一次跨服务调用都跨越了进程边界，引入了网络延迟、分布式事务、服务发现、容错重试等一系列复杂问题。更重要的是，这些技术问题会转化为团队成员的认知负载：一个由十人组成的开发团队，需要同时维护三十个微服务，每个服务都有独立的代码库、数据库和流水线，那么即使每次变更都很小，理解全局知识的成本也会成倍增长。这种由架构产生的“认知债”比代码债更隐蔽，也更持久。相反，单体架构虽然简单，但它最大的问题是缺少边界，容易演变成大泥球。然而，如果我们能用模块化思维构建单体，在代码层面上明确模块职责和接口契约，就能同时获得单体的简单性和微服务的可演化性。

这里我要提出一个可能具有争议的观点：微服务其实是模块化单体的物理投影，而非一种更高级的形态。当模块化单体的模块数量和团队规模达到某个阈值后，我们才需要将某些模块独立成服务，以突破部署或扩展的瓶颈。而“微服务”正是把这个过程提前，甚至过度提前的产物。很多团队在没有足够领域建模能力的时候强行拆分服务，往往会因为无法协调数据一致性而付出巨大的代价。更合理的做法是“先单体后微服务”：先从模块化单体开始，随着对业务的理解加深，再将易变且高负载的模块逐步剥离为独立服务。这种演进式架构尊重了组织认知发展的规律，让技术债务成为有意识的投资，而不是盲目的赌博。

最终，架构师应该放弃“非此即彼”的二元思维，转向一种基于约束的决策框架。约束条件包括：团队规模、业务稳定度、交付频率、领域复杂度、运维能力等。当我们把注意力从技术词汇上移开，转向团队认知负载和系统信息流时，很多流行方案的吸引力就会消失。记住，最好的架构不是最先进的技术，而是能让你的团队在长期内保持高交付速度、低变更风险的组织结构。微服务和单体只是工具箱里的两个选项，而不是宗教信仰。在这个意义上，认识“模块化单体”的价值，不是倒退，而是对架构演进本质的回归。当我们承认复杂性不可消除，只能在合适的地方承担时，架构决策才真正走向成熟。