“单体与微服务”的争论通常集中在技术方面，而忽略了战略和团队动力。但是，思维敏捷的组织不是从技术入手，而是以团队的认知负担作为有效交付和运行现代软件系统的指导原则。 过多的认知负担不利于有效的团队所有权和软件的可支持性。(banq注：人的能力有限，过多支持太多太广的系统就会力不从心)
微服务粒度很难确定？当您根据拥有单个服务的团队他们可以处理的认知负担来重新考虑问题时，围绕服务大小如何确定等大多数混淆都将消失。
如何定义认知负荷
心理学家约翰·斯威勒（John Sweller）将认知负荷定义为“ 在工作记忆中使用的精神努力总量 ”，然后继续描述三种不同的认知负荷：
- 内在的认知负荷，与问题空间基本任务的各个方面有关。示例：如何用Java定义类？
- 无关的认知负荷，与完成任务的环境有关。示例：如何再次部署此组件？
- 相关认知负荷， 这 涉及需要学习或高性能特别注意任务的各个方面。示例：此服务应如何与ABC服务交互？
广义上讲，您应该尝试最小化内在的认知负担（通过培训，对技术的良好选择，聘用，结对编程等），并消除无关的认知负担（无聊或多余的任务或命令，它们几乎没有保留在工作记忆中的价值） ）。这将为人的认知负担（“增值”思维所在）留出更多空间。
有关认知负载如何应用于软件开发的概述，请参阅Jo Pearce的文章“ 管理团队学习的认知负载 ” 。
团队的认知负荷
当将认知负荷的概念应用于整个团队时，您需要限制期望团队工作的软件系统的大小。也就是说，不要让软件子系统超出负责它的团队的认知符合。这对软件系统的形式和架构具有强烈而彻底的影响：当您将认知符合明确视为可支持性和可操作性的指标时，软件架构将变得更加具有“团队形”。
尽量减少不必要的认知负担的驱动力还导致需要关注开发人员的经验和运维人员员的经验。通过使用明确定义的平台和组件，您的团队将能够减少不必要的认知负担。
一些组织甚至开始使用认知符合作为对软件体系结构和系统边界决策的明确输入。
为什么您应该使用团队认知能力来合理选择微服务
在“ 您构建，运行 ”的世界中，整个团队负责软件服务的成功运营，必须消除对团队软件所有权的不必要障碍。模糊的命令或神秘的配置选项增加了团队成员的（外部）认知负担，有效地降低了他们获取或改善面向业务方面的能力（认知负荷）。
另一个典型的示例是等待另一个团队为基础结构提供验证或更新配置。这打断了依赖团队的流动，再次导致认知能力的有效利用减少。
团队认知能力的下降使团队完全拥有软件服务的能力受到压力。团队花费大量时间来处理复杂的配置，容易出错的过程和/或等待新的环境或基础结构更改，以致于无法对可测试性或运行时边缘案例的重要方面给予足够的重视。
正如软件开发人员Julia Evans所说，减少团队的认知负担意味着设置界面边界。 您组织中的每个技术人员都不必是Kubernetes专家。
换句话说，通过确保团队的认知负担不太高，您将有更好的机会来增强团队所使用的软件的可支持性和可操作性。它可以更好地拥有自己的服务，因为团队更好地了解它们。
减少团队认知负荷并改善流程的三种方法
没有降低团队认知负担的神奇方法，但是我们与全球许多大型组织（包括中国，欧洲和美国）合作，建议使用三种有用的方法：定义明确的团队互动模式，独立的流程，统一的团队，以及最薄的可行平台。
1.建立明确的团队互动模式
在组织中，团队之间的关系经常没有很好地定义或理解。正如罗素·阿科夫（Russell Ackoff）所说，组织中出现的问题“ 几乎总是零件相互作用的产物，而不是单个零件作用的产物。 ”
您可能已经听到诸如“为什么我们必须与其他团队合作？”之类的抱怨。或“为什么那个团队不提供我们所需的东西？” 这些迹象表明组织内部的团队互动是模棱两可的。在《团队拓扑》一书中，我们确定了三种核心的团队互动模式，以帮助阐明和定义团队之间的互动方式：
- 协作：在定义的时间段内与另一个团队合作，以发现新的工作方式，新工具或新解决方案。
- X即服务：使用或提供“服务即服务”，并具有清晰的API和对服务级别的明确期望。
- 促进：帮助团队（或得到团队帮助）获得新技能或新领域意识，或采用新技术。
有了这些定义明确的团队互动模式，您就可以开始在组织级别上听取信号，以了解效果良好的团队互动和不良好的团队互动，包括认知负担问题。
例如，如果协作交互持续太长时间，则可能表明该技术的某些方面最好由平台作为服务提供。
同样，如果一个团队希望使用“作为服务”的监视工具，但经常需要与提供团队合作来诊断问题，则这可能表明使用团队的认知负荷过多，您需要简化API。
2.使用独立的，按流程分组的团队
在大型和小型组织中，越来越多的小型跨职能团队（具有多种技能）拥有整个问题领域的“切片”，从创意到实时服务。这样的团队通常称为产品或功能团队。
但是随着物联网和无处不在的连接服务的发展，我们称它们为“流对齐”，因为当您谈论物理设备，在线服务和网络之间的多对多交互时，“产品”失去了其含义。
与流程保持一致的团队与组织部门所要求的变更流保持一致，无论是业务线，市场部门，特定的地理位置还是政府服务。
确保流对齐的团队可以独立于其他团队进行绝大部分工作来分析，测试，构建，发布和监视更改，这一点极为重要。依赖关系会引入大量的认知负担（例如，等待其他微服务或环境能够进行测试，或者没有以微服务为中心的监视）。
确保按流程排列的团队在日常工作流程中基本独立，可以消除无用的外部认知负担，使团队可以专注于工作的内在和紧密联系（与领域相关）。这种独立性的部分原因在于能够使用有效的平台。
在大型组织中，交付大型，复杂的系统时，将两个或三个团队紧密地联系在一起很有用。这种密切的关系有助于避免一个团队等待另一团队。
显然，团队确实依赖其他服务和相关的团队来提供基础结构，运行时API，工具等。但是，这些依赖关系不会阻止流向一致的团队的工作流程。能够自助服务新测试环境，部署管道或服务监视都是无阻塞依赖关系的所有示例。与团队保持一致的团队可以根据需要独立使用它们。
3.建立最薄的可行平台
与流保持一致的团队应该期望从定义明确的平台使用服务，但避免使用过去庞大，不友好的平台。相反，构建最薄的可行平台（TVP）：加速团队开发现代软件服务和系统所需的最小的API，文档和工具集。
这样的TVP可能只有一个Wiki页面，该页面定义了其他团队应该使用哪种公共云提供商服务以及如何使用。较大的组织可能会决定在底层云或IoT平台上构建其他服务，但是这些额外服务应始终“足够稠密”，以加速以流为单位的团队中的变更流程，而不是更稠密。
当内部平台肿，缓慢且有故障时，避免过去的频繁错误；有糟糕的用户体验；而且-更糟的是-必须使用。
一个好的平台可以作为流对齐团队的力量倍增器，通过关注开发人员的经验，易用性，工具的简单性和文档的丰富性，帮助他们专注于核心领域的功能。简而言之，使用平台本身内的标准敏捷性和DevOps做法，将与流对齐的团队作为内部客户来构建和运行平台，作为产品或服务本身。
云通信公司Twilio的工程师在内部对其交付团队采用了这种方法。在2018年QCon的一次演讲中，工程高级总监贾斯汀·北川 （Justin Kitagawa）描述了Twilio的内部平台如何通过提供统一的自助式声明性平台来构建，交付和运行数千个全球微服务，从而减轻了工程师的认知负担。
此外，该平台的开发者经验会定期根据内部客户的反馈（使用净发起人得分）进行评估。
Twilio的内部平台明确遵循以下关键原则：
- API优先：授权开发团队通过自动化在平台功能方面进行创新。
- 通过网守自助服务：帮助开发团队确定自己的工作流程。
- 声明式胜于命令式：“什么”优先于“如何”。
- 善解人意地构建：了解使用该平台的人们的需求和挫败感。
这种方法使Twilio能够扩展到全球40,000多家组织的客户群。
通过减少认知负担，一个好的平台可以帮助开发团队专注于问题的不同方面，增加个人和团队级别的流程，并使整个团队更加有效。
减轻负荷
在考虑软件系统边界的大小和形状时，团队的认知负荷是一个重要的方面。通过确保团队的认知负担不会太高，您可以增加团队成员能够有效地构建和运营服务的机会，因为他们会正确地理解他们正在构建的系统。我们建议使用三种核心的团队互动模式来阐明团队之间的互动，并最终帮助减轻认知负担。当与独立的按流分组的团队和最薄的可行平台一起使用时，这些团队交互模式将帮助您的组织检测系统中不同部分的认知负担何时过高。