云计算解释：你必须了解的11个架构概念（4K大师班）。
大多数软件工程师试图通过记忆AWS、GCP和Azure的数百个供应商产品缩写来学习云架构。
大多数软件工程师试图通过记忆AWS、GCP和Azure的数百个供应商产品缩写来学习云架构。但真实的云工程是建立在十一个基本的架构原语之上的。在这个4K重制大师班中，Niko分解了完整的企业蓝图：从垂直扩展与水平扩展、七层负载均衡到动态自动扩展、无服务器微虚拟机执行、异步事件驱动解耦、容器编排、四支柱存储层次结构、高可用性与11个9的持久性之间的关键区别、声明式基础设施即代码以及虚拟私有云网络。掌握这十一个概念，你就能在生产环境中构建任何后端。判决：SHIP IT。
本视频涵盖的内容
- - 架构之墙与主蓝图
- - 01. 垂直扩展 vs. 水平扩展
- - 02. 负载均衡架构（L4 vs. L7 & 健康检查）
- - 03. 自动扩展与弹性
- - 04. 无服务器（FaaS & Firecracker MicroVMs）
翻译的文字记录
译自英文原版旁白。可用音频和字幕由 YouTube 控制。
- 架构之墙与主蓝图
0:00 每个软件工程师最终都会面对云架构的壁垒。 你在笔记本电脑上构建应用程序，推送到生产环境， 而当真实用户到来时，服务器崩溃， 数据库连接池耗尽，你的AWS账单看起来像一个电话 号码。大多数开发人员试图通过记忆 三百个不同的AWS产品缩写来解决云工程问题。 但真实的云计算不是关于记忆供应商目录：它 是建立在十一个基本的架构原语之上的。
0:34 在这个大师班中，我们将详细介绍整个企业蓝图：从 扩展和负载均衡到无服务器、事件驱动解耦， 存储层次结构和云网络。 掌握这十一个概念，你就可以在AWS、 GCP或Azure上设计任何后端。 这是The Daily Diff，幕后揭秘。
- 01. 垂直扩展 vs. 水平扩展
0:57 概念一：扩展。 当你的应用程序流量增长时，你有两种根本 不同的方式来处理负载：垂直扩展或水平 扩展。垂直扩展，即向上扩展，意味着使用你 现有的机器并增加更多资源：从四个 CPU核心升级到三十二个，或将三十二千兆字节的内存换成 一百二十八千兆字节。 垂直扩展不需要任何架构更改：你的代码
1:28 和数据库保持完全相同。 但它会达到残酷的硬件上限。 世界上没有一台机器拥有一万个CPU核心， 顶级实例的价格溢价呈指数级增长。 水平扩展，即向外扩展，意味着保持你的服务器 小型且商品化定价，但在路由器后面并行运行多个实例。 如果一个实例崩溃，其余节点会吸收流量， 零停机。水平扩展的黄金法则是
2:01 无状态：你的应用程序服务器不能在本地磁盘上存储用户会话、 上传文件或状态。 状态必须存在于外部数据库或缓存中， 允许任何节点处理任何用户请求。
- 02. 负载均衡架构（L4 vs. L7 & 健康检查）
2:17 概念二：负载均衡。 水平扩展听起来很棒，但它立即引入了一个 问题：当一万个用户访问你的域名时， 具体是哪台服务器接收他们的流量？ 负载均衡器充当反向代理，位于公共互联网 和你的私有后端集群之间。 它接受传入的TCP或HTTP连接，并 将请求分发到健康的实例上。
2:47 负载均衡器在两个主要网络层运行。 四层网络负载均衡器在传输层运行， 根据IP地址和端口路由原始TCP和UDP数据包， 具有微秒级延迟和每秒数百万次请求。 七层应用负载均衡器检查HTTP协议 本身：读取URL路径、请求头、Cookie和HTTP 方法。这实现了基于路径的路由：将斜杠-API 请求发送到你的后端集群，将斜杠-静态请求发送到
3:25 对象存储。重要的是，负载均衡器执行主动健康 检查。每隔几秒，均衡器会ping每个 实例上的健康端点。如果一个实例抛出三个连续的五百错误或 未能响应，它将自动从池中移除， 零请求丢失。
- 03. 自动扩展与弹性
3:45 概念三：自动扩展。 如果你的Web应用程序在凌晨三点需要两台服务器， 但在中午发布时需要二十台服务器，手动点击 云控制台中的按钮是导致停机和破产的必然途径。 自动扩展为水平服务器池带来了动态弹性。 自动扩展组监控平均CPU利用率、网络I/O或队列积压 深度等性能指标。 当平均CPU超过定义的阈值——比如，
4:19 连续三分钟达到百分之七十——自动扩展器会自动 启动新的虚拟机，将其注册到你的负载均衡器， 并开始路由流量。 同样重要的是缩减：当流量高峰消退时， 自动扩展器会终止多余的实例，这样你就不会为 空闲计算付费。为了防止抖动——即服务器在无休止的 循环中快速创建和销毁——云架构师会配置 冷却期。概念四：无服务器。
- 04. 无服务器（FaaS & Firecracker MicroVMs）
4:53 多年来，营销团队将无服务器宣传为在 云端运行的神奇代码。 实际上，无服务器仍然使用服务器——但当没有代码运行时，你无需 拥有、修补或付费。 使用AWS Lambda或Google Cloud Functions等函数即服务， 你编写一个独立的处理器函数。 当发生HTTP请求、S3文件上传或数据库更改时， 云运行时会在五毫秒内启动一个临时
5:23 微虚拟机，例如Firecracker。 你的代码执行，返回响应，然后关闭。 如果三个月内没有人访问你的网站，你的计算账单正好是 零美元零美分。 如果一百万用户同时访问它，提供商会启动一百万个 并发微虚拟机。工程权衡是真实的：启动新运行时时的冷启动 延迟，Lambda上严格的十五分钟执行限制，以及严格的无状态性。 严格的无状态性。
5:55 无服务器对于事件管道和零星API来说是无与伦比的， 但对于持久性WebSockets或多小时的训练运行来说则很差。
- 05. 事件驱动架构（EDA & 解耦）
6:05 概念五：事件驱动架构，或EDA。 在传统架构中，服务是同步通信的。 你的结账服务调用支付，支付调用库存， 库存调用欺诈，欺诈调用电子邮件。 这产生了同步的毁灭级联。 如果第三方电子邮件提供商遇到网络故障并需要十 秒才能响应，你的客户的整个结账请求将超时并出现 错误。在事件驱动架构中，服务是完全解耦的。
6:37 当客户点击购买时，结账服务不会调用下游 服务。它只是向中央 事件总线（如Amazon EventBridge或SNS主题）发布一个名为OrderPlaced的事件。 结账在五十毫秒内完成。 用于支付、库存扣减和电子邮件收据的下游工作者 独立地从他们自己的专用SQS队列中拉取消息。 如果电子邮件服务宕机一小时，消息会安全地 缓冲在队列中，而不会丢失任何订单。
- 06. 容器编排（Docker & Kubernetes）
7:13 概念六：容器编排。 Docker解决了打包问题：它将你的应用程序代码、 系统库、配置和运行时封装成一个不可变 镜像，该镜像在你的MacBook和云端运行完全相同。 但打包容器很容易。 在五十台物理虚拟机上运行五百个容器才是 工程崩溃的地方。 这就是为什么存在Kubernetes和AWS ECS等容器编排器。
7:41 编排器提供了一个控制平面：一个API服务器、 一个etcd状态存储和一个智能调度器。 你声明你的期望状态：我需要十个我的认证 服务副本，每个具有两个千兆字节的内存。 调度器检查集群，将pod放置在具有空闲内存的节点上， 配置内部网络，并不断协调现实。 如果一个节点发生硬件故障，Kubernetes会检测到 丢失并立即将所有受影响的pod重新调度到
- 07. 四大云存储支柱（S3, EBS, DBs & Redis）
8:16 健康的节点上。概念七：云存储层次结构。 初学者通常将云存储视为一个你倾倒 文件的单一存储桶。在生产架构中，存储根据访问模式和延迟分为四个不同的 支柱。 首先是对象存储，例如Amazon S3或Google Cloud Storage。你通过HTTP REST API使用 简单的PUT和GET调用访问文件。 它以每月每千兆字节两美分的价格提供无限的水平容量，
8:49 使其成为视频、用户上传、日志和备份的理想选择。 其次是块存储，例如Amazon EBS。 这些是直接通过高速互连安装到特定虚拟机的 虚拟硬盘。 它们格式化为ext4等标准文件系统， 支持数据库引擎所需的快速随机读写访问。 第三是托管数据库：RDS上的PostgreSQL等关系引擎提供ACID事务和复杂连接， RDS上的PostgreSQL等关系引擎提供ACID事务和复杂连接，
9:21 以及DynamoDB等NoSQL引擎在大规模下提供个位数 毫秒级延迟。 第四是Redis等内存缓存。 从RAM读取数据需要微秒而不是毫秒。 缓存位于你的数据库前面，保护它免受重复的读取流量， 并管理易失的用户会话令牌。
- 08. 高可用性与九个九（多可用区故障转移）
9:44 概念八：高可用性，或HA。 可用性回答一个问题：你的应用程序 在多大比例的时间内是可操作且用户可访问的？ 在企业合同中，可用性以“九”来衡量。 两个九，即百分之九十九的可用性，每年允许超过三天半的 停机时间。 四个九将允许的停机时间减少到五十二分钟， 而五个九每年允许的总停机时间仅为五分钟。
10:15 为了实现高可用性，你必须消除 故障域中的单点故障。 在云中，这意味着跨多个可用区进行部署。 可用区不是一个单一的机架：它是一个或多个相距数英里且具有独立电源和冷却的 独立物理数据中心。 通过在A区和B区运行活动实例并进行同步 数据库复制，一次闪电击中或光纤中断导致整个物理设施 宕机，将导致自动故障转移。
10:50 在三十秒内，无需任何人工干预即可完成。
- 09. 持久性 vs. 可用性（为什么11个9不是正常运行时间）
10:53 概念九：耐用性与可用性。 这是云计算架构面试中最常见的概念陷阱 之一。工程师们经常互换使用这些词语， 但它们衡量的是完全不同的属性。 可用性衡量正常运行时间：我能否在此时此刻进行API调用来读取或写入我的 数据？ 耐用性衡量保存性：我的数据能否在十年内不发生永久性 比特衰减、损坏或销毁？
11:24 以 Amazon S3 Standard 为例。 其服务级别协议提供百分之九十九点九的 可用性，这允许每月大约四十三分钟的停机时间，在此期间 API请求可能会返回五百错误。 但S3承诺十一个九的耐用性：百分之九十九点 九九九九九九九 九九。 如果您在S3中存储一千万个文件，从统计学上讲，您可以预期每
11:56 一万年平均会丢失一个文件。 S3通过纠删码对象并在至少三个地理位置分散的数据设施中复制块来实现这一点。 至少三个地理位置分散的数据设施中复制块来实现这一点。 在发生重大区域网络中断时，S3可能会暂时 不可用，但您的数据永远不会被销毁。
- 10. 基础设施即代码（Terraform vs. 控制台漂移）
12:14 概念十：基础设施即代码，或简称IaC。 在云计算早期，工程师登录到AWS web管理控制台，手动点击创建虚拟 机器，配置子网，并附加安全组。 行业称之为ClickOps，在生产环境中，这绝对是一场 灾难。手动控制台更改没有审计跟踪，没有回滚 机制，并且不可避免地导致暂存和生产环境之间的配置漂移。 使用 Terraform 等基础设施即代码工具，
12:48 使用 Terraform 等基础设施即代码工具， OpenTofu、Pulumi 或 AWS CDK，您可以在存储在Git中的声明性配置文件中定义您的整个云架构。 整个云架构在存储在Git中的声明性配置文件中定义。 对开放端口或数据库副本的每次更改都需经过拉取请求和 同行评审。 运行terraform plan会预览确切的API差异，然后 才触及任何内容，并且启动生产堆栈的相同副本 需要四分钟而不是四周。
- 11. 云网络（VPC, 子网, NAT & 安全组）
13:20 概念十一：云网络和虚拟私有云。 当您将服务器部署到云端时，它们不会直接暴露在原始公共互联网上。 它们位于一个名为VPC的软件定义隔离边界内。 它们位于一个名为VPC的软件定义隔离边界内。 在您的VPC内部，您分配一个私有IP地址空间，例如 十点零点零点零斜杠十六，并将其划分为公共和私有子网。 公共和私有子网。 公共子网具有到互联网网关的直接路由。
13:51 它包含面向公众的资产，如您的应用负载均衡器和NAT 网关。它是您网络中唯一拥有公共IP地址的部分。 您的应用服务器和生产数据库严格位于没有公共IP且没有来自互联网入站路由的私有子网中。 没有公共IP且没有来自互联网入站路由的私有子网中。 当您的后端服务器需要下载安全更新时，它们的出站流量会通过公共子网中的NAT网关路由。 它们的出站流量会通过公共 子网中的NAT网关路由。围绕每个实例的是安全组：有状态 虚拟防火墙，强制执行最小特权原则。
- 12. 完整的企业蓝图与判决
14:28 您的数据库安全组仅接受来自您的应用服务器安全组的端口 5432上的连接，使得外部渗透在数学上不可能。 5432上的连接，使得外部渗透在数学上不可能。 当您放大时，这十一个原语连接成一个内聚系统。 您的DNS路由到公共子网中的负载均衡器， 自动伸缩组处理跨多个可用区的流量高峰， 事件总线解耦后端工作者，您的整个堆栈 使用基础设施即代码从Git部署。
15:02 今日大师班判决：SHIP IT。 停止记忆数百个云营销缩写词。 掌握这十一个架构模式，解耦您的状态， 并构建不会失败的系统。 请在评论中告诉我，当您刚开始构建时，哪个云概念让您最头疼。 请在评论中告诉我，当您刚开始构建时，哪个云概念让您最头疼。 要获取完整的架构备忘单， 请订阅thedailydiff.dev上的新闻通讯，
15:28 链接如下。这就是今天的区别。 我是来自Axrisi的Niko。 负责任地合并。
来源
- AWS Well-Architected Framework (Reliability & Performance Pillars)aws.amazon.com
- Kubernetes Architecture & Control Plane Conceptskubernetes.io
- Martin Fowler: What is Event-Driven Architecture?martinfowler.com
- Amazon S3 Data Durability & Availability Technical Whitepaperaws.amazon.com
- HashiCorp: Declarative Infrastructure as Code with Terraformwww.terraform.io
