雲端運算解釋：你必須知道的 11 個架構概念（4K 大師班）。

本影片涵蓋的內容

• - 架構牆與主藍圖
• - 01. 垂直與水平擴展
• - 02. 負載平衡架構（L4 與 L7 及健康檢查）
• - 03. 自動擴展與彈性
• - 04. 無伺服器（FaaS 與 Firecracker MicroVMs）

翻譯的文字記錄

從英文原文旁白翻譯。可用的音頻和字幕由 YouTube 控制。

- 架構牆與主藍圖

0:00 每個軟件工程師最終都會面對雲端架構的難題。 你在一台筆記本電腦上構建一個應用程式，將其推送到生產環境， 而當真實用戶到來時，伺服器崩潰， 數據庫連接池耗盡，你的 AWS 賬單看起來像一個電話號碼。 大多數開發者試圖通過記憶三百個不同的 AWS 產品縮寫來解決雲端工程問題。 三百個不同的 AWS 產品縮寫。 但真正的雲端運算不是關於記憶供應商目錄：它是 建立在十一個基本架構原語之上。

0:34 在這個大師班中，我們將逐步探討整個企業藍圖：從 擴展和負載平衡到無伺服器、事件驅動解耦、 儲存層次結構和雲端網絡。 掌握這十一個概念，你就可以在 AWS、 GCP 或 Azure 上設計任何後端。 這是 The Daily Diff，幕後探秘。

- 01. 垂直與水平擴展

0:57 概念一：擴展。 當你的應用程式流量增長時，你有兩種根本不同的方法來處理負載： 垂直擴展或水平擴展。 垂直擴展，或稱向上擴展，意味著升級你現有的機器並增加更多資源： 從四個 CPU 核心升級到三十二個，或者將三十二 GB 的記憶體換成一百二十八 GB。 CPU 核心到三十二個，或者將三十二 gigabytes 的 RAM 換成一百二十八個。 一百二十八。 垂直擴展不需要任何架構變更：你的代碼和數據庫保持完全相同。

1:28 你的代碼和數據庫保持完全相同。 但它會達到一個嚴酷的硬件上限。 世界上沒有一台機器擁有一萬個 CPU 核心， 而且頂級實例帶有指數級的價格溢價。 水平擴展，或稱向外擴展，意味著保持你的伺服器小巧且商品價格， 但在路由器後並行運行多個實例。 如果一個實例崩潰，其餘的節點會吸收流量，並實現零停機時間。 零停機時間。水平擴展的黃金法則是

2:01 無狀態性：你的應用程式伺服器不能在本地磁盤上儲存用戶會話、上傳文件或狀態。 上傳文件或狀態儲存在本地磁盤。 狀態必須儲存在外部數據庫或緩存中， 允許任何節點處理任何用戶請求。

- 02. 負載平衡架構（L4 與 L7 及健康檢查）

2:17 概念二：負載平衡。 水平擴展聽起來很棒，但它立即引入了一個問題：當一萬名用戶訪問你的域名時， 當一萬名用戶訪問你的域名時， 哪個特定的伺服器接收他們的流量？ 負載均衡器充當反向代理，位於公共互聯網和你的私有後端集群之間。 和你的私有後端集群。 它接受傳入的 TCP 或 HTTP 連接，並 將請求分發到你的健康實例。

2:47 負載均衡器在兩個主要的網絡層運作。 第 4 層網絡負載均衡器在傳輸層運作， 根據 IP 地址和端口路由原始 TCP 和 UDP 包， 具有微秒級延遲和每秒數百萬個請求。 第 7 層應用程式負載均衡器檢查 HTTP 協議 本身：讀取 URL 路徑、請求頭、cookie 和 HTTP 方法。 這使得基於路徑的路由成為可能：將斜線 api 請求發送到你的後端集群， 請求發送到你的後端集群，將斜線靜態請求發送到對象存儲。

3:25 對象存儲。關鍵是，負載均衡器執行主動健康檢查。 每隔幾秒，均衡器就會向每個實例上的健康端點發送 ping 請求。 如果一個實例連續拋出三個五百錯誤或 未能響應，它會自動從池中驅逐，而不會丟失任何請求。 不會丟失任何請求。

- 03. 自動擴展與彈性

3:45 概念三：自動擴展。 如果你的網絡應用程式在凌晨三點需要兩台伺服器， 但在中午發佈時需要二十台伺服器，手動點擊雲端控制台中的按鈕， 保證會導致停機和破產。 自動擴展為水平伺服器池帶來動態彈性。 自動擴展組監控性能指標，例如平均 CPU 使用率、 CPU 使用率、網絡 I/O 或隊列積壓深度。 深度。當平均 CPU 達到定義的閾值 — 例如，

4:19 連續三分鐘達到百分之七十 — 自動擴展器會自動啟動新的虛擬機， 啟動新的虛擬機，將其註冊到你的負載均衡器， 並開始路由流量。 同樣重要的是縮減：當流量高峰消退時， 自動擴展器會終止多餘的實例，這樣你就不必為閒置的計算付費。 為了防止抖動 — 伺服器在無休止的循環中快速創建和銷毀 — 雲端架構師會配置 銷毀在無休止的循環中 — 雲端架構師會配置 冷卻期。概念四：無伺服器。

- 04. 無伺服器（FaaS 與 Firecracker MicroVMs）

4:53 多年來，營銷團隊將無伺服器宣傳為在雲端運行的魔法代碼。 在雲端運行。 實際上，無伺服器仍然使用伺服器 — 但當沒有代碼運行時，你不需要擁有、修補或支付它們。 修補，或支付它們，當沒有代碼運行時。 使用像 AWS Lambda 或 Google Cloud Functions 這樣的函數即服務 (Function-as-a-Service)， 你編寫一個獨立的處理程序函數。 當發生 HTTP 請求、S3 文件上傳或數據庫更改時， 雲端運行時會在五毫秒內啟動一個臨時的微虛擬機，例如 Firecracker。

5:23 微虛擬機，例如 Firecracker，在五毫秒內。 你的代碼執行，返回響應，然後關閉。 如果三個月內沒有人訪問你的網站，你的計算賬單正好是 零美元零美分。 如果一百萬用戶同時訪問，提供商會啟動一百萬個並發的微虛擬機。 微虛擬機。工程權衡是真實存在的：啟動新運行時時的冷啟動延遲， 在 Lambda 上硬性的十五分鐘執行限制，以及嚴格的無狀態性。 在 Lambda 上，以及嚴格的無狀態性。

5:55 無伺服器對於事件管道和零星 API 來說是無敵的， 但對於持久的 WebSockets 或數小時的訓練運行來說則很糟糕。

- 05. 事件驅動架構（EDA 與解耦）

6:05 概念五：事件驅動架構，或 EDA。 在傳統架構中，服務是同步通信的。 你的結賬服務調用支付，支付調用庫存， 庫存調用欺詐，欺詐調用電子郵件。 這就產生了同步的級聯厄運。 如果第三方電子郵件提供商遇到網絡故障並需要十秒鐘才能響應， 秒鐘才能響應，你的客戶的整個結賬請求就會超時並出現錯誤。 錯誤。在事件驅動架構中，服務是完全解耦的。

6:37 當客戶點擊購買時，結賬服務不會調用下游服務。 服務。它只是向中央事件總線（例如 Amazon EventBridge 或 SNS 主題）發佈一個名為 OrderPlaced 的事件。 事件總線，例如 Amazon EventBridge 或一個 SNS 主題。 結賬在五十毫秒內完成。 支付、庫存扣減和電子郵件收據的下游工作器 獨立地從他們各自的專用 SQS 隊列中拉取消息。 如果電子郵件服務停機一小時，消息會安全地 緩衝在隊列中，沒有任何訂單遺失。

- 06. 容器編排（Docker 與 Kubernetes）

7:13 概念六：容器編排。 Docker 解決了打包問題：它將你的應用程式代碼、 系統庫、配置和運行時包裝成一個不可變的 映像，可在你的 MacBook 和雲端上完全相同地運行。 但打包容器很容易。 在五十台物理虛擬機上運行五百個容器是 工程崩潰的地方。 這就是為什麼像 Kubernetes 和 AWS ECS 這樣的容器編排器會存在的原因。

7:41 存在。編排器提供一個控制平面：一個 API 伺服器、 一個 etcd 狀態存儲和一個智能調度器。 你聲明你想要的狀態：我需要十個身份驗證服務副本，每個具有兩 GB 記憶體。 服務，每個具有兩 gigabytes 的 RAM。 調度器檢查集群，將 Pod 放置在具有空閒記憶體的節點上，配置內部網絡，並持續協調現實。 配置內部網絡，並持續協調現實。 如果節點發生硬件故障，Kubernetes 會檢測到 丟失並立即將所有 displaced Pod 重新調度到健康的節點上。

- 07. 四大雲端儲存支柱（S3、EBS、數據庫與 Redis）

8:16 健康的節點。概念七：雲端儲存層次結構。 初學者常將雲端儲存視為一個單一的桶，您只需將檔案丟入其中。 在生產架構中，儲存根據訪問模式和延遲分為四個不同的支柱。 支柱，根據訪問模式和延遲。 首先是物件儲存，例如 Amazon S3 或 Google Cloud Storage。 儲存。您使用簡單的 PUT 和 GET 調用，通過 HTTP REST API 訪問檔案。 簡單的 PUT 和 GET 調用。 它提供無限的水平容量，每月每 GB 兩美分，

8:49 使其成為視頻、用戶上傳、日誌和備份的理想選擇。 其次是塊儲存，例如 Amazon EBS。 這些是通過高速互連直接掛載到特定虛擬機的虛擬硬碟。 通過高速互連。 它們格式化為標準文件系統，例如 ext4， 支持數據庫引擎所需的快速隨機讀寫訪問。 引擎。第三是託管數據庫：像 RDS 上的 PostgreSQL 這樣的關係型引擎，提供 ACID 事務和複雜的連接， 在 RDS 上提供 ACID 事務和複雜的連接，

9:21 以及像 DynamoDB 這樣的 NoSQL 引擎，以大規模提供個位數毫秒級延遲。 毫秒級延遲，在大規模下。 第四是像 Redis 這樣的記憶體內緩存。 從 RAM 讀取數據需要微秒而不是毫秒。 緩存位於數據庫前面，保護它免受重複讀取流量的影響，並管理易失性用戶會話令牌。 並管理易失性用戶會話令牌。

- 08. 高可用性與 Nines（多可用區故障轉移）

9:44 概念八：高可用性，或 HA。 可用性回答了一個問題：你的應用程式在什麼百分比的時間內是可運行的，並且用戶可以訪問？ 應用程式可運作並可供用戶訪問的時間百分比？ 在企業合同中，可用性以「九」來衡量。 兩個九，即百分之九十九的可用性，每年允許超過三天半的停機時間。 半天停機時間。 四個九將允許的停機時間縮短到五十二分鐘， 而五個九每年僅允許總共五分鐘的停機時間。

10:15 每年。為實現高可用性，您必須消除跨故障域的單點故障。 跨故障域。 在雲端，這意味著跨多個可用區部署。 一個可用區並非一個單一機架：它是一個或多個獨立的物理數據中心，相距數英里， 物理數據中心，相隔數英里，擁有獨立的電源和冷卻系統。 通過在區域 A 和區域 B 中運行活動實例並進行同步數據庫複製， 閃電擊中或光纖切斷導致整個物理設施關閉，將會導致自動故障轉移。 擊中或光纖切斷導致整個物理設施關閉，將導致自動故障轉移

10:50 在三十秒內，無需人手介入。

- 09. 持久性與可用性（為何 11 個 9 並非正常運行時間）

10:53 概念九：耐用性與可用性。 這是雲端架構面試中最常見的概念陷阱 工程師經常互換使用這兩個詞， 但它們衡量的是完全不同的屬性。 可用性衡量正常運行時間：我能否立即發出 API 調用來讀取或寫入我的 數據？ 耐用性衡量保存性：我的數據在十年內是否能在沒有永久性 位元腐爛、損壞或破壞的情況下倖存下來？

11:24 看看 Amazon S3 Standard。 其服務級別協議提供百分之九十九點九的 可用性，這表示每個月大約有四十三分鐘的停機時間， 期間 API 請求可能會返回五百錯誤。 但 S3 承諾達到十一個九的耐用性：百分之九十九點九九九九九九九 九九九。 九九。 如果您在 S3 中儲存一千萬個文件，統計上預期每隔一萬年會丟失一個

11:56 文件。 S3 透過擦除編碼對象並在至少三個地理位置分隔的數據設施中複製數據塊來實現這一點。 至少三個地理上分離的數據設施。 在一次重大的區域網絡中斷期間，S3 可能會暫時 不可用，但您的數據永遠不會被破壞。

- 10. 基礎設施即代碼（Terraform 與控制台漂移）

12:14 概念十：基礎設施即代碼，或稱 IaC。 在雲端運算的早期，工程師登入 AWS 網絡管理控制台，手動點擊創建虛擬機器、 配置子網絡並連接安全組。 業界稱此為 ClickOps，在生產環境中，這絕對是個 災難。手動控制台更改沒有稽核追蹤，沒有回溯 機制，並且不可避免地導致暫存和生產環境之間的配置漂移。 使用基礎設施即代碼工具，例如 Terraform、

12:48 例如 Terraform， OpenTofu、Pulumi 或 AWS CDK，您可以將整個 雲端架構定義在儲存在 Git 中的聲明性配置文件中。 對開放端口或數據庫副本的每次更改都經過 拉取請求和同行審查。 執行 terraform plan 可在任何更改發生之前預覽確切的 API 差異， 而啟動一個與您生產堆棧完全相同的副本 需要四分鐘而不是四週。

- 11. 雲端網絡（VPC、子網、NAT 與安全組）

13:20 概念十一：雲端網絡和虛擬私有雲。 當您將伺服器部署到雲端時，它們並非暴露在原始的 公共網絡上。它們存在於一個稱為 VPC 的 軟件定義的隔離邊界內。 在您的 VPC 內部，您會分配一個私有 IP 地址空間，例如 十點零點零點零斜線十六，並將其劃分為公共和私有子網絡。 劃分為公共和私有子網絡。 公共子網絡直接路由到互聯網閘道。

13:51 它容納面向公眾的資產，例如您的應用程式負載平衡器和 NAT 閘道。這是您的網絡中唯一擁有公共 IP 地址的部分。您的應用程式伺服器和生產數據庫嚴格位於 私有子網絡中，沒有公共 IP 和來自互聯網的零入站路由。 當您的後端伺服器需要下載安全更新時，它們的出站流量會經由 公共子網絡中的 NAT 閘道路由。 每個實例周圍都有安全組：有狀態的虛擬防火牆， 它們強制執行最小權限原則。

- 12. 完整的企業藍圖與結論

14:28 您的數據庫安全組僅接受來自您的應用程式伺服器安全組的 5432 端口連接，使得外部入侵在數學上不可能發生。 使得外部滲透在數學上不可能。 當您放大觀察時，這十一個原語連接成一個有凝聚力的系統。 您的 DNS 路由到公共子網絡中的負載平衡器， 自動擴展組處理跨多個可用區的流量高峰， 事件總線解耦後端工作器，而您的整個堆棧則使用基礎設施即代碼從 Git 部署。 使用基礎設施即代碼從 Git 部署。

15:02 今天的精通課程判決：SHIP IT。 停止背誦數百個雲端行銷縮寫詞。 掌握這十一種架構模式，解耦您的狀態， 並構建不會失敗的系統。 告訴我您在剛開始構建時，哪個雲端概念給您帶來了最大的困擾 請在評論中告訴我。 如欲獲取完整的架構速查表， 請訂閱 the daily diff dot dev 的電子報，

15:28 連結在下方。這就是今天的差異。 我是 Axrisi 的 Niko。 負責地合併。

來源

1. AWS Well-Architected Framework (Reliability & Performance Pillars)aws.amazon.com
2. Kubernetes Architecture & Control Plane Conceptskubernetes.io
3. Martin Fowler: What is Event-Driven Architecture?martinfowler.com
4. Amazon S3 Data Durability & Availability Technical Whitepaperaws.amazon.com
5. HashiCorp: Declarative Infrastructure as Code with Terraformwww.terraform.io