← Courses Catalogue

#在 AWS 上设计支持百万级到千万级用户的系统

注释：为了避免重复，这篇文章的链接直接关联到 系统设计主题 的相关章节。为一讨论要点、折中方案和可选方案做参考。

#第 1 步：用例和约束概要

收集需求并调查问题。 通过提问清晰用例和约束。 讨论假设。

如果没有面试官提出明确的问题，我们将自己定义一些用例和约束条件。

#用例

解决这个问题是一个循序渐进的过程：1) 基准/负载 测试， 2) 瓶颈 概述， 3) 当评估可选和折中方案时定位瓶颈，4) 重复，这是向可扩展的设计发展基础设计的好模式。

除非你有 AWS 的背景或者正在申请需要 AWS 知识的相关职位，否则不要求了解 AWS 的相关细节。并且，这个练习中讨论的许多原则可以更广泛地应用于AWS生态系统之外。

#我们就处理以下用例讨论这一问题

#约束和假设

#状态假设

#计算使用

向你的面试官厘清你是否应该做粗略的使用计算

便捷的转换指南：

#第 2 步：创建高级设计方案

用所有重要组件概述高水平设计

Imgur

#第 3 步：设计核心组件

深入每个核心组件的细节。

#用例：用户进行读写请求

#目标

#以单台服务器开始

运用 纵向扩展：

折中方案, 可选方案, 和其他细节:

#自 SQL 开始，但认真考虑 NoSQL

约束条件假设需要关系型数据。我们可以开始时在单台服务器上使用 MySQL 数据库。

折中方案, 可选方案, 和其他细节:

#分配公共静态 IP

#使用 DNS 服务

添加 DNS 服务，比如 Route 53（Amazon Route 53 - 译者注），将域映射到实例的公共 IP 中。

折中方案, 可选方案, 和其他细节:

#安全的 Web 服务器

折中方案, 可选方案, 和其他细节:

#第 4 步：扩展设计

在给定约束条件下，定义和确认瓶颈。

#用户+

Imgur

#假设

我们的用户数量开始上升，并且单台服务器的负载上升。基准/负载测试 和 分析 指出 MySQL 数据库 占用越来越多的内存和 CPU 资源，同时用户数据将填满硬盘空间。

目前，我们尚能在纵向扩展时解决这些问题。不幸的是，解决这些问题的代价变得相当昂贵，并且原来的系统并不能允许在 MySQL 数据库 和 Web 服务器 的基础上进行独立扩展。

#目标

#独立保存静态内容

#迁移 MySQL 数据库到独立机器上

#系统安全

折中方案, 可选方案, 和其他细节:

#用户+++

Imgur

#假设

我们的 基准/负载测试 和 性能测试 显示，在高峰时段，我们的单一 Web服务器 存在瓶颈，导致响应缓慢，在某些情况下还会宕机。随着服务的成熟，我们也希望朝着更高的可用性和冗余发展。

#目标

折中方案, 可选方案, 和其他细节:

#用户+++

Imgur

注意： 内部负载均衡 不显示以减少混乱

#假设

我们的 性能/负载测试 和 性能测试 显示我们读操作频繁（100:1 的读写比率），并且数据库在高读请求时表现很糟糕。

#目标

折中方案, 可选方案, 和其他细节:

#添加 MySQL 读取副本

折中方案, 可选方案, 和其他细节:

#用户++++

Imgur

#假设

基准/负载测试 和 分析 显示，在美国，正常工作时间存在流量峰值，当用户离开办公室时，流量骤降。我们认为，可以通过真实负载自动转换服务器数量来降低成本。我们是一家小商店，所以我们希望 DevOps 尽量自动化地进行 自动伸缩 和通用操作。

#目标

#添加自动扩展

#用户+++++

Imgur

注释： 自动伸缩 组不显示以减少混乱

#假设

当服务继续向着限制条件概述的方向发展，我们反复地运行 基准/负载测试 和 分析 来进一步发现和定位新的瓶颈。

#目标

由于问题的约束，我们将继续提出扩展性的问题：

SQL 扩展模型包括：

为了进一步处理高读和写请求，我们还应该考虑将适当的数据移动到一个 NoSQL数据库 ，例如 DynamoDB。

我们可以进一步分离我们的 应用服务器 以允许独立扩展。不需要实时完成的批处理任务和计算可以通过 Queues 和 Workers 异步完成：

折中方案, 可选方案, 和其他细节:

#额外的话题

根据问题的范围和剩余时间，还需要深入讨论其他问题。

#SQL 扩展模式

#NoSQL

#缓存

#异步性和微服务

#沟通

#安全性

参考 安全章节

#延迟数字指标

查阅 每个程序员必懂的延迟数字

#正在进行