System Design现代系统设计概论

概论"/>

System Design现代系统设计概论

1. 什么是系统设计？

系统设计是定义组件及其集成、API 和数据模型以构建满足一组指定功能和非功能需求的大型系统的过程。

系统设计使用计算机网络、并行计算和分布式系统的概念来设计可扩展且高性能的系统。分布式系统本质上具有良好的可扩展性。然而，分布式系统本质上是复杂的。系统设计的纪律可以帮助我们克服这种复杂性并完成工作。

系统设计的目的是构建可靠、有效、可维护等特征的系统。

• 可靠的系统可以处理故障、故障和错误。
• 有效的系统可以满足所有用户需求和业务要求。
• 可维护的系统灵活且易于扩展或缩小。添加新功能的能力也属于可维护性的范畴。

2. 使用构建块的现代系统设计

我们分离出常用的设计元素，例如负载均衡器，作为高级系统设计的基本构建块。这有两个目的。首先，它使我们能够详细讨论所有构建块并讨论它们有趣的迷你设计问题。其次，当我们解决设计问题时，我们可以专注于特定问题的方面，提及我们将使用的构建块以及我们将如何使用它。这有助于我们消除对常见设计元素的重复讨论。

我们已经确定了对于设计现代系统至关重要的十六个构建模块。

3. 什么是系统设计面试？

了解系统设计访谈 (SDI) 以及如何战略性地进行这些访谈。

SDI 发生在更高的抽象级别。我们找出需求并将其映射到计算组件和连接这些子系统的高级通信协议。

最终答案并不重要。重要的是优秀的申请人带领面试官经历的过程和旅程。

注意：与面试中的编码问题相比，系统设计更符合我们将在工作中完成的任务。

4. 我们如何解决设计问题？

设计问题是开放式的，并且一开始就故意含糊其辞。这种模糊性模仿了现代商业的现实。

面试官经常询问一个众所周知的问题，例如设计 WhatsApp。现在，真正的 WhatsApp 应用程序具有众多功能，将所有这些功能作为我们的 WhatApp 克隆的要求可能不是一个明智的主意，原因如下：

• 首先，我们采访的时间有限。
• 其次，使用系统的一些核心功能应该足以展示我们解决问题的能力。

我们可以告诉面试官，真正的 WhatsApp 所做的许多其他事情我们不打算包含在我们的设计中。如果面试官有任何异议，我们可以相应地改变我们的行动计划。

以下是我们在系统设计面试期间应遵循的一些最佳实践：

• 申请人应该提出正确的问题来巩固要求。

• 申请人还需要确定问题的范围，以便他们能够在面试的有限时间内尽力解决问题。SDI 的长度通常约为 35 至 40 分钟。

• 与面试官的沟通至关重要。默默地做设计并不是一个好主意。相反，我们应该与面试官接触，以确保他们理解我们的思维过程。

5. 呈现高层设计

在较高层次上，组件可以是前端、负载均衡器、缓存、数据处理等。系统设计告诉我们这些组件如何组合在一起。

架构设计通常将组件表示为盒子。这些方框之间的箭头代表谁与谁交谈以及这些方框或组件如何组合在一起。

我们可以针对给定的问题画一张如上所示的图表并将其呈现给面试官。

6. 每个 SDI

SDI 通常包括与设计如何随着时间的推移而演变相关的问题，因为系统的某些方面增加了某个数量级，例如用户数量、每秒查询数量等。系统社区普遍认为，当系统的某些方面增加十倍或更多时，相同的设计可能不再适用，可能需要更改。

设计和操作更大的系统需要仔细思考，因为设计通常不会随着系统需求的增加而线性扩展。

SDI 中的另一个问题可能与我们为什么不设计一个已经能够处理比必要或预测更多的工作的系统有关。

与复杂项目相关的美元成本是我们不这样做的主要原因。

7. Google 的设计演变

谷歌搜索早期版本的设计在今天看来可能很简单，但在当时却相当复杂。它还降低了成本，这对于像谷歌这样的初创公司维持生存是必要的。结果是，作为设计师，我们所做的一切都会对企业及其客户产生影响。我们需要通过有效利用资源来满足或超越客户的需求。

8. 设计挑战

随着时间的推移，事情会发生变化，并且会因为以下原因而崩溃：

• 对于设计问题，没有单一正确的方法或解决方案。
• 很多事情都是基于我们所做的假设。

9. 设计师的责任

作为设计师，我们需要在设计层面提供容错能力，因为几乎所有现代系统都使用现成的组件，而且这样的组件有数百万个。因此，总会有一些东西发生故障，我们需要向客户隐瞒这种不良的现实。

大多数系统设计理论都来自分布式系统领域。分布式系统为我们提供了成熟软件原理的指南。其中包括以下内容：

• Robustness稳健性（危机期间维持运营的能力）
• Scalability 伸缩性
• Availability可用性
• Performance性能
• Extensibility可扩展性
• Resiliency弹性（中断后在可接受的时间内恢复正常运行的能力）

举个例子，我们可能会说，当网络组件发生故障时，我们需要在可用性和一致性之间进行权衡，因为 CAP 定理表明，在网络分区下我们不能同时拥有这两者。这种共同语言有助于沟通，并表明我们精通理论和实践。

Reference