如何估计系统设计面试问题的机器数量

Question

有一次我在一次面试中被问到一个系统设计问题。我不记得细节了，但它是一个相当典型的web应用程序，所以我描述了一个非常常见的体系结构(用户向服务器发出REST风格的请求，服务器与数据库对话，数据库被分区和复制以实现可伸缩性，世界各地有多个数据库以加快访问速度，还有多个服务器，前面有一个负载均衡器，它可以执行循环或其他更聪明的操作)。

我那次面试失败了。我的错误是我高估了申请的规模。在给出了多个提示之后，我们一致认为，所有这些复杂性都是不必要的，而且(对于我获得的用户数量)，这个应用程序在只有一个本地数据库的服务器上可以正常工作。(顺便说一句，我知道很长一段时间以来，堆栈溢出本身都是托管在一台机器上的)。

我的问题是，如何正确估计解决方案的服务器/数据库节点的数量？

我天真的理解是，我需要估计应用程序的参数，然后粗略地将工作负载除以典型服务器的带宽。

“典型的”服务器可能有：

• 256 GB内存
• 1-10 TB磁盘空间
• 10 Mb/S网络带宽
• 服务器与数据库之间的请求时间为100-500 is。

听起来合理吗？

作为一个具体的例子，让我们来看看本文介绍了一个URL缩短器的设计.。

通过对应用程序规模的估计，确定数据库需要15 the的存储空间，缓存需要170 of的RAM，网络带宽约为10 of /S。

根据我的估计，这个应用程序也可以托管在一台机器上(可能还有一些额外的垂直缩放)。然而，他们继续描述一个具有分区数据库、多个服务器、负载平衡器等的“复杂”体系结构。

如果在面试中被问到这个问题，那么建议在一台机器上托管这个服务器是否合理，因为它要便宜得多，并且从解决方案中消除了很多复杂性？如果没有，您将如何估计您需要的机器数量？

Answer 1

特别是在面试中，他们不是在寻找解决方案，而是你如何观察，以及如何解决问题。

他们可能想让你证明你在考虑商业利益，并且愿意参与讨论，找出企业的真正需求，并帮助他们管理真正的风险。

如果他们向您提供了一些关于系统性能的数据，也许他们想看看您如何在信封计算的后面缩小合适的解决方案。

So第一个问题应该是:业务预期是什么？

这些需要准确地说明系统在特定时间内的运作方式。类似于：

• 在晚上8点到凌晨2点之间，95%在过去2周内创建的链接请求在100 to内得到响应。
• 对于两个多星期前创建的链接，每10分钟就有1000次请求，完成时间不超过500 no。
• 该系统将可用于查询99%的时间。
• 如果系统失败，所有被确认为已创建的链接都必须在还原系统时可用。
• 系统应在故障后1小时内恢复。

这些语句中的每一条都有助于准确地阐明运行此系统所需的内容。至少可以将它们设置为报告/测试，以验证系统是否在预期的范围内运行。

The第二个问题是:限制是什么？

并不是每一家企业都是谷歌( Google )，或是脸书( Face Book )。并不是每一家企业都需要或负担得起闪闪发亮的小玩意。因此，他们通常已经拥有了他们愿意利用的基础设施，无论是在内部还是通过提供者。其中一些限制将是困难的，如果结果值得的话，其他限制将是可谈判的。

• 必须使用xyz数据库引擎
• 必须每天进行备份。
• 备份必须在完成后1小时内移出现场。
• 只有xyz机器才能使用。
• 数据必须存储在Raid中。

解决

现在，您有了一组需求和限制，有时间思考各种可能性并检查它们是否相关。根据实现和操作的成本(材料+时间)对每个可能的实现进行排序，以及它满足需求的可能性，以及它是否违反了限制。

• 选择最便宜的
• 选择最便宜的来保养
• 选择最容易扩展的
• 选择最容易收缩的
• 选择最容易改变的
• 选择一个能够适应所有限制的方法，而不管维护起来有多困难。
• 选择最干净的解决方案，这只会打破一些(较软的)限制。

如果这些都是相同的解决方案，请继续思考。如果不是很好，那就继续讨论。让企业知道解决方案是否限制了他们未来的选择，是否运营成本更高，或者是否存在其他形式的风险，如缺乏技术专长。

Handwavium规范

至于如何具体说明每个解决方案，这在很大程度上取决于所使用的特定技术。您可以根据某些限制和要求进行一些手工投影，以获得对光谱的感觉。就像可能有一条规则，软件、数据库和备份必须在不同的机器上。或者一个地理上冗余的系统需要在两个数据中心中至少有4台机器。

只有当你对软件的实际响应时间有一些数据时，才能得到准确的要求。对于广泛使用的系统，如数据存储和缓存，公开可用的参考数据+一个空白应该足以支持信封样式的计算。如果你可以尝试一个实际的设置，即使使用低功耗的硬件，那就更好了.

明确计算的基准值，并显示+-10%/20%的预测值，以说明由于参考费率的变化，需求可能会发生什么变化。这里的重点是解决低估/过高估计的风险，并查看这对最终解决方案的影响。