案例實戰：架構設計工作坊

工作坊目標

PCA 考試的案例題不是單純考你認不認識某個服務，而是考你能不能在複雜的商業情境中做出合理的架構決策。這堂課我們將走過一個完整的架構設計演練——從需求分析到最終架構，讓你親身體驗「架構師思考」的完整流程。

這個工作坊的目標：

• 練習將模糊的商業需求拆解為明確的技術約束
• 在每個架構決策點上運用排除法與取捨分析
• 建立一套可在考試中 2-3 分鐘內完成的快速決策框架

模擬案例：CloudMart 全球電商平台

公司背景

CloudMart 是一家總部位於台灣的電商平台，過去三年營收年增 120%，目前服務台灣與東南亞市場。公司計畫在未來 18 個月內擴展至全球 5 個區域（亞太、北美、歐洲、中東、南美）。

現況

• 應用架構：單體式 Java 應用，部署在自建機房的 VMware 環境
• 資料庫：單一 MySQL 8.0 實例，資料量約 2TB
• 部署方式：手動打包、手動部署，每月一次版本更新
• 團隊：30 人工程團隊，熟悉 Java 和 Docker，少數人有 Kubernetes 經驗

商業需求

1. 擴展至 5 個區域，各區域延遲 < 200ms
2. 系統可用性 99.99%（年停機 < 52.6 分鐘）
3. AI 個人化推薦引擎，提升轉換率 15%
4. 推出行動 App（iOS/Android）
5. 合規要求：歐洲 GDPR、各地資料在地化法規

技術需求

1. 雙十一等促銷活動流量為平日 10 倍
2. 即時庫存同步，全球一致
3. 全球延遲 < 200ms
4. 完整的資料分析管線，支援即時與離線分析

💡 考試小提示：PCA 案例題的核心就是這種「多維度需求同時出現」的情境。不要急著選服務，先把需求拆乾淨。

Step 1：需求分析

架構設計的第一步永遠是拆解需求，把模糊的商業語言轉化為具體的技術約束。

💡 考試小提示：先排優先級！考試時如果兩個選項都「可以」，選滿足最高優先級需求的那個。

Step 2：六大支柱評估

將需求對應到 Google Cloud Architecture Framework 的六大支柱，確保架構沒有盲點：

Step 3：運算架構設計

單體應用必須拆分為微服務，但不需要一步到位——採用 Strangler Fig Pattern 漸進式遷移：

為什麼核心交易選 GKE 而非 Cloud Run？因為交易系統需要連線池管理、背景工作排程、服務網格（Service Mesh） 等能力，GKE 的 Sidecar 模式和 Pod 生命週期管理更適合。

💡 考試小提示：GKE vs Cloud Run 的決策關鍵——需要長連接、背景任務、精細資源控制選 GKE；無狀態請求驅動選 Cloud Run。

Step 4：資料架構設計

資料層是這個案例最關鍵的決策點——「全球即時庫存同步」直接指向 Spanner：

Spanner 的設計考量

• 主鍵設計：避免 hotspot，使用 UUID 或反轉時戳作為前綴
• 區域配置：Multi-region 配置（nam-eur-asia1）自動跨洲複製
• 成本控制：Processing Units 按需調整，尖峰時段自動擴展

Step 5：網路架構設計

全球部署的網路設計重點在於讓流量走 Google 骨幹網路，而非公共網際網路：

• Global External Application Load Balancer — 單一 Anycast IP，自動將使用者導向最近的後端
• Cloud CDN — 快取靜態資源與 API 回應，Cache-Control header 精細控制
• Cloud Armor — WAF 防護，DDoS 緩解，地理位置存取控制
• VPC 設計 — Shared VPC，每個區域一個子網路，Private Google Access 存取 GCP 服務
• Cloud Interconnect — 過渡期間連接自建機房與 GCP，支援漸進式遷移

Step 6：安全架構設計

99.99% 可用性的系統如果被攻破，可用性就是 0%。安全架構需同步設計：

GDPR 合規要點

• 歐洲使用者資料必須儲存在歐洲區域的 Spanner 分區
• 實作「被遺忘權」：設計軟刪除 + 排程硬刪除機制
• 資料存取稽核：啟用 Data Access Audit Logs

Step 7：AI/ML 架構

AI 推薦引擎的架構需兼顧推論延遲與模型更新頻率：

資料管線：使用者行為事件 → Pub/Sub → Dataflow → BigQuery → 模型訓練 → Vertex AI Endpoint。

💡 考試小提示：AI 架構題的關鍵區分——「即時推論」用 Vertex AI Online Prediction，「批次推論」用 Batch Prediction 或 BigQuery ML，「不需要自訓練」用 Pre-trained API 或 AutoML。

Step 8：營運架構

再好的架構沒有良好的營運也是空談：

完整架構總覽

以下是 CloudMart 最終架構決策的彙整：

考試實戰技巧

在考試中你不會有 30 分鐘來做一個完整的架構設計，但可以用精簡版流程在 2-3 分鐘內決策：

1. 30 秒讀題 — 抓關鍵字：可用性數字、延遲要求、資料一致性、合規需求
2. 30 秒排除 — 用約束條件淘汰不可能的選項（例如需要強一致性就排除 Bigtable）
3. 60 秒比對 — 剩餘選項對照需求矩陣，選「滿足最多 P0 需求」的那個
4. 30 秒驗證 — 檢查選擇是否違反任何明確約束（成本、合規、技術限制）

常見陷阱

• 過度設計：不是每個場景都需要 Spanner，Cloud SQL + Read Replica 能解決大部分問題
• 忽略團隊能力：案例說團隊不熟 Kubernetes，卻選了需要深度 K8s 管理的方案
• 只看技術不看商業：最佳技術方案不等於最佳商業方案，成本和時程也是約束

💡 考試小提示：案例題通常不會有「完美答案」。選最合理的取捨，而不是技術上最先進的方案。Google 偏好的答案通常是「managed service + 最小營運負擔」。

重點整理

• 架構設計的核心是取捨 — 沒有完美方案，只有最適合當下約束的方案
• 需求分析決定一切 — 先拆解需求並排優先級，再選服務，避免拿著錘子找釘子
• 六大支柱是檢查清單 — 確保每個支柱都有對應設計，不遺漏安全、成本、營運等面向
• 運算選型看工作負載特性 — GKE 適合長時間運行的有狀態服務，Cloud Run 適合無狀態請求驅動
• Spanner 是全球一致性的唯一解 — 需要跨區域強一致性時沒有替代方案
• AI 架構分線上與離線 — 即時推論用 Vertex AI Prediction，批次分析用 BigQuery ML
• 考試快速決策法 — 讀題（30s）→ 排除（30s）→ 比對（60s）→ 驗證（30s）

下一步

恭喜你完成了這個架構設計工作坊！在接下來的課程中，我們將進入最終的考試準備階段——整合所有學過的知識，進行模擬題演練，並針對 PCA v6.1 的重點考試領域做最後衝刺。