有一种观点：
- 您不需要分布式系统！如今的计算机速度如此之快，您只需一台机器即可为所有客户提供服务
这种论点是愚蠢和简单化的。
这一论点基于一个事实：
- 现代机器非常强大，每秒可以完成大量工作，甚至可以将一些大型企业的所有数据都放入内存中。
- 每秒可以实现数千甚至数百万个请求。每秒数百 GB。TB 级内存，甚至更多存储空间。
- 每秒 GB 级存储带宽。数百万 IOPS。
现代机器速度超快，能够利用这种速度的软件可以实现令人难以置信的事情。
因此：
- 许多系统的分布都是不加思索的，或者浪费的，或者增加复杂性和降低效率
例如：EC2 提供的单个实例有 32TiB 内存和 896 个 vCPU，以及 200Gbps 网络带宽。
许多非常重要的工作负载可以放在一台这样的机器上。
如果我们只关心规模的话，这是可能的。
但是，不仅仅是规模！
Marc Brooker 这篇文章《不仅仅是规模》讨论了规模在分布式系统中的重要性，但也强调规模只是使这些系统变得有趣和有用的一小部分。
- 虽然规模至关重要，但它并不是唯一需要考虑的因素。
规模和可扩展性只是分布式系统受到关注的总体原因中的一小部分。
其他实际原因包括：
- 可用性。由多个冗余组件组成的系统可以提供单机系统无法比拟的可用性。分布式系统以线性成本实现了指数级的可用性提升，而且几乎完全无需干预。单机系统只能通过增加故障时间或减少恢复时间来实现更高的可用性，这既复杂又昂贵。
- 耐久性。在多台机器上制作多个数据副本是确保在线数据高度耐久的唯一可靠方法。RAID 等单系统方法基于对故障独立性的根本性错误假设。当然，离线数据可以通过离线备份实现耐久性。
- 利用率。多租户系统通过将多个不同的工作负载打包到相同的资源上来实现更低的成本和更高的利用率。这有两种方式：它允许不同季节周期的工作负载在短期内共享资源，并允许具有不可预测的负载峰值（或故障恢复峰值）的系统共享备用突发资源。这既可以加快恢复速度，又可以显著提高峰值与平均比率。在许多实际系统中，通过提高峰值与平均比率获得的效率超过了调整单机系统以提高效率的机会。
- 延迟。通过将短期负载峰值分散到更大的资源池中，分布式系统可以减少短期系统过载造成的尾部延迟。
- 专业化。由多个组件组成的分布式系统允许这些组件专门用于延迟敏感、吞吐量敏感、位置敏感、计算密集型、内存密集型或任何其他不寻常属性的工作负载。一个很好的例子来自 MemoryDB 论文，我们看到了专用组件的组合如何使整个系统既显着减少内存需求又降低尾部延迟。
- 隔离。使用多个组件构建系统可以优化组件的安全属性。例如，请注意在Firecracker 论文中，Lambda 的架构如何将执行客户代码的强隔离组件与执行简单数据查找任务的多租户组件相结合。
- 变化。系统中最普遍的需求，也是经常被忽视的需求，可能是应对变化的能力。随着业务的发展部署新代码。修补安全问题。对客户问题做出反应。在分布式系统中，通常会利用系统的高可用性机制来实现安全的零影响修补和部署。单机系统更难改变。
这些属性使系统实现了一些重要的东西：简单性。
简单是一种系统属性
我们经常可以看到对简单性的还原观点，这种观点只考虑了系统的部分职责，忽略了重要的要求，或忽视了实现这些要求的实际方式。
让我们以部署为例。
- 在许多分布式设计中，当需要进行更改时，部署是通过更换或重新镜像机器来实现的。通常情况下，这使用的是确保高可用性的相同机制：流量从一台机器移走，进行更改并验证，然后流量返回。
- 而单机部署通常较难更改：必须在线对运行中的系统或在停机压力下进行更改。单机验证更改也很困难，因为要么全做，要么全不做。
在欣赏单机部署的简单性时，我们很容易忽略这种复杂性：
- 单机部署的问题是可以解决的，但通常要以更高的系统复杂性为代价：复杂的操作程序、熟练的操作员、高度的判断力、与客户的协调等。
简单是系统的属性，而不是组件的属性，系统包括人和流程。
简单性辩论中的另一个陷阱是将简单与熟悉混为一谈：
- 多年使用 Linux 可能会让人感觉系统管理任务很简单。
- 多年使用 IaC 框架可能会让人感觉云部署很简单。
实际上，两者都相当复杂，但我们很容易得出结论：我们更熟悉的那个才是更简单的。
当然，在实际系统中，规模也有很多方面的影响，其中一种方式就是组织规模。
扩大组织规模
就像计算机系统一样，组织的扩展必须避免协调。
- 组织越是需要不同部分相互协调才能工作，就越无法发展壮大。
- 组织要想在不停滞的情况下发展壮大，就必须精心设计并不断优化，以减少不必要的协调。
组织必须通过避免协调来扩大规模：
- 不必要的协调可能会阻碍其发展能力
- 随着组织的发展，需要不断优化，减少不必要的协调
微服务和 SoA 等方法是允许技术组织避免协调数据模型、实施选择、队列管理、工具选择等非核心业务的工具。
从根本上说，应用程序接口是一种契约，它将人与人之间的协调转移到系统与系统之间，并以允许系统高效处理协调的方式对协调进行限制。
您也许可以在一个盒子上运行所有的业务逻辑，但随着企业的发展，您可能会发现这样做所需的协调工作会越来越慢。
最后，规模确实很重要。
规模上限
作为一名企业主，没有什么比满载而归的喜悦和痛苦更让人难忘的了。
- 喜悦，因为这是生意成功的标志。
- 痛苦，是因为如果店面更大，就能为更多顾客提供服务。
门外排队的人把顾客拒之门外，这些人的生意也就没了。开设第二家分店可能需要几个月的时间，增加面积也是如此。机会正在溜走。
聪明的企业需要正确的规模。对于墨西哥卷饼车来说，十万平方英尺的面积实在太大了。所有这些空间都很昂贵，而且会分散注意力。对于超市来说，50 平方英尺太小了。人们几乎进不了门。人行天桥和火车桥的建造方式不同。规模很重要，无论是向上还是向下。
这个想法并不难。它是工程学领域的灵魂所在。
新工程师所能做的最明智的事情就是关注企业的需求。无论是现在还是将来。
- 了解是什么驱动了企业的成本和可扩展性需求。
- 了解它是如何赚钱的。
- 了解未来的预测以及随之而来的风险。
- 忽略那些谣言和强烈的意见。
规模确实很重要，但它并不是分布式系统中唯一的考虑因素。