系统分析与系统设计：每个开发人员都需要知道的 System Analysis & System Design

Posted 2022-10-30 禅与计算机程序设计艺术

您是一名软件工程师，有兴趣在您的职业生涯中取得进步并在就业市场上获得优势吗？学习系统设计可以在这两个方面为您提供帮助。通过了解创建现代系统以满足实际需求的过程，您将更好地准备在日常工作中提供弹性和可扩展的解决方案。在您的工具包中拥有系统设计技能也将帮助您在您的领域取得进步并在您的组织中提升。

系统设计已成为软件开发过程的关键。这就是为什么退后一步分析好的设计对软件和信息系统的长期效率、寿命和成功的宏观影响的原因。系统设计及其所针对的要求并非凭空存在。作为一名软件工程师，了解为什么要针对某些需求、它们与组织的业务目标之间的关系以及这些决策如何影响整体用户体验对您很有帮助。

为了更好地理解影响系统设计的许多因素以及信息技术专业人员在系统实施遇到问题时如何应对，我们需要谈谈系统分析。

今天，我们将通过比较的视角来看待系统设计和系统分析主题。我们将探讨这些过程，它们如何适应更广泛的系统开发生命周期，以及如何区分它们。

我们将介绍以下内容：

• 什么是系统分析？

• 什么是系统设计？

• 系统分析与系统设计

• 1. 系统分析先于系统设计

• 2. 关注“什么”与“如何”

• 3.完成不同的任务

• 从今天开始掌握系统设计

什么是系统分析？

系统分析是审查技术系统以进行故障排除、开发或改进的过程。这样的系统可能是软件实现，例如系统或应用程序。将系统分析视为更大过程中的一个阶段是很重要的，即系统开发生命周期 (SDLC)，我们将在后面更详细地讨论。在系统分析阶段，分析人员关注的是针对已定义问题提出建议的解决方案。在这样做时，他们会考虑产品的可行性和有效性。系统分析师考虑系统的总体目标，然后他们可以将其分解为组件或模块以进行单独的分析。

两项任务通常有助于这些分析：可行性研究和需求工程。

• 可行性研究侧重于衡量所提出的解决方案解决已定义问题的可能性的几个指标

• 需求工程决定了提议的解决方案必须完成什么

稍后我们将更详细地探讨这两项任务。

在完成这些任务时，系统分析师通常会朝着一个关键输出工作：最终的系统需求规范(SRS) 或系统需求文档。当系统分析师交付这个产品时，他们为软件工程师提供了生命周期下一阶段的主要输入：系统设计。

什么是系统设计？

在软件开发中，系统设计是为系统定义体系结构、接口和数据模型以满足 SRS 中概述的要求的过程。在这个阶段，软件工程师将业务需求转化为技术规范，以构建新的物理系统或更新现有系统。如果系统设计得当，它将满足客户的需求，并最终实现业务目标。

顾名思义，系统设计是一个应该系统地进行的过程。通过全面、有序地考虑系统的基础架构，从硬件和软件到数据以及数据的存储方式，您可以帮助确保最终设计具有可靠性、有效性和可维护性等重要特征。

• 可靠的系统对错误、故障和故障具有弹性。

• 有效的系统满足用户的需求和业务设定的要求。

• 可维护系统经证明灵活且易于按比例放大或缩小。向可维护系统添加新功能通常也更容易。

下面我们来了解系统分析和系统设计之间的差异。

系统分析与系统设计

作为 SDLC 的连续阶段，系统分析和系统设计有一个更广泛的目的：开发满足客户和业务需求的技术系统。从那里开始，两个过程之间出现了许多差异。我们现在将讨论其中的三个差异。

1. 系统分析先于系统设计

在这里，了解系统开发生命周期 (SDLC)的大局会有所帮助。SDLC，也称为软件开发生命周期或应用程序开发生命周期，是创建信息系统的多阶段过程。它涵盖了系统从规划、启动到评估的整个生命周期。作为信息技术中的一个关键概念，SDLC 包含了软件和硬件配置的混合。这些可以包括仅由软件、仅由硬件或两者组合组成的系统。

SDLC 不是一种方法论。它是阶段的描述。然而，有几种方法或模型适合 SDLC。一些著名的例子包括瀑布、敏捷软件开发和快速原型设计。

根据您的来源，您可能会发现 SDLC 阶段的数量和名称有所不同。但是开发一个系统通常会涉及相同的主要任务，这个过程分为几个阶段的一种方式如下：

1. 规划和初步分析

2. 系统分析

3. 系统设计

4. 发展

5. 测试和集成

6. 执行

7. 运维

8. 评估

SDLC 阶段通常意味着按顺序实施，其中一个阶段的完成先于下一个阶段的启动。这种排序让开发人员、工程师和程序员一次可以专注于一个阶段，并简化了开发过程。根据组织和方法，有时并非每个阶段都进行。在其他时候，这些阶段可能会重叠。

无论如何，一件事通常是正确的：系统分析和系统设计是流程的基本和连续部分。由于 SDLC 的目标是创建支持已确定需求的高质量信息系统，因此系统分析先于系统设计。毕竟，为了让系统设计开始满足需求，软件工程师首先需要知道这些需求是什么。

2. 关注“什么”与“如何”

系统分析和系统设计以多种方式划分其职责。我们已经讨论了时间的重要性以及如何在技术解决方案设计之前收集需求。此外，系统分析师和软件工程师对他们的可交付成果有不同的关注点，我们可以将其标记为系统开发的“什么”与“如何”。

系统分析：“什么”

如前所述，系统分析是 SDLC 的早期基础阶段。在软件工程的背景下，系统分析师出于各种目的审查技术系统，最终使用计算机系统提出问题的解决方案。换句话说，他们确定了满足客户和客户需求所需的内容。在可行性研究和需求工程之后，他们将这些信息记录在系统需求规范 (SRS) 文档中。

系统设计：“如何”

完成 SRS 后，流程进入系统设计阶段，这相当于确定如何满足要求的阶段。要可视化预期的结果，请考虑创建不同组件的独特组合。为了使这种可视化更加有形，我们将这些组件称为构建块，表示跨系统设计问题共享的相似性，这些问题已经被提取出来以便于重用。

出于我们的目的，您可以借鉴16 个现代系统设计的构建块。要了解这些积木的用途，可以将它们视为砖块，一种可组合的原材料。一旦掌握了这些构建块的作用，就可以使用它们来演示如何为几乎任何设计问题创建可靠、有效和可维护的系统。

3.完成不同的任务

系统分析和系统设计之间的另一个区别是在工作过程方面。系统分析中使用了两个约定：可行性研究和需求工程。同时，系统设计的复杂性使任何单一的方法都无法解决所有问题，但工程师可以使用各种一致的程序来系统地解决问题。我们将讨论一种可以解决多种场景的可重用方法。

可行性研究

回想一下，系统分析涉及概述针对已定义问题的建议解决方案。为了衡量潜在解决方案的适用性，系统分析师转向可行性研究。

这些研究通常包括以下步骤：

1. 识别现有系统中的缺陷。这可以从准备系统流程图开始，包括其子系统，然后检查它是否存在漏洞或故障点。

2. 确定新系统的目标、范围和负责的用户。

3. 准备拟议系统的流程图。

4. 确定提案是否是新系统或升级系统的可行解决方案。

最后一步主要关注权衡三种类型的可行性：

• 技术可行性：注意客户或客户当前的硬件和软件资源，并决定现有设置是否可以满足提议系统的技术要求。

• 经济可行性：对提议的系统进行成本效益分析，并将结果与项目预算进行比较。

• 操作可行性：确定系统是否会按照用户期望的方式工作，考虑开发和实施系统所需人员的可用性。

其他类型的可行性可能包括社会可行性、管理可行性、法律可行性和时间可行性。但无论系统分析师如何划分可行性，预期的结果都是一样的：确定用于解决已定义问题的提议系统是否可以并且应该继续进行。当此分析结果获得批准时，系统分析师就可以从事需求工程。

需求工程

在需求工程（也称为需求分析）中，分析师将定义、记录和维护与提议的系统相关的需求。通常，此过程包括检查有关系统目标和目的的数据，例如：

• 拟议的系统将如何在高水平上工作

• 提议的系统必须具备哪些品质或特性才能提供预期的结果

稍后，软件工程师将寻找与这些发现相符的特定编码解决方案。

需求工程的一个主要焦点是确保彻底了解客户的需求和期望。生产系统的公司和客户之间的沟通是关键，需求工程可以包括支持一致性的几个活动：

• 征集：最初从客户那里收集需求

• 分析：更详细地评估客户的需求

• 规范：生成正式文档，有时称为需求规范

• 确认或验证：确保文件化的要求是一致的并满足客户的需求

• 管理：将提议的系统流程与要求相匹配

在可行性研究和需求工程期间，系统分析师可能会使用多种工具。这些可以包括流程图（组织、现有系统或提议的系统架构）和用户界面 (UI) 模型（以了解最终用户如何与系统交互）。

在确定可行性和微调要求后，系统分析师会生成 SRS。本文档使系统设计工程师能够开始为新的或更新的系统进行设计。

系统设计的 RESHADED 方法

尽管设计阶段不存在一刀切的方法，但RESHADED 方法为工程师提供了一种解决许多问题的灵活方法。这种方法阐明了从头开始设计几乎任何系统的步骤，无论您是在处理客户项目还是参加系统设计面试。我们将快速了解首字母缩略词的含义。

• 需求：收集反映客户业务或组织需求的所有功能性和非功能性需求。功能需求代表核心特性，没有它，系统将无法按最终用户的预期工作，而非功能需求是对核心功能没有贡献的基本考虑因素。

• 估算：衡量大规模实施系统所需的硬件和基础设施资源。

• 存储模式（可选）：如果与手头的问题相关，则使用数据流程图阐明数据模型。您需要定义数据的结构、要使用的表、表中字段的类型以及表之间的关系（可选）。当您需要高度规范化的数据、需要以不同格式存储数据的不同部分或面临存储性能和效率问题时，您可能需要此步骤。

• 高级设计：从我们之前讨论的 16 个构建块中进行选择，以满足某些功能要求。

• API：创建用户可以用来调用系统内各种服务的接口。接口采用 API 调用的形式，通常是功能需求的转换。

• 详细设计：分析和改进高级设计，添加或替换构建块以满足非功能性需求，然后概述这些构建块。该大纲应确定组件的工作方式和原因、需要它们的原因以及如何集成它们。

• 评估：将详细设计与要求进行比较。证明权衡并权衡替代设计的利弊。确定需要改进的领域并考虑解决任何被忽视的问题。

• 独特的组件/功能：讨论添加到您的设计中以满足要求的独特功能。这种讨论可以遵循流程中的各个步骤，可能与系统设计访谈或演示最相关。

RESHADED 方法的实用性在其作为解决系统设计问题的一般指南的灵活性方面最为明显。但是，它并不是要解决所有设计问题，因此在设计新解决方案时不要害怕发挥创造力和足智多谋。

从今天开始掌握系统设计

此时，您应该对系统分析和系统设计如何适应软件开发过程以及它们之间的区别有一个很好的了解。即使您的主要关注点是您职业生涯中的系统设计，也最好了解事先发生的事情以及系统分析师对整个 SDLC 的贡献。

如果您是一名软件工程师或有志成为一名软件工程师，我们希望对系统设计的讨论能够启发您更多地了解这一基本过程。为了帮助您掌握系统设计，我们为工程师和经理创建了 Grokking 现代系统设计面试课程。这个交互式课程提供了一个关于使用微服务架构中的各种组件设计复杂系统的现代视角。您将了解本文中讨论的构建块和 RESHADED 方法的所有内容，并有机会将这些概念应用于现实世界的设计问题。

---

附录：现代系统设计的组成部分

描述这些组件的更准确的术语是“积木”。

现代系统设计的想法源于将构建块拼凑在一起形成一个有凝聚力的部分的方法。

通过将单独的系统设计概念视为构建块以形成一个更大的整体，我们可以以易于消化和理解的方式分解复杂的问题。系统设计问题通常具有一些总体相似性。但是，大多数具体细节都是独一无二的。通过分离这些独特的构建块并一次描述它们，我们可以在系统设计中将它们用作独立的构建块。当涉及到大规模系统设计时，考虑我们看到的软件设计模式很重要。

负载均衡器

负载平衡是系统设计的关键组成部分。它涉及在一定范围的资源上委派任务。

一个系统平均每秒可能有数百万个请求。负载平衡器确保所有这些请求都可以通过在可用服务器之间划分来处理。

这样，服务器将拥有更易于管理的任务流，并且一台服务器不太可能因请求而负担过重。平均分配计算负载可以实现更快的响应时间和更多网络流量的容量。

负载平衡器是系统设计过程的关键部分。它们启用了现代网页设计所需的几个关键属性。

• 扩展：负载均衡器通过隐藏对服务器数量所做的更改来促进扩展，无论是向上还是向下。

• 可用性：通过划分请求，负载均衡器即使在服务器中断的情况下也能保持系统的可用性。

• 性能：将请求定向到流量较低的服务器会减少最终用户的响应时间。

键值存储

键值存储或键值数据库是类似于哈希表或字典的存储系统。哈希表和字典是关联的，因为它们以（键，值）格式将信息存储为一对。由于每个值都链接到一个键，因此可以轻松地检索和排序信息。

键值存储是分布式哈希表 (DHT)。

分布式哈希表只是哈希表的分散版本。这意味着它们共享键值对和查找方法。

键值存储中的键将数据视为单个不透明集合。存储的数据可以是 blob、服务器名称、图像或用户想要存储的任何内容。这些值被称为不透明数据类型，因为它们被它们的存储方法有效地隐藏了。为了支持信息隐藏和面向对象编程 (OOP)等概念，数据类型是不透明的很重要。

当代大型键值存储的示例是Amazon 的 DynamoDB和Microsoft Cassandra。

Blob 存储

Blob或二进制大对象存储是非结构化数据的存储解决方案。这些数据几乎可以是任何类型：照片、音频、多媒体、可执行代码等。

Blob 存储使用平面数据组织模式，这意味着没有目录或子目录的层次结构。

大多数 Blob 存储服务（例如Microsoft Azure或AWS S3）都是围绕“一次写入，多次读取”或WORM的规则构建的。这确保了重要数据受到保护，因为一旦写入数据，它就可以读取但不能更改。

Blob 存储非常适合任何数据量大的应用程序。Blob 存储的一些最著名的用户是：

• YouTube（谷歌云存储）

• Netflix（亚马逊 S3）

• Facebook（构造）

这些服务通过大型媒体文件生成大量数据。据估计，仅 YouTube每天就会产生 1 PB（ 1024 TB！）的数据。

数据库

在扩展和清除系统功能时，传统的文件存储方法具有很大的局限性。这些限制的答案是数据库。

数据库是可以轻松访问和修改的有组织的数据集合。数据库的存在是为了使存储、检索、修改和删除数据的过程更简单。

有两种基本类型的数据库：

• SQL、关系数据库

• NoSQL，非关系型数据库

简而言之，关系数据库是结构化的，使用预定的模式，并记录联系电话和地址等数据。非关系数据库是非结构化的并使用动态模式。非关系数据库是存储个人资料或购物偏好等信息的文件目录。

数据库几乎是系统设计的通用构建块，需要涵盖的内容很多。要深入了解数据库，请查看此数据库设计教程。

速率限制器

速率限制器为服务将满足的请求数量设置了限制。它将限制超过此阈值的请求。

速率限制器是服务和系统的重要防线。它们防止服务被请求淹没。通过禁止过多的请求，它们可以减少资源消耗。

在某些情况下，速率限制器可以执行与负载平衡器类似的功能。在处理大量数据的系统中，它们有助于控制机器之间的数据流。

监控系统

监控系统是允许系统管理员监控基础设施的软件。这种系统设计的构建块很重要，因为它创建了一个集中位置，用于实时观察潜在的大型计算机系统的整体性能。

监测系统应具有监测以下因素的能力：

• 中央处理器

• 服务器内存

• 路由器

• 开关

• 带宽

• 应用

• 重要网络设备的性能和可用性

分布式消息队列

消息队列是称为生产者和消费者的两个连接实体之间的中介。生产者创建消息，消费者接收并处理它们。

消息队列有助于通过异步通信提高性能，因为生产者和消费者彼此独立地行动。因此，消息队列有助于解耦或减少系统中的依赖性。这提高了可靠性并允许更简单、更简洁的系统设计。此外，异步消息传递有助于可扩展性。可以添加更多消费者以补偿增加的负载。

分布式消息队列有几种不同的用例。

1. 发送电子邮件：顾名思义，消息队列可以发送电子邮件。出于多种原因，包括帐户验证和密码重置，需要许多不同的服务来发送电子邮件。

2. 数据后处理：具有多媒体支持的应用程序处理不同格式或平台的图像和视频。这可能是一个耗时且资源密集的过程，但消息传递队列支持离线处理以减少最终用户延迟。

3. 推荐系统：许多网站使用cookie来个性化用户的内容。该系统检索用户数据并对其进行处理。可以合并消息队列以使此过程更有效，因为后台数据处理可能很耗时。

分布式唯一 ID 生成器

使用唯一标识符标记系统中的实体很重要。在大型分布式系统中，每秒可能发生数百万个事件，因此我们需要一种区分它们的方法。唯一的 ID 生成器执行此任务并启用事件流的日志记录和跟踪以用于调试或维护目的。

在大多数情况下，这是一个通用唯一 ID (UUID)。这些是 128 位数字，如下所示：123e4567e89b12d3a456426614174000十六进制。有了这么大的数字，就有大量可能的 ID，但不能完全保证所有 ID 都是唯一的。

我们可以使用一个中央数据库，它采用给定的 ID，并通过每次将值加一来使其唯一。不幸的是，对于数据库解决方案，有一个故障点可能会中断整个 ID 生成过程。

使用范围处理程序可以使使用数据库的概念多样化。范围处理程序具有多个服务器，每个服务器都覆盖一系列 ID 值。可以为一台服务器分配 100,000 到 300,000 的值。一旦达到 ID 300,001，它将联系中央服务器以分配新的值范围。这增加了可访问性，允许系统在发生故障时保持运行。

Facebook 自己的唯一 ID 生成器称为Canopy。Canopy 使用称为 TraceID 的系统来启用端到端性能跟踪。

分布式搜索

搜索栏对于浏览具有数百甚至数千页的大型网站至关重要。大多数现代网站都有搜索栏来帮助用户准确找到他们正在寻找的内容。每个搜索栏后面都有一个搜索系统。

搜索系统由三个主要实体组成：

• 爬虫：查找/获取内容并创建文档

• Indexer : 建立一个可搜索的索引

• Searcher：针对索引运行搜索查询

分布式搜索系统是可靠的，是水平可扩展性的理想选择。用于分布式搜索的数字产品的一个典型例子是Elasticsearch。

分布式日志服务

日志记录是记录数据的过程，尤其是软件系统中发生的事件。日志文件是这些细节的记录。他们可能会记录服务操作、事务、微服务或任何其他在调试时可能有用的数据。

随着越来越多的设计从单体架构转向微服务架构，分布式系统中的日志记录变得越来越重要。在微服务架构中登录很方便，因为可以从端到端的事件流中跟踪日志。由于微服务可以在系统中创建相互依赖关系，并且一个服务的故障可以级联到其他服务，因此日志记录有助于确定故障的根本原因。

分布式任务调度器

在计算中，任务是在特定时间内需要计算资源的工作单元。

这些资源可能是：

• CPU时间

• 记忆

• 贮存

• 网络带宽

对于图像上传或社交媒体发布等任务而言，异步非常重要，以免用户等待后台任务结束。

任务调度器调解任务和资源之间的供需平衡，以控制系统的工作流程。通过分配资源，任务调度程序可以确保以有效的方式满足任务级别和系统级别的目标。

任务调度程序用于广泛的系统：

• 云计算服务

• 大型分布式系统

• 基于单操作系统的节点

大型分布式系统任务调度器的一个显着示例是 Facebook 的任务调度器：Async。

什么是 CAP 定理？

CAP 定理，或 Brewer 定理，是系统设计领域的一个基本定理。它于 2000 年由加州大学伯克利分校的计算机科学教授 Eric Brewer 在关于分布式计算原理的演讲中首次提出。2002 年，麻省理工学院教授南希·林奇和赛斯·吉尔伯特发表了布鲁尔猜想的证明。CAP 定理指出，分布式系统只能同时提供三个属性中的两个：一致性、可用性和分区容错性。当存在分区时，该定理形式化了一致性和可用性之间的权衡。

分布式系统是计算机的集合，它们一起工作以形成最终用户的单台计算机。所有分布式机器都有一个共享状态并同时运行。对于分布式系统，用户必须能够与任何分布式机器进行通信，而不知道它只是一台机器。分布式系统网络将其数据存储在不止一个节点上，同时使用多个物理机或虚拟机。

CAP 定理说明

让我们看一下 CAP 定理的简单证明。想象一个由两个节点组成的分布式系统：

分布式系统充当具有变量X值的普通寄存器。网络故障导致系统中两个节点之间出现网络分区。最终用户执行写入请求，然后执行读取请求。让我们研究一个系统的不同节点处理每个请求的情况。在这种情况下，我们的系统有两种选择：

• 它可能会因其中一个请求而失败，从而破坏系统的可用性

• 它可以执行这两个请求，从读取请求中返回一个陈旧的值并破坏系统的一致性

系统无法成功处理这两个请求，同时还确保读取返回写入写入的最新值。这是因为由于网络分区，写操作的结果无法从节点 A 传播到节点 B。

现在我们对 CAP 定理有了基本的了解，下面我们来分解首字母缩写词，讨论一致性、可用性和分区容错的含义。

一致性

在一致的系统中，所有节点同时看到相同的数据。如果我们在一致的系统上执行读操作，它应该返回最近的写操作的值。读取应该导致所有节点返回相同的数据。所有用户同时看到相同的数据，无论他们连接到哪个节点。当数据写入单个节点时，它会被复制到系统中的其他节点。

可用性

当分布式系统中存在可用性时，这意味着系统始终保持运行状态。无论节点的各个状态如何，每个请求都会得到响应。这意味着即使有多个节点关闭，系统也会运行。与一致的系统不同，不能保证响应将是最近的写入操作。

分区容错

当分布式系统遇到分区时，意味着节点之间的通信中断。如果系统具有分区容错性，则系统不会发生故障，无论系统内的节点之间的消息是否被丢弃或延迟。为了具有分区容错性，系统必须跨节点和网络的组合复制记录。

CAP 定理和 NoSQL 数据库

NoSQL 数据库非常适合分布式网络。它们允许水平扩展，并且可以跨多个节点快速扩展。

在决定使用哪个 NoSQL 数据库时，牢记 CAP 定理很重要。NoSQL 数据库可以根据它们支持的两个 CAP 特性进行分类：

CA 数据库

CA 数据库支持所有节点的一致性和可用性。不幸的是，CA 数据库无法提供容错能力。在任何分布式系统中，都必然会发生分区，这意味着这种类型的数据库不是一个非常实用的选择。话虽如此，如果需要，您仍然可以找到 CA 数据库。一些关系数据库，例如PostgreSQL，允许一致性和可用性。您可以使用复制将它们部署到节点。

CP 数据库

CP 数据库支持一致性（C）和分区容错性（P），但不支持可用性（A）。当分区发生时，系统必须关闭不一致的节点，直到分区可以被修复。MongoDB是 CP 数据库的一个示例。它是一个使用文档进行数据存储的 NoSQL 数据库管理系统 (DBMS)。它被认为是无模式的，这意味着它不需要定义的数据库模式。它通常用于大数据和在不同位置运行的应用程序。CP 系统的结构使得只有一个主节点可以接收给定副本集中的所有写入请求。辅助节点复制主节点中的数据，因此如果主节点发生故障，辅助节点可以替代。

AP数据库

AP 数据库支持可用性（A）和分区容错性（P），但不支持一致性（C）。如果分区更新，所有节点都可用，但它们并非全部更新。例如，如果用户尝试从坏节点访问数据，他们将不会收到最新版本的数据。当分区最终解决时，大多数 AP 数据库将同步节点以确保它们之间的一致性。Apache Cassandra 是 AP 数据库的一个示例。这是一个没有主节点的 NoSQL 数据库，这意味着所有节点都保持可用。Cassandra 允许最终的一致性，因为用户可以在分区解决后立即重新同步他们的数据。

CAP 定理和微服务

微服务被定义为可以独立开发、部署和维护的松耦合服务。它们包括自己的堆栈、数据库和数据库模型，并通过网络相互通信。微服务在混合云和多云环境中变得特别流行，并且它们也广泛用于本地数据中心。如果您想创建一个微服务应用程序，您可以使用 CAP 定理来帮助您确定最适合您需求的数据库。

总结和后续步骤

恭喜你迈出了 CAP 定理和分布式系统的第一步！分布式系统允许更低的延迟、可扩展性、更高的互连性等等。CAP 定理在分布式系统和整个系统设计中非常重要。虽然我们今天介绍了很多内容，但关于分布式系统还有很多东西需要学习。接下来要学习的一些推荐主题包括：

• 分布式数据存储

• 分布式系统算法

• 原子性

快乐学习！

参考资料：

https://www.educative.io/blog/what-is-cap-theorem

https://www.educative.io/blog/components-of-system-design?eid=5082902844932096

https://medium.com/educative/system-analysis-vs-system-design-what-every-dev-needs-to-know-8ff3fedcf1f