雲端運算揭密：您必須知道的 11 個架構概念 (4K 大師班)。

本影片重點

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

翻譯文字稿

譯自英文原版旁白。可用的音訊和字幕由 YouTube 控制。

- 架構之牆與主藍圖

0:00 每個軟體工程師最終都會面臨雲端架構的挑戰。 您在筆記型電腦上建置應用程式，將其推送到生產環境， 而當真實用戶湧入時，伺服器卻崩潰了， 資料庫連線耗盡，而您的 AWS 帳單看起來像一組電話號碼。 大多數開發人員試圖透過記憶三百個不同的 AWS 產品縮寫來解決雲端工程問題。 三百個不同的 AWS 產品縮寫。 但真正的雲端運算並不是關於記憶供應商目錄：它是 建立在 11 個基本架構原語之上。

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

- 01. 垂直擴展 vs. 水平擴展

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

1:28 和資料庫保持完全相同。 但它會撞上一個嚴酷的硬體天花板。 世界上沒有任何一台機器擁有萬個 CPU 核心， 而且頂級實例的價格呈指數級增長。 水平擴展，或向外擴展，意味著保持您的伺服器小巧且商品化定價，但在路由器後方並行運行多個實例。 小巧且商品化定價，但在路由器後方並行運行多個實例。 如果一個實例崩潰，其餘節點將在零停機時間內吸收流量。 水平擴展的黃金法則是無狀態：您的應用程式伺服器不能在其本機磁碟上儲存用戶會話、上傳檔案或狀態。

2:01 無狀態：您的應用程式伺服器不能儲存用戶會話、 上傳檔案或狀態在其本機磁碟上。 狀態必須存在於外部資料庫或快取中， 允許任何節點處理任何用戶請求。

- 02. 負載平衡架構 (L4 vs. L7 & 健康檢查)

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

2:47 負載平衡器在兩個主要網路層運作。 Layer 4 網路負載平衡器在傳輸層運作，根據 IP 位址和連接埠路由原始 TCP 和 UDP 封包，具有微秒級延遲和每秒數百萬個請求。 根據 IP 位址和連接埠路由原始 TCP 和 UDP 封包， 具有微秒級延遲和每秒數百萬個請求。 Layer 7 應用程式負載平衡器檢查 HTTP 協定本身：讀取 URL 路徑、請求標頭、Cookie 和 HTTP 方法。 本身：讀取 URL 路徑、請求標頭、Cookie 和 HTTP 方法。這實現了基於路徑的路由：將斜線 api 請求發送到您的後端叢集，將斜線靜態請求發送到物件儲存。 請求發送到您的後端叢集，將斜線靜態請求發送到一個

3:25 物件儲存。關鍵的是，負載平衡器會執行主動健康檢查。 每隔幾秒，平衡器會向每個實例上的健康端點發送 Ping 請求。 如果一個實例連續拋出三個 500 錯誤或未回應，它將自動從池中逐出，而不會丟失任何請求。 未回應，它將自動從池中逐出，而不會丟失任何請求。 零個丟失的請求。

- 03. 自動擴展與彈性

3:45 概念三：自動擴展。 如果您的網路應用程式在凌晨三點需要兩台伺服器，但在中午啟動時需要二十台伺服器，手動點擊雲端控制台中的按鈕保證會導致停機和破產。 但在中午啟動時需要二十台伺服器，手動點擊雲端控制台中的按鈕 雲端控制台是一個導致停機和破產的保證途徑。 自動擴展為水平伺服器池帶來動態彈性。 自動擴展群組監控平均 CPU 利用率、網路 I-O 或佇列積壓深度等性能指標。 CPU 利用率、網路 I-O 或佇列積壓 深度。當平均 CPU 達到定義的閾值時——例如，連續三分鐘達到百分之七十——自動擴展器會自動啟動新的虛擬機器，將它們註冊到您的負載平衡器，並開始路由流量。

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

- 04. 無伺服器 (FaaS & Firecracker MicroVMs)

4:53 多年來，行銷團隊將無伺服器宣傳為在雲端中運行的魔法程式碼。 運行在天空中。 實際上，無伺服器仍然使用伺服器——但當沒有程式碼運行時，您無需擁有、修補或支付它們。 修補，或支付它們，當沒有程式碼運行時。 使用 AWS Lambda 或 Google Cloud Functions 等函數即服務， 您編寫一個獨立的處理函數。 當 HTTP 請求、S3 檔案上傳或資料庫變更發生時，雲端執行環境會在五毫秒內啟動一個短暫的 micro-virtual-machine，例如 Firecracker。 發生時，雲端執行環境會啟動一個短暫的

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

5:55 無伺服器對於事件管道和零星的 API 來說是無可匹敵的， 但對於持久性 WebSocket 或多小時的訓練運行來說卻很差。

- 05. 事件驅動架構 (EDA & 解耦)

6:05 概念五：事件驅動架構，或 EDA。 在傳統架構中，服務以同步方式進行通訊。 您的結帳服務呼叫支付，支付呼叫庫存， 庫存呼叫詐騙，詐騙呼叫電子郵件。 這產生了同步的毀滅性連鎖反應。 如果第三方電子郵件供應商遇到網路問題並花費十秒鐘回應，您的客戶的整個結帳請求將因錯誤而逾時。 秒回應，您的客戶的整個結帳請求將因 錯誤而逾時。在事件驅動架構中，服務是完全解耦的。

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

- 06. 容器編排 (Docker & Kubernetes)

7:13 概念六：容器編排。 Docker 解決了打包問題：它將您的應用程式程式碼、系統函式庫、組態和執行環境包裝成一個不可變的映像檔，在您的 MacBook 和雲端中執行方式完全相同。 系統函式庫、組態和執行環境包裝成一個不可變的 映像檔，在您的 MacBook 和雲端中執行方式完全相同。 但打包容器很容易。 在五十台實體虛擬機器上運行五百個容器才是工程的瓶頸。 工程崩潰了。 這就是為什麼存在 Kubernetes 和 AWS ECS 等容器編排器。

7:41 存在。編排器提供一個控制平面：一個 API 伺服器、一個 etcd 狀態儲存和一個智慧排程器。 一個 etcd 狀態儲存和一個智慧排程器。 您聲明您所需的狀態：我需要十個 auth 服務副本，每個具有兩 GB 的 RAM。 服務，每個具有兩 GB 的 RAM。 排程器檢查叢集，將 Pod 放置在具有空閒記憶體的節點上，配置內部網路，並持續協調實際情況。 配置內部網路，並持續協調實際情況。 如果一個節點發生硬體故障，Kubernetes 會檢測到 丟失並立即將所有被移位的 Pod 重新排程到

- 07. 四大雲端儲存支柱 (S3, EBS, DBs & Redis)

8:16 健康的節點上。概念七：雲端儲存層級。 初學者通常將雲端儲存視為一個用於傾倒檔案的單一儲存桶。 檔案。在生產架構中，儲存根據存取模式和延遲分為四個不同的支柱。 支柱，根據存取模式和延遲。 首先是物件儲存，例如 Amazon S3 或 Google Cloud 儲存。您使用簡單的 PUT 和 GET 呼叫，透過 HTTP REST API 存取檔案。 簡單的 PUT 和 GET 呼叫。 它提供無限的水平容量，每月每 GB 兩美分，非常適合影片、使用者上傳、日誌和備份。

8:49 使其成為影片、使用者上傳、日誌和備份的理想選擇。 其次是區塊儲存，例如 Amazon EBS。 這些是透過高速互連直接安裝到特定虛擬機器的虛擬硬碟。 透過高速互連。 它們格式化為標準檔案系統，例如 ext4，支援資料庫引擎所需的快速隨機讀寫存取。 支援資料庫所需的快速隨機讀寫存取 引擎。第三是託管資料庫：RDS 上的 PostgreSQL 等關聯式引擎提供 ACID 事務和複雜聯結，以及 DynamoDB 等 NoSQL 引擎以大規模提供個位數毫秒延遲。 在 RDS 上提供 ACID 事務和複雜聯結，

9:21 和 DynamoDB 等 NoSQL 引擎提供個位數 毫秒延遲，規模龐大。 第四是記憶體快取，例如 Redis。 從 RAM 讀取資料只需微秒而不是毫秒。 快取位於您的資料庫前方，保護它免受重複讀取流量的影響，並管理易失性使用者會話令牌。 並管理易失性使用者會話令牌。

- 08. 高可用性與 Nines (多可用區故障轉移)

9:44 概念八：高可用性，或 HA。 可用性回答一個問題：您的應用程式在多大比例的時間內可以運行並被使用者訪問？ 應用程式可運行並被使用者訪問？ 在企業合約中，可用性以「Nines」衡量。 兩個 Nines，或百分之九十九的可用性，每年允許超過三天半的停機時間。 半天的停機時間。 四個 Nines 將允許的停機時間降至五十二分鐘， 而五個 Nines 每年總停機時間僅允許五分鐘。

10:15 年。為了實現高可用性，您必須消除跨故障域的單點故障。 跨故障域。 在雲端中，這意味著部署到多個可用區。 一個可用區不是單一機架：它是一個或多個相距數英里且具有獨立電源和冷卻的不同實體資料中心。 物理資料中心相距數英里，具有獨立的電源和冷卻。 透過在區域 A 和區域 B 中運行活動實例並進行同步資料庫複製，雷擊或光纖中斷導致整個實體設施停機，將導致自動故障轉移。 資料庫複製，雷擊或光纖中斷導致 整個實體設施停機將導致自動故障轉移

10:50 在三十秒內零人為干預。

- 09. 持久性 vs. 可用性 (為何 11 個 9 並非正常運行時間)

10:53 概念九：耐用性與可用性。 這是雲端架構訪談中最常見的概念陷阱。 工程師經常互換使用這些詞， 但它們測量的是完全不同的屬性。 可用性衡量正常運行時間：我現在可以發出 API 呼叫來讀取或寫入我的資料嗎？ 資料。 耐用性衡量保存性：我的資料在十年內是否能在沒有永久位元腐蝕、損壞或破壞的情況下存活？ 位元腐蝕、損壞或破壞。

11:24 看看 Amazon S3 標準版。 其服務水準協議提供百分之九十九點九的可用性， 這允許每月大約四十三分鐘的停機時間， 在此期間，API 請求可能會返回五百個錯誤。 但 S3 承諾的耐用性是十一個九： 百分之九十九點九九九九九九九九九。 九九％。 如果你在 S3 中儲存一千萬個檔案，統計上你可以預期平均每萬年丟失一個檔案。

11:56 平均每萬年損失一個檔案。 S3 透過對物件進行擦除編碼並將區塊複製到至少三個地理位置分離的資料設施來實現這一點。 至少三個地理位置分離的資料設施。 在一次重大的區域網路中斷期間，S3 可能會暫時不可用， 但你的資料永遠不會被銷毀。

- 10. 基礎設施即程式碼 (Terraform vs. Console Drift)

12:14 概念十：基礎設施即程式碼，或稱 IaC。 在雲端運算早期，工程師登入 AWS 網路管理主控台， 並手動點擊以創建虛擬機、配置子網路和附加安全群組。 虛擬機、配置子網路和附加安全群組。 業界稱之為 ClickOps，在生產環境中，它絕對是一場災難。 手動主控台更改沒有稽核軌跡，沒有回滾機制， 並且不可避免地導致暫存和生產環境之間的配置漂移。 生產環境。有了基礎設施

12:48 程式碼工具，如 Terraform、 OpenTofu、Pulumi 或 AWS CDK，你可以在 Git 中儲存的宣告式配置檔案中定義你的整個雲端架構。 所有雲端架構都在儲存在 Git 的宣告式配置檔案中定義。 對開放連接埠或資料庫副本的每次更改都必須經過拉取請求和同行審查。 拉取請求和同行審查。 執行 terraform plan 會在任何東西被碰觸之前預覽確切的 API 差異， 並且啟動與你生產堆疊完全相同的副本只需四分鐘而不是四週。 堆疊只需要四分鐘，而不是四週。

- 11. 雲端網路 (VPC, 子網, NAT & 安全群組)

13:20 概念十一：雲端網路和虛擬私人雲端。 當你將伺服器部署到雲端時，它們不會直接暴露在原始的公共網路上。 它們生活在一個稱為 VPC 的軟體定義的隔離邊界內。 它們生活在一個稱為 VPC 的軟體定義的隔離邊界內。 在你的 VPC 內部，你分配了一個私有 IP 位址空間， 例如 10.0.0.0/16，並將其劃分為公共和私人子網路。 劃分為公共和私人子網路。 公共子網路具有到網際網路閘道的直接路由。

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

- 12. 完整的企業藍圖與評語

14:28 你的資料庫安全群組僅接受來自你的應用程式伺服器安全群組的 5432 埠連線， 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