这不是微服务或单体的问题，而是认知负荷的问题 [译]

📝

内容提要

文章指出，架构选择的关键不在微服务或单体本身，而在团队认知负荷。单一团队宜采用模块化单体，避免过度拆分微服务而增加沟通负担；多团队则适合微服务，通过良好API实现领域抽象与独立协作。应减少额外认知负荷，按团队能力设计架构。

🔎

延伸解读

认知负荷：架构选择的新视角

文章将架构决策的焦点从技术风格转向团队认知负荷，指出微服务与单体之争并非关键，真正重要的是团队能承受多少认知负荷。这一视角提醒我们，架构应适配团队能力，而非盲目追随技术潮流。通过区分固有、额外和相关认知负荷，文章为评估团队负荷提供了具体框架，帮助读者理解为何同样的架构在不同团队中效果迥异。

单团队与多团队的架构分水岭

文章明确区分了单团队与多团队的适用架构：单团队宜采用模块化单体，避免微服务带来的额外沟通与API维护负担；多团队则适合微服务，通过良好设计的API实现领域抽象和独立协作。这一分水岭基于沟通边界的差异——团队内部靠代码、文档和讨论沟通，团队之间则靠API等自助工具。读者可据此判断自身团队规模对应的合理架构方向。

减少额外认知负荷的实践要点

额外认知负荷不直接贡献成果，却消耗团队精力，如繁琐基础设施、公司流程、技术债务和跨团队等待。文章建议通过简化流程、避免琐碎工作、用API提供领域抽象来减少或消除这类负荷。若无法消除，则应在分配任务时予以考虑。对于单团队，尤其要警惕将工作拆分为多个微服务所带来的API设计和文档负担，模块化单体往往是更务实的选择。

❓

Q&A

为什么说架构选择的关键不是微服务或单体，而是认知负荷？

因为架构风格本身不是目的，团队能承受的认知负荷才是决定因素。选择架构前应先评估团队认知负荷能力，再设计匹配的软件架构，避免过度野心导致交付质量下降。

认知负荷分为哪几种类型？各自含义是什么？

分为三种：固有认知负荷（团队对领域的专业知识程度）、额外的认知负荷（不直接贡献成果却必须做的工作，如琐碎任务、公司流程）、相关认知负荷（解决领域相关问题的心智负担，能促进流状态和幸福感）。

单个团队为什么更适合模块化单体而不是微服务？

单个团队若拆分多个微服务，会引入复杂的通信边界和API维护负担，导致工作分散、额外认知负荷增加。模块化单体在单一代码库中保持一致性，减少抽象和沟通成本，更适合团队内部协作。

多团队组织采用微服务架构有什么好处？

多团队采用微服务可通过良好设计的API实现领域抽象，减少团队间频繁沟通，让各团队独立工作。API作为自助工具，降低其他团队了解领域细节的认知负荷，提升组织效率。

如何减少或消除额外的认知负荷？

可通过简化流程、避免琐碎无关工作、通过API为其他团队提供领域抽象、设计不产生冗余沟通渠道的架构等方式实现。需要工程团队和领导层共同努力，若无法减少则应在分配任务时考虑该因素。

团队认知负荷过高会带来什么风险？

过多的认知负荷会限制团队的工作量和潜在质量，导致项目延误、交付压力增大，甚至使团队成员感到疲惫，无法提供高质量成果。

🏷️

标签

单体 团队架构 微服务 模块化单体 认知负荷