Google PCD: 雲端原生應用程式架構與服務選擇 — 學習指南

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

屬於 Google Professional Cloud Developer — 學習指南. 使用經過驗證的解答練習： Google 考試中心, 或參加限時模擬考試： ExamRoll.io.

總覽

在 Google Cloud 上的雲端原生應用程式架構，核心在於建構可水平擴展、具備彈性的無狀態服務，並在適當時機採用代管服務，以最大程度地減少維運負擔。要有效地選擇服務，必須了解在控制權、可攜性、效能、成本和維運責任之間的權衡取捨。本節將介紹相關原則和模式，幫助您為全球使用者設計、現代化及維運具有可預測可靠性的應用程式。

雲端原生原則與架構選擇

十二因子與無狀態設計
- 程式碼庫、依賴項目、建置-發布-執行：鎖定確切的依賴版本，建立不可變的產物，並將建置與發布階段分開。容器映像檔和 Cloud Build 管線能強制執行可重現的發布流程。
- 將設定儲存在環境中：使用環境變數、Secret Manager、Kubernetes Secrets 或 Compute Engine 的執行個體中繼資料來外部化設定。切勿將憑證或每次部署的特定設定寫死在映像檔中。對於 Compute Engine 的代管執行個體群組，應使用執行個體範本的中繼資料來儲存每次部署的特定值。
- 後端服務：將資料庫、佇列和快取視為附加資源。優先選擇代管服務 (Cloud SQL、Cloud Spanner、Firestore、Memorystore、Pub/Sub) 以減輕維運負擔。
- 無狀態程序：透過增加執行個體來擴展；將會話狀態儲存在外部 (Memorystore for Redis、Firestore 或 Spanner)。將日誌寫入 stdout/stderr 或由 Cloud Logging 代理程式收集的日誌檔案。
- 可拋棄性：快速的啟動/關閉有助於快速擴展和滾動更新。處理 SIGTERM 信號以實現優雅關閉。
- 將日誌視為事件串流：產生結構化日誌；使用 Cloud Logging 進行收集，並使用 Cloud Monitoring 進行告警。
架構的權衡取捨
- 單體式架構
  - 優點：簡化開發/測試、較少的網路邊界、單一部署單元。
  - 缺點：獨立交付速度慢、擴展限制、跨領域的緊密耦合。
  - 故障模式：單一熱門路徑可能耗盡共享資源；迴歸問題會影響所有功能。
- 模組化單體式架構
  - 優點：清晰的內部模組邊界、可作為重構至服務的途徑、單一可部署檔案。
  - 缺點：仍受限於單體式的部署和資料庫。
  - 適用於團隊在抽離服務之前，先成熟化領域邊界的階段。
- 微服務
  - 優點：可獨立部署、針對性擴展、團隊自主性、透過適當的艙壁模式 (bulkheads) 實現故障隔離。
  - 缺點：分散式系統的複雜性、一致性、可觀測性及維運開銷。
  - 故障模式：透過同步呼叫造成的連鎖故障；schema 漂移；網路通訊頻繁。
- 事件驅動
  - 優點：鬆散耦合、非同步的彈性、天然的緩衝機制、透過日誌/串流的可審計性。
  - 缺點：偵錯複雜、最終一致性、順序性和「恰好一次」(exactly-once) 語意難以實現。
  - Pub/Sub 提供「至少一次」(at-least-once) 的交付保證；消費者端需設計為冪等性 (idempotent)。
- 無伺服器 (Cloud Run、Cloud Functions、App Engine)
  - 優點：極少的維運工作、可縮減至零、依請求自動擴展、整合式的安全性和遙測。
  - 缺點：執行時間和並行性限制、冷啟動、平台特定的限制。
  - 適用於突發性工作負載、行動/Web 後端及事件處理。

通訊模式與服務選擇

同步與非同步呼叫
- 同步
  - 用於需要立即得到結果的請求/回應 API。
  - 協定：gRPC (基於 HTTP/2、支援串流、精簡的 Protobuf；非常適合行動裝置頻寬和強型別合約)、HTTP/JSON (廣泛的相容性；偵錯較簡單)。
  - 風險：緊密耦合和延遲放大；應使用逾時、帶有抖動的重試及斷路器模式。
- 非同步
  - 當工作可以延後或批次處理時，使用 Pub/Sub 或 Cloud Tasks。
  - 優點：平滑流量尖峰、隔離故障、透過最終完成來改善使用者感知的延遲。
  - 風險：需要實現冪等性 (idempotency) 和補償性動作；必須自行建構對處理中工作的可見性。
在 Google Cloud 上的服務選擇標準
- 控制權與可攜性
  - Compute Engine：完整的 VM 控制權和自訂映像檔；較高的維運負擔。
  - GKE：可攜的容器和服務網格選項；強大的自動擴展能力；共同責任模型。
  - Cloud Run：容器的高度可攜性，維運工作極少；可縮減至零；以請求為導向。
  - App Engine：框架化的 PaaS，內建路由和擴展功能；對於特定語言是部署最快的路徑。
- 擴展性與延遲
  - Global HTTP(S) Load Balancing 搭配 Cloud CDN 進行邊緣加速。
  - 資料儲存：
    - Cloud Spanner：全域一致性、水平擴展、多區域 99.999% 可用性。
    - Cloud SQL：代管的關聯式資料庫，區域級服務，支援讀取複本 (包含跨區域)。
    - Firestore：文件型資料庫，在多區域模式下具備全球可用性，對單一文件提供強一致性。
    - Cloud Bigtable：適用於寬欄式使用情境的低延遲、大規模儲存。
    - Memorystore：用於熱門路徑和會話的低延遲快取。
- 維運責任
  - 優先選擇代管服務來處理核心問題 (可用性、修補、備份、升級)。
  - 自行管理提供彈性，但增加了維運負擔和故障風險 (例如，自行託管 Kafka vs. 使用 Pub/Sub)。
- 資料移動與整合
  - 使用 VPC-native 連線、Private Service Connect 和 internal HTTP(S) Load Balancing 以實現低延遲的私有存取。
  - 服務探索：在叢集內使用 Kubernetes Service 名稱；對 VM 則使用 Compute Engine 內部 DNS。

Kubernetes Service 範例 (叢集內名稱探索)： apiVersion: v1 kind: Service metadata: name: image-resize spec: selector: app: image-resize ports:

port: 80 targetPort: 8080 type: ClusterIP

邊界、相容性與可靠性模式

領域邊界與擁有權
- 使用領域驅動設計 (domain-driven design) 來定義限界上下文 (bounded contexts)。每個服務擁有自己的資料，並將 API/事件作為合約發布。
- 避免跨服務共用資料庫；應使用定義良好的介面和事件傳播。
- 擁有權意味著每個服務需負責輪值待命 (on-call)、服務等級目標 (SLO)、發布節奏及預算。
API 合約與向後相容性
- 明確地對 API 進行版本控制 (例如，在路徑或標頭中使用 v1)。優先採用追加式變更；避免破壞性欄位或行為變更。
- 使用消費者驅動合約測試 (consumer-driven contract tests) 和金絲雀發布 (canary releases)。棄用時應提供時間表並透過遙測 (telemetry) 監控使用情況。
- 對於行動裝置用戶端，預期會有長尾版本 (long tail versions) 的存在；需同時維護多個 API 版本。
故障隔離與彈性
- 艙壁模式 (Bulkheads)：按服務或優先級隔離資源 (例如，獨立的節點池 (node pools)、執行個體群組 (instance groups)、配額 (quotas))。防止盡力而為 (best-effort) 的功能耗盡關鍵路徑的資源。
- 斷路器模式 (Circuit breakers)：在對依賴項的請求連續失敗後跳脫 (trip)，以卸載流量 (shed load) 並提供恢復時間窗。可透過服務網格 (service mesh) (例如 Envoy)、閘道器政策或函式庫來實作。
- 逾時與重試：使用帶有抖動 (jitter) 的截斷指數退避 (truncated exponential backoff)；確保處理程式具備冪等性 (idempotent)。
- 優雅降級 (Graceful degradation)：在逾時情況下，省略非關鍵的 UI 元件；提供快取或近似的資料，而不是回傳錯誤。
- 健康檢查與就緒探測 (readiness probes)：僅將流量路由到就緒的執行個體；使用存活探測 (liveness probes) 進行自我修復。

截斷指數退避範例 (HTTP 429)： retry = 0 max_retry = 5 base = 0.5 while retry < max_retry: resp = fetch_gcs_object() if resp.status_code == 200: break if resp.status_code in (429, 500, 503): sleep = min(8, base * (2 ** retry)) + random.uniform(0, 0.25) time.sleep(sleep) retry += 1 else: raise Exception(“Non-retryable error”)

全球性與營運考量

服務全球使用者的多地區模式
- 全球前端：使用具備 anycast IP 的 Global External HTTP(S) Load Balancing，並搭配 Cloud CDN 處理靜態內容。設定負向快取 (negative caching) 與驗證，以減少來源伺服器的負載。
- 資料層 (Data plane)：
  - 若要達到五個九 (99.999%) 的資料庫可用性並將全球讀取延遲降到最低，請使用多地區的 Cloud Spanner 執行個體 (例如 nam-asia-eur1)，並配置足夠的節點以滿足運算與法定數量 (quorum) 的需求 (正式環境至少需要三個節點)。
  - 對於讀取密集且不要求嚴格全球一致性的模式，可考慮採用區域性主執行個體搭配跨地區讀取複本；但需接受跨洲寫入時較高的延遲。
- 應用程式層 (Application plane)：
  - 在多個地區部署具備自動擴展功能的無狀態服務 (GKE 或 Cloud Run)。每個地區使用後端服務 (backend services) 與網路端點群組 (network endpoint groups)。
  - 根據延遲進行路由，同時遵守資料落地與合規性的限制。
- 快取：將 Memorystore 或邊緣快取 (edge caches) 部署在靠近使用者的位置，以吸收讀取流量並保護來源伺服器。
代管 vs 自行管理
- 使用 Cloud Monitoring 收集指標、Cloud Logging 收集日誌、Cloud Trace/Profiler 分析延遲與 CPU/記憶體熱點。針對 SLO 消耗率 (burn rates) 建立快訊政策，並透過可用性檢查 (uptime checks) 監控外部可用性。
- 如果現有的可觀測性平台必須作為主要記錄系統 (system of record)，請先透過 Cloud Logging 擷取資料以獲得低延遲的快訊，然後再透過匯出槽 (sinks) 匯出到外部平台。
現代化與漸進式遷移
- 絞殺者模式 (Strangler pattern)：在單體式應用程式前加上一個閘道器；將特定端點路由到新的服務。逐步取代原有功能。
- 透過抽象化分支 (Branch by abstraction)：在依賴項周圍引入一個介面，並在其後方更換實作 (例如資料庫或儲存空間)。
- 防腐層 (Anti-corruption layer)：在舊有資料模型與新的限界上下文 (bounded contexts) 之間進行轉換。
- 資料遷移：使用雙寫 (dual writes) 搭配驗證，或使用事件溯源 (event sourcing) 來回填資料；規劃轉換時需具備背壓 (backpressure) 控制機制。
- 分階段交付：分階段替換功能以將商業風險降到最低；持續測量 SLO。
設計審查與權衡評估
- 安全性：威脅模型、IAM 最小權限原則、使用服務帳戶而非嵌入式金鑰 (在 GCE/GKE/Cloud Run 上使用 Application Default Credentials)、在需要時使用 CMEK、私有連線、WAF 與速率限制、漏洞與網站安全掃描。
- 可靠性：定義 SLO 與錯誤預算、多地區故障轉移計畫、容量預留空間 (capacity headroom)、混沌演練 (chaos drills)、依賴關係圖。
- 效能：長尾延遲 (tail latency) 分析、在邊緣與來源伺服器進行負載測試、連線重複使用 (HTTP/2, gRPC)、壓縮、快取策略。
- 成本：適當調整資源規模、自動擴展政策、承諾使用折扣、針對突發性工作負載縮減至零、輸出 (egress) 與 CDN 卸載。
- 營運：操作手冊 (Runbooks)、復原 (rollbacks)、漸進式交付 (金絲雀、藍綠部署)、政策即程式碼 (policy as code)、備份與災難復原測試、事件應變整合。

實務問題情境

Nimbus Retail 正在推出一個全球電子商務平台，提供個人化圖片服務，並要求全球 p95 延遲必須低於 200 毫秒，訂單資料庫的可用性需達到 99.999%。他們還必須保留現有的 SIEM，同時提升快訊速度。

使用 Cloud Spanner 建立一個全球性、高可用性的資料庫

動作：在 nam-asia-eur1 建立一個多地區的 Spanner 執行個體，至少包含三個節點，並將資料表分割成適當的交錯式結構 (interleaved schemas) 以提升資料局部性 (locality)。
理由：多地區的 Spanner 透過部署在三大洲的複本，提供五個九的可用性與低讀取延遲；三個或更多節點可確保足夠的運算與複本法定數量 (quorum) 容量。

範例：

undefined

前端與 API 的全球部署

動作：使用 Global External HTTP(S) Load Balancing 搭配 Cloud CDN 處理靜態資產，並將流量動態路由到區域性後端 (位於 us-central1、europe-west1、asia-east1 的 GKE 服務)。
理由：Anycast VIP 能將來回時間 (RTT) 降到最低；CDN 在靠近使用者的位置快取圖片；後端服務會將請求分發到最近的健康地區。

在 GKE 上部署無狀態服務並使用叢集內服務發現

動作：在 GKE 上部署圖片縮放與 API 服務，使用 Horizontal Pod Autoscaling，並透過 ClusterIP Services 提供叢集內基於名稱的存取；透過 Ingress 公開外部端點。
理由：無狀態的 Pods 允許彈性擴展；Kubernetes Service 抽象化了 Pod 的 IP 並提供穩定的 DNS，從而降低客戶端的耦合度。

事件驅動的圖片處理

動作：將圖片處理任務發布到 Pub/Sub；執行透過 push 訂閱的 Cloud Run 服務來處理儲存在 Cloud Storage 中的物件。針對 GCS 的 429/5xx 錯誤，實作帶有抖動 (jitter) 的截斷式指數輪詢 (truncated exponential backoff)。
理由：Pub/Sub 能緩衝流量高峰並隔離故障；Cloud Run 能根據每則訊息進行擴展；輪詢機制能減少錯誤放大效應，並幫助儲存貯體 (buckets) 逐漸「暖機」。

可觀測性與快速快訊

動作：使用 Cloud Logging 與 Cloud Monitoring 擷取日誌和指標，為 API 定義可用性檢查 (uptime checks)，並根據錯誤率與延遲建立快訊政策。設定一個日誌匯出槽 (log sink) 將資料匯出到現有的 SIEM。
理由：原生的遙測功能提供低延遲的快訊與代管的可用性檢查；匯出功能在保留集中式 SIEM 的同時，不會犧牲快訊速度。

外部化的設定與密鑰

動作：將非機密的設定儲存在 ConfigMaps 中；將密鑰與 API 金鑰儲存在 Secret Manager 中，並搭配 GKE 的 Workload Identity 使用。對於任何基於 Compute Engine 的工作，使用執行個體中繼資料 (instance metadata) 來儲存每個部署特定的值。
理由：外部化的設定能實現不可變的映像檔與環境特定的配置；避免嵌入密鑰；中繼資料支援 VM 的差異化，而無需修改程式碼。

故障隔離與優雅降級

動作：對於盡力而為 (best-effort) 的個人化工作負載，使用獨立的節點池 (node pools) 來實作艙壁模式 (bulkheads)；對個人化服務強制執行請求預算與斷路器 (circuit breakers)。在 UI 中，當依賴項逾時，則省略非關鍵的元件。
理由：隔離容量可防止盡力而為的功能耗盡結帳流程的資源；斷路器能限制故障的影響範圍 (blast radius)；優雅降級能保留核心的使用者旅程。

API 合約與相容性

動作：為行動裝置客戶端 (v1) 定義 gRPC 合約，並為網頁端提供 HTTP/JSON 轉碼 (transcoding)；採用附加式變更，並在行動裝置版本推出期間至少維護兩個版本。
理由：gRPC 能減少頻寬並提供強型別；轉碼能簡化瀏覽器與合作夥伴的整合；版本控制能保持向後相容性。

安全性與身分識別

動作：為每個服務使用遵循最小權限 IAM 原則的 Google 服務帳戶；依賴 Application Default Credentials。啟用 Cloud Armor 以提供邊緣保護，並強制在所有地方使用 TLS。
理由：Workload Identity 消除了金鑰管理的風險；WAF 與速率限制能減緩濫用行為；傳輸中加密是預設且強制執行的。