轶事2014年3月，MartinFowler和JamesLewis首次提出微服务架构，武林秘籍。然而，不到一年的时间，有些人没看懂，有些人就失去了理智。马丁只好再次出面，告诫大家要孤军奋战，切忌急功近利。不到七天，就有人在马丁的门户里公然唱反调，指责先独处是不可接受的。后来，曾经评论过微服务秘籍的SamNewman不置可否地表示，只有在合适的时候，他才会去实践。一时间众说纷纭，天下大乱。有诗为证：分析所有企业框架的模式，重构代码精益求精。纵横软件40年，世人称他为老马丁。建立微服务后，我建议您从单个实体开始。莫问风雪几时，心若晴天。和平爱好者对初生的三体世界给人类的忠告是：不回答，不回答，不回答。而人类在软件行业面临的很多未解决的问题是：无法回答的，无法回答的，无法回答的。时间永远不会因为人类愚蠢的争执而停止她的脚步，坐标一转眼就来到了2019年。来自英国和比利时的两个才华横溢的年轻人因机缘巧合走到了一起。基于前人特立独行的想法，结合认知心理学，他们提出了一个相当大胆的假设：单体重要还是微服务重要并不重要，重要的是团队的认知负荷。乍看之下，这个理论似乎并没有多少新意，但仔细一看，却又像是启蒙。马丁·福勒和山姆·纽曼难以言喻的暧昧就这样被轻轻驱散。就像是四维空间的神明，低头嘲笑着三维空间的渺小人类。这是一次彻底的降维打击。不仅微服务架构如此，你甚至可以发散：为什么敏捷开发要取代瀑布开发？DevOps是怎么突然兴起的？云计算为何如此火爆？为什么我们今天构建的软件应该是云原生的？你会发现，团队认知负荷理论，或者说整个团队的拓扑结构，不仅仅是一种方法论，而是一种全新的世界观。什么是认知负荷？认知负荷理论最早由认知心理学家约翰·斯威勒于1988年提出，是指从事一项工作所需脑力劳动的总和。Sweller在研究ProblemSolving时发现，不同的教学方式会对学习者产生不同的影响，而造成不同影响的根本原因是认知负荷。对于要存储在长期记忆中的信息，必须首先由工作记忆注意和处理。然而，工作记忆的容量和持续时间是非常有限的。在某些情况下，这些限制会阻碍学习过程并影响学习效果。沉重的认知负荷会对学习产生负面影响。Sweller将认知负荷分为以下三类：内在认知负荷是指与特定主题相关的脑力劳动。额外的认知负荷是指学习者呈现信息或任务的方式。相关（相关）认知负荷是指创建永久知识库的努力。团队认知负荷与软件开发MatthewSkelton和ManuelPais（刚才提到的两个“年轻人”）在他们的团队拓扑中提倡团队优先的思维方式，目的是降低团队的认知负荷，避免工作内容（架构、运维等）超出团队的最大认知负荷。这样，整个团队就可以以一种非常舒服的状态来有效地应对软件的复杂性，而不是疲于奔命。这种“以人为本”的思维方式，远优于单一或微服务只关注技术本身的视角。Matthew和Manuel不仅将认知负荷的概念引入软件开发领域，还给出了他们对不同分类的解释。内在认知负荷指的是开发所需的知识，如Java知识、前端知识等，也就是技术。Extrinsiccognitiveload是指怎么部署，怎么调试，怎么配置，也就是机制。相关认知负荷是指软件要解决的问题，即与业务和领域相关的知识。其中，内部认知负荷是固定的，是我们开发软件所必需的知识；尽量减少外界的认知负荷，尽量避免与发展本身无关的脑力劳动；相关的认知负荷是尽可能最大化，因为这是我们在开发软件时必须了解的业务知识。为什么要最小化外在认知负荷？例如，对于在线错误，修复它的固有认知负荷可能非常低，只需要修改一行代码。但是在我们修复它之前，我们搭建环境、准备数据、调试、测试……可能一两天就这样过去了。这是外部认知负荷过高（环境不好，数据没准备好，调试不好，测试不好等）导致的问题。又比如每个开发者都曾遭受过业务方或者需求方的灵魂拷问：为什么这个需求这么简单，开发起来却需要那么多天？其实需求看似简单，但是要改改改改改改，零零碎碎的加起来需要好几天。你可能也会受委屈，但是你有没有想过哪里出了问题？为什么简单的需求不能快速上线？您可能会想到霰弹枪改装，但这些只是表象。根本原因是架构和代码结构不合理，增加了团队的外部认知负荷。唯一的答案回到最初的问题，你有答案吗？为什么人们不愿意接触数百页的需求文档，而宁愿阅读只有一两页的故事卡片？因为外部认知负荷：用厚而全面的文档向人们呈现需求的方式大大增加了外部认知负荷。为什么人们不喜欢管理冗长的维护列表而更喜欢基础架构即代码？因为外部认知负荷：以代码的形式管理基础设施显然比人工运维具有更低的外部认知负荷。为什么人们不愿意自己控制软件的弹性和弹性，而更愿意将软件部署到云端？因为外部认知负荷：把专业的工作交给专业的团队，开发人员只关注业务代码，把与自己无关的外部认知负荷抛在脑后。从这个角度来看，单体微服务之争是不是显得太低级了？答案是显而易见的。你只需要评估什么样的架构可以减少当前团队的认知负荷（准确地说是外在认知负荷）。过去软件行业所有悬而未决的问题和似是而非的断言，似乎都有了答案，唯一的答案。这么难的问题是谁想出来的？到处都有正确的答案。
