GCP 架構範本庫

架構圖

使用者
  │
  ▼
Cloud CDN ── Cloud Load Balancing
                  │
                  ▼
            Cloud Run (API)
            ┌─────┴─────┐
            ▼           ▼
      Cloud SQL    Cloud Storage
     (PostgreSQL)  (商品圖片/靜態)

使用服務

Cloud Run 執行電商 API 與後端邏輯，自動擴縮處理流量高峰（如促銷活動）

Cloud SQL (PostgreSQL) 儲存商品目錄、訂單、用戶資料，支援交易一致性（ACID）

Cloud Storage 儲存商品圖片、靜態資源、用戶上傳檔案，99.999999999% 持久性

Cloud CDN 快取靜態內容至全球邊緣節點，降低延遲、加速頁面載入

Cloud Load Balancing 全球 HTTP(S) 負載平衡，SSL 終止、自動故障轉移

設計決策（為什麼這樣選？）

選擇 Cloud Run 而非 GKE：電商流量有明顯波峰波谷（如晚間、促銷），Cloud Run 可縮到零節省成本，且不需管理叢集。

選擇 Cloud SQL 而非 Spanner：中小型電商的資料量和 QPS 不需要 Spanner 的全球分散式能力，Cloud SQL 成本更低且 PostgreSQL 生態豐富。

Cloud CDN + Load Balancing 組合：CDN 快取靜態資源減少 Cloud Run 請求數（省錢），Load Balancing 提供 SSL、DDoS 防護和全球路由。

Cloud Storage 存圖片：比資料庫存 BLOB 便宜 10 倍以上，且可直接透過 CDN 加速分發。

實作步驟（8 步）

建立 Cloud SQL (PostgreSQL) 執行個體，設定 Private IP 與自動備份
建立 Cloud Storage bucket，設定 CORS 規則與生命週期管理
將電商 API 容器化（Dockerfile），部署到 Cloud Run
設定 Cloud Run 連接 Cloud SQL（使用 Cloud SQL Auth Proxy）
建立 External HTTP(S) Load Balancer，指向 Cloud Run 服務
在 Load Balancer 上啟用 Cloud CDN，設定快取規則
設定自訂域名與 SSL 憑證（Google-managed certificate）
設定 Cloud Monitoring 告警（錯誤率、延遲、SQL 連線數）

ACE 考試提示

Cloud Run vs App Engine vs GKE 選型是 ACE 必考題：無伺服器 + 容器 = Cloud Run
Cloud SQL 支援 MySQL、PostgreSQL、SQL Server；需要全球一致性才選 Spanner
Cloud CDN 只能搭配 External HTTP(S) Load Balancer 使用
考試常問「如何降低延遲」— CDN 是第一個要想到的答案

架構圖

租戶 A / B / C
      │
      ▼
Cloud Load Balancing
      │
      ▼
   GKE Cluster
  ┌───┼───┐
  ▼   ▼   ▼
 API  Auth Worker
  │    │    │
  └────┼────┘
       ▼
    Pub/Sub ──► Worker Pods
       │
       ▼
 Cloud Spanner
 (多區域副本)

使用服務

GKE (Autopilot) 運行微服務叢集，支援藍綠部署、自動擴縮、服務網格（Istio）

Cloud Spanner 全球分散式關聯資料庫，支援強一致性、99.999% SLA，適合多租戶資料隔離

Pub/Sub 非同步訊息佇列，解耦微服務間通訊，處理事件驅動工作負載（如通知、報表產生）

Cloud Armor WAF 防護，Rate limiting 防止單一租戶濫用，DDoS 防護

Cloud KMS 加密金鑰管理，每個租戶獨立加密金鑰，滿足合規要求

設計決策（為什麼這樣選？）

選擇 GKE Autopilot 而非 Cloud Run：SaaS 需要長駐服務（WebSocket、gRPC）、服務網格、以及更細粒度的資源控制。Autopilot 免管理節點。

選擇 Spanner 而非 Cloud SQL：多租戶 SaaS 需要全球一致性、水平擴展，且 Spanner 的 99.999% SLA 滿足企業客戶要求。

使用 Pub/Sub 解耦：避免服務間直接呼叫造成的耦合，非同步處理耗時任務（報表、通知），提升系統韌性。

租戶隔離策略：Spanner 中使用 tenant_id 前綴做 row-level 隔離，搭配 Cloud KMS 每租戶獨立加密金鑰。

實作步驟（9 步）

建立 GKE Autopilot 叢集，啟用 Workload Identity 與 Network Policy
部署核心微服務：API Gateway、Auth Service、Tenant Manager
建立 Cloud Spanner 執行個體，設計多租戶 schema（tenant_id 為主鍵前綴）
建立 Pub/Sub topics 與 subscriptions（每個事件類型一個 topic）
部署 Worker pods 訂閱 Pub/Sub，處理非同步任務
設定 Cloud Armor 安全政策：WAF 規則、Rate limiting per tenant
設定 Cloud KMS 為每個租戶產生獨立加密金鑰
建立 CI/CD pipeline（Cloud Build + GKE 藍綠部署）
設定多區域部署策略與故障轉移測試

ACE 考試提示

GKE Autopilot vs Standard：Autopilot 不需管理節點池，Google 全權管理基礎設施
Spanner 的關鍵特性：全球一致性 + 水平擴展 + 99.999% SLA — 考試常考何時選 Spanner
Pub/Sub 是全託管、無伺服器的訊息服務，至少一次傳遞（at-least-once delivery）
多租戶隔離：考試可能問 shared database vs separate database 的取捨

架構圖

資料來源（App / IoT / Logs）
          │
          ▼
       Pub/Sub
       (緩衝層)
          │
          ▼
      Dataflow
   (串流 / 批次 ETL)
     ┌────┴────┐
     ▼         ▼
  BigQuery   Cloud Storage
 (分析倉儲)  (原始資料湖)
     │
     ▼
  Looker Studio
  (視覺化儀表板)

使用服務

Pub/Sub 即時事件擷取與緩衝，解耦資料來源與處理層，承受突發流量

Dataflow 基於 Apache Beam 的全託管串流/批次處理引擎，執行 ETL 轉換、資料清洗、彙總

BigQuery 無伺服器資料倉儲，支援 PB 級查詢、SQL 分析、ML 內建函數

Cloud Storage 資料湖儲存原始資料（Parquet/Avro 格式），作為資料備份與重播來源

Looker Studio 免費的視覺化工具，直接連接 BigQuery 建立即時儀表板與報表

設計決策（為什麼這樣選？）

Pub/Sub 作為緩衝層：當 Dataflow 處理速度跟不上時，Pub/Sub 會自動緩存訊息，避免資料遺失。也方便未來新增多個消費者。

選擇 Dataflow 而非 Dataproc：Dataflow 是全託管無伺服器，不需管理叢集。適合 ETL 管線；Dataproc 適合需要 Spark/Hadoop 生態的場景。

BigQuery 作為分析倉儲：按查詢量計費（隨選定價）適合探索式分析；也可選固定費率（slot 預留）控制成本。

同時寫入 Cloud Storage（資料湖）：保留原始資料供未來重新處理或不同 schema 分析，實現 Lambda/Kappa 架構。

實作步驟（8 步）

建立 Pub/Sub topic 與 subscription，設定訊息保留期限（如 7 天）
設定資料來源將事件發送到 Pub/Sub（SDK / REST API）
開發 Dataflow pipeline（Apache Beam SDK），定義轉換邏輯
設定 Dataflow 同時輸出到 BigQuery（結構化資料）和 Cloud Storage（原始備份）
在 BigQuery 建立 dataset，設定分區表（按日期）與叢集欄位優化查詢
部署 Dataflow streaming job，設定自動擴縮參數
使用 Looker Studio 連接 BigQuery，建立儀表板
設定 Cloud Monitoring 監控管線延遲、錯誤率、backlog 大小

ACE 考試提示

Dataflow vs Dataproc：Dataflow = 全託管 Apache Beam、Dataproc = 託管 Spark/Hadoop — 這是必考選型題
BigQuery 定價：隨選 $5/TB 查詢 vs 固定費率 slot 預留 — 考試常考成本優化
Pub/Sub 保證至少一次傳遞，Dataflow 可以做到恰好一次處理（exactly-once）
BigQuery 分區表（Partitioned Table）是考試常考的成本優化手段

架構圖

開發者 ── git push
             │
             ▼
        Cloud Build
        (自動建構)
             │
             ▼
       Cloud Storage
       (靜態網站託管)
             │
             ▼
         Cloud CDN
       (全球邊緣快取)
             │
             ▼
        Cloud DNS
      (自訂域名解析)
             │
             ▼
          使用者

使用服務

Cloud Storage 託管靜態網站檔案（HTML/CSS/JS/圖片），啟用靜態網站功能，設定 index 和 404 頁面

Cloud CDN 快取靜態資源至 100+ 全球邊緣節點，讓全球用戶都有毫秒級載入速度

Cloud DNS 高可用域名解析服務（100% SLA），設定 CNAME 指向 Load Balancer

Cloud Build CI/CD 管線，偵測 git push 自動觸發建構（如 npm build）並部署到 Cloud Storage

Cloud Load Balancing 提供 HTTPS 支援（Google-managed SSL）、CDN 入口點、自訂域名綁定

設計決策（為什麼這樣選？）

Cloud Storage 靜態網站：比 Compute Engine 或 Cloud Run 便宜 90%+，適合純靜態內容。沒有伺服器需要管理。

需要 Load Balancer 的原因：Cloud Storage 原生靜態網站不支援 HTTPS 自訂域名，需透過 LB 提供 SSL 終止。

Cloud Build 自動化：避免手動 gsutil rsync，git push 即自動部署，確保版本一致性。每天 120 分鐘免費建構額度通常足夠。

Cloud DNS 而非外部 DNS：整合在 GCP 內管理更方便，100% SLA，且可搭配 IAM 權限控制。

實作步驟（9 步）

建立 Cloud Storage bucket（名稱需與域名相同或使用 LB 路由）
啟用 Cloud Storage 靜態網站功能，設定 MainPageSuffix 和 NotFoundPage
設定 bucket 權限為公開讀取（allUsers: Storage Object Viewer）
建立 External HTTP(S) Load Balancer，後端指向 Cloud Storage bucket
在 Load Balancer 設定 Google-managed SSL 憑證
啟用 Cloud CDN 於 Load Balancer 後端
設定 Cloud DNS zone，將域名 A/AAAA 記錄指向 LB IP
建立 Cloud Build trigger，連接 Git repo，設定建構腳本（cloudbuild.yaml）
測試完整流程：git push → 自動建構 → 自動部署 → CDN 更新

ACE 考試提示

Cloud Storage 靜態網站 + Cloud CDN + LB 是考試常見的「最低成本」答案
Cloud Storage 不能直接提供 HTTPS 自訂域名 — 需要 Load Balancer 做 SSL 終止
Cloud Build 免費額度：每天 120 分鐘建構時間
考試常問靜態網站的全球加速方案 — 答案就是 Cloud CDN

架構圖

IoT 裝置（感測器 / 閘道器）
          │
       MQTT / HTTP
          │
          ▼
      IoT Core
   (裝置管理 + 認證)
          │
          ▼
       Pub/Sub
     (訊息緩衝層)
       ┌──┴──┐
       ▼     ▼
  Dataflow  Cloud Functions
(串流處理)  (即時告警)
       │
    ┌──┴──┐
    ▼     ▼
BigQuery  Bigtable
(分析)   (時序資料)

使用服務

IoT Core 裝置註冊、身份認證（X.509 憑證）、MQTT/HTTP 通訊、裝置狀態管理

Pub/Sub 接收 IoT Core 轉發的裝置訊息，緩衝流量尖峰，fan-out 到多個消費者

Dataflow 串流處理裝置資料：解析、過濾異常值、時間視窗彙總、寫入儲存

BigQuery 長期資料分析、趨勢報表、異常偵測、搭配 BigQuery ML 做預測性維護

Bigtable 儲存高頻時序資料（每秒數千筆寫入），支援毫秒級低延遲讀取

Cloud Functions 訂閱 Pub/Sub 即時觸發告警（如溫度超標），發送通知到 Slack/Email

設計決策（為什麼這樣選？）

IoT Core 管理裝置：提供標準 MQTT 通訊協定、X.509 憑證認證、裝置 OTA 設定更新，免自建 MQTT broker。

Pub/Sub 做中間層：解耦裝置通訊與資料處理。當 Dataflow 升級或故障時，訊息不會遺失。也支援多個消費者同時處理。

BigQuery + Bigtable 雙寫：BigQuery 適合複雜 SQL 分析與歷史趨勢；Bigtable 適合高頻寫入與低延遲即時查詢（如最新裝置狀態）。

Cloud Functions 做即時告警：比在 Dataflow 裡處理告警更簡單，獨立部署、獨立擴縮，不影響主資料管線。

實作步驟（9 步）

建立 IoT Core registry，設定裝置認證方式（X.509 或 RSA）
建立 Pub/Sub topic（IoT Core 預設會自動建立 telemetry 和 state topics）
註冊測試裝置，使用 MQTT client 發送模擬資料驗證連線
建立 Dataflow streaming pipeline：讀取 Pub/Sub → 解析 JSON → 過濾 → 寫入 BigQuery + Bigtable
在 BigQuery 建立分區表（按裝置 ID 和時間戳分區）
建立 Bigtable instance，設計 row key（device_id#reverse_timestamp）
部署 Cloud Functions 訂閱 Pub/Sub，實作告警邏輯
設定 Cloud Monitoring 監控裝置連線數、訊息延遲、管線 backlog
建立 Looker Studio 儀表板顯示裝置狀態與趨勢

ACE 考試提示

IoT Core 使用 MQTT 或 HTTP 協定，裝置認證用 X.509 憑證或 RSA 公鑰
Bigtable vs BigQuery：Bigtable 適合低延遲大量寫入（時序資料）；BigQuery 適合複雜分析查詢
Bigtable row key 設計是考試重點：避免 hotspot，建議用 reverse timestamp
IoT → Pub/Sub → Dataflow → BigQuery 是 GCP 經典資料管線模式

架構圖

資料準備
  │
  ▼
Cloud Storage ◄── BigQuery
(訓練資料集)    (特徵工程)
  │
  ▼
Vertex AI Training
(Custom / AutoML)
  │
  ▼
Vertex AI Model Registry
(模型版本管理)
  │
  ├──► Vertex AI Endpoints
  │    (線上推論 API)
  │
  └──► Cloud Run
       (自訂推論容器)

使用服務

Vertex AI 統一 ML 平台：管理資料集、訓練任務（Custom Training / AutoML）、模型版本、推論端點

Cloud Storage 儲存訓練資料集、模型產物（SavedModel / ONNX）、實驗日誌

Cloud Run 部署自訂推論容器（如 TensorFlow Serving、PyTorch Serve），適合需要自定義前後處理的場景

BigQuery 特徵工程與資料分析，使用 BigQuery ML 快速原型驗證，匯出訓練資料集

Artifact Registry 儲存訓練用 Docker 映像檔和推論容器映像檔，版本管理

Vertex AI Pipelines 編排 ML 工作流程（資料驗證 → 訓練 → 評估 → 部署），可重現的 MLOps

設計決策（為什麼這樣選？）

Vertex AI 而非自建 ML 基礎設施：Vertex AI 整合訓練、調參、部署、監控，減少 MLOps 負擔。支援 Custom Training（帶自己的程式碼）和 AutoML（零程式碼）。

Cloud Run 部署推論 vs Vertex AI Endpoints：需要自訂推論邏輯（如前處理、批次推論、A/B 測試）時用 Cloud Run；標準模型推論用 Vertex AI Endpoints 更方便。

Cloud Storage 作為中心儲存：訓練資料、模型產物、實驗紀錄都存在 Cloud Storage，Vertex AI 原生支援讀取。

BigQuery 做特徵工程：利用 SQL 處理結構化資料的特徵計算比 Python 腳本更快（PB 級資料秒級完成），且結果可直接匯出到 Cloud Storage。

實作步驟（10 步）

準備訓練資料，上傳到 Cloud Storage bucket（建議 TFRecord 或 CSV 格式）
在 BigQuery 進行資料探索與特徵工程，匯出處理後的資料集
建立 Vertex AI Dataset，連結 Cloud Storage 資料來源
選擇訓練方式：AutoML（快速原型）或 Custom Training（自訂模型程式碼）
Custom Training：建立訓練容器映像檔，推送到 Artifact Registry
提交 Vertex AI Training Job，設定 GPU 類型與數量
模型訓練完成後，匯入 Vertex AI Model Registry
部署到 Vertex AI Endpoint 或打包成 Cloud Run 服務
設定 Vertex AI Pipelines 自動化整個流程（定期重新訓練）
設定模型監控（Model Monitoring）偵測資料偏移

ACE 考試提示

Vertex AI 是 GCP 的統一 ML 平台（取代舊的 AI Platform）
AutoML vs Custom Training：AutoML 適合非 ML 專家快速建模；Custom Training 適合需要自訂架構的場景
考試常問「最少管理負擔的 ML 方案」— 答案通常是 AutoML 或 BigQuery ML
Vertex AI Endpoints 支援自動擴縮和流量分割（canary deployment）

經典架構拆解 · 01 — Netflix 全球串流架構

經典架構拆解 · 02 — Uber 即時派單架構

經典架構拆解 · 03 — Stripe API 冪等性設計

電商平台架構

使用服務

SaaS 多租戶應用架構

使用服務

資料分析管線架構

使用服務

靜態網站架構

使用服務

IoT 數據平台架構

使用服務

ML 訓練與推論架構

使用服務

想看更多架構範本？

歡迎來到登雲學院

你的雲端經驗？

你的目標認證？

每天能學多久？

你的學習計畫準備好了！