软件架构师速成指南

第 30 章 扩大组织规模

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

如何扩大组织规模？就像扩展系统一样！

水平缩放似乎更自然

数字世界讲究的是可扩展性：数百万网站、每月数十亿的点击量、PB 级的数据、更多的推文、更多的图片上传。为了实现这一目标，架构师们学习了大量有关系统扩展的知识：使服务无状态且可横向扩展、尽量减少同步点 以最大限度地提高吞吐量、保持事务范围在本地、避免同步远程通信、使用巧妙的缓存策略以及缩短变量名（开个玩笑！）。

随着我们周围的一切都在以前所未有的吞吐量进行扩展，所有这一切的限制因素 必然是我们、人类用户和我们工作的组织。那么，你可能会问，对可扩展性了如指掌的 IT 架构师是否能将他们的专业知识应用到企业的吞吐量扩展和优化上。我可能会成为一名架构师宇航员¹但我不禁感到，许多经验丰富的 IT 架构师所熟知的可扩展性和性能方法同样适用于组织的扩展。如果说咖啡店（第 17 章）可以教会我们如何最大限度地提高系统的吞吐量，那么我们的 IT 系统设计知识也许可以帮助提高组织的性能？

组件设计--个人生产力

提高 的吞吐量要从个人做起。有些人的工作效率是其他人的十倍。对我来说，这是个 "一击即中 "的问题：当我 "进入状态 "时，我的工作效率会高得惊人，但当我经常被某些事情打断或惹恼时，我也会很快失去动力。因此，我不会给你任何好的个人建议，而是向你推荐许多资源，比如 GTD（Getting Things Done）、²它建议你尽量减少未完成任务的库存（让精益管理的人高兴），并将大型任务分解成可立即执行的小型任务。例如，"我真应该换掉那辆破车 "会变成 "这个周末去拜访三家经销商"。传入的任务会被分类，要么立即处理，要么暂时搁置，直到可操作为止，从而减少并发线程的数量。这些建议非常合理，但要成功实施这些建议，始终需要一点信任和大量的纪律。

避免同步点--会议无法扩展

让我们假定 每个人都尽其所能提高工作效率和吞吐量，这意味着我们拥有高效和有效的系统组件。现在，我们需要看看 集成架构，它定义了组件之间的交互，换句话说，就是人与人之间的交互。最常见的交互点之一（除电子邮件外，稍后详述）肯定是会议。单看这个名字，我们中的一些人就会起鸡皮疙瘩，因为它意味着人们聚在一起 "见面"，但并没有定义任何具体的议程、目标或结果。

备注

会议是同步点--众所周知的吞吐量杀手。

从系统设计的角度来看，会议还有一个令人头疼的特性：会议要求多人（大部分情况下）同时出现在同一地点。在软件架构中，我们称之为同步点，众所周知，同步点是最大的吞吐量杀手之一。同步 "一词源于希腊语，主要指事情在同一时间发生。在分布式系统中，要让事情同时发生，一些组件必须等待其他组件，这显然不是最大化吞吐量的方法。

等待同步点的时间越长，对绩效的负面影响就越大。在一些组织中，在高层人员中寻找一个会议时间段可能需要一个月甚至更长的时间。这种对人员时间的资源争夺会大大降低决策速度和项目进度（并损害速度经济；参见第 35 章）。其效果类似于锁定数据库更新：如果许多进程都试图更新同一张表的记录，吞吐量就会大打折扣，因为大多数进程只能等待其他进程完成，最终导致 陷入可怕的僵局。大型企业中充当事务监控器的行政团队 强调了使用会议作为主要交互模式所造成的开销。更糟糕的是， ...