这不是微服务或单体；而是认知负荷

Meta：HN 排名与怀疑

• 一些评论质疑这篇帖子如何在很少积分/评论的情况下迅速冲上首页。
• 排名算法被描述为偏向积分上升的 свеж帖；也有人猜测存在机器人或人工提权/降权，但这仍未得到证实，而且颇具争议。

将认知负荷作为设计视角

• 许多人喜欢把“认知负荷”作为一种以人为本的架构思考方式。
• 对可测量性存在分歧：有人说它不能/不应该被量化；也有人指出其他领域中有人因工程研究。
• 对“以最大认知负荷进行设计”的误解：有些人把它理解为把团队推到极限；另一些人则理解为“不要超过团队实际能承受的范围”。
• 来自炼油厂和医疗软件的例子表明，未文档化、多个服务组成的“数据炼油厂”可能超出人的理解能力，并带来真实风险。

微服务 vs 单体：权衡

• 强烈观点：架构应遵循良好设计（自治、清晰边界），而不是诸如“每个团队 N 个服务”或“永远单体”之类的任意目标。
• 有几位认为微服务主要是一种组织/部署策略；从技术上说，单进程或模块化单体通常更简单、更快、更可靠。
• 当以下条件满足时，微服务可以很好地工作：边界设计良好、服务可独立测试、CI/CD 和可观测性强，并且团队规模较大。
• 许多人报告了失败模式：服务过多、接口难以更改、跨团队协调瓶颈、漫长的调试链路，以及“分布式单体”。

团队结构、Conway 定律与 Team Topologies

• 争论微服务是为了“遵守”还是“拥抱” Conway 定律，还是把它当作一种警告。
• 有人认为每个服务对应一个团队以及类似“Team Topologies”的自治方式很有帮助；另一些人则说这会鼓励割据、碎片化，并让跨团队的认知负荷飙升。
• 多条评论强调，激励机制、领导力和软技能比所选模式更重要。

组件化、模块化与中间路线

• 许多人强调，模块化单体可以通过库、包和严格接口实现清晰边界。
• “单体 vs 微服务”被视为一种错误的二分法；实际上存在一个谱系：单进程模块化应用、“mesolithic/gabion” 设计、具有严格所有权的共享数据库，以及选择性拆分出的服务。
• 一条很长的子线程讨论了极端拆分（数百个小组件/仓库）与单一单体之间的对比，支持者认为它能带来小批量生产力，批评者则指出维护成本和“过度工程”的观感。

产品优先还是架构优先

• 一些创始人认为，早期初创公司应优先关注产品发现和速度；扩展/重写是少数人才能遇到的“好问题”。
• 另一些人则反驳说，长期存在的系统需要持续重构、简化，并尊重本质复杂性与偶然复杂性之间的区别。

降低认知负荷的实用方法

• 建议的做法包括：强封装、定义清晰的 API、限定上下文、良好文档、更少的语言/技术栈，以及提取自包含的库。
• 反复出现的主题是：你无法避免复杂性，但你可以选择它“存在于何处”，以及每个人必须在脑中承载多少复杂性。