架構師設計工作坊 — PCA 13 步驟實戰

以登雲書店為例：這是一個線上電商平台，讓讀者瀏覽書籍、加入購物車、結帳並追蹤訂單;核心角色是「讀者」與「書店營運人員」;目標是以穩定、低維運成本支撐每日約三萬筆瀏覽與兩千筆訂單。

登雲書店 Persona A — 小陳，35 歲上班族，每週通勤時滑手機找書，最在意搜尋速度與推薦精準度;Persona B — 書店營運助理小葉，每天用後台批次上架新書，最怕圖檔上傳與庫存同步出錯。

例如：身為登雲書店讀者小陳，我想要在首頁看到依我歷史偏好排序的書單，以便三秒內決定今天要不要加入購物車—驗收條件包含首頁回應 < 1 秒、至少呈現 10 本書、登入狀態下顯示個人化結果。

登雲書店搜尋 API：有效請求先依規則排除健康檢查與已確認的無效輸入；5xx、逾時及非預期 4xx 都計入失敗。成功率 SLI = 成功的有效請求／全部有效請求，滾動 28 天 SLO 暫定 99.9%。延遲另以「成功且 500ms 內完成的有效請求／全部有效請求」設定 95% 目標，兩個目標分別追蹤。

登雲書店先定義 Catalog、Cart、Order、Payment Adapter、User、Recommendation、Notification 七個邏輯模組，不等同七個部署。小團隊可先用模組化 Web/API 加背景 worker；若推薦工作需要獨立資源，再拆出部署。Order 保存訂單狀態，付款供應商保存扣款結果，透過冪等與對帳協調。

Catalog 使用 GET /v1/books（列表／篩選）、GET /v1/books/{id}（明細），後台才可 POST 與 PATCH；實際刪除策略另記。購物車以 cartId 定位，但每次都檢查登入者的所有權。POST /v1/orders 接收冪等鍵，同一鍵重試回傳同一筆處理結果，付款狀態另外對帳。

Order 需要關聯與單一資料庫內的交易；假設每年成長 10GiB，尖峰讀寫量另行估計。主要服務位於 asia-east1，以區內 HA 處理 zone 故障；跨 region 的資料保護另在 DR 步驟設計。搜尋索引可以落後，但結帳必須回權威來源驗證價格與庫存。

本練習 Order 採 Cloud SQL PostgreSQL 的 regional HA（同一 region 的不同 zone）。Catalog 書目採 Firestore Standard edition，分類查詢與關鍵字搜尋索引分開設計；文字搜尋能力依 edition 查證，不能只寫 Native mode。封面圖先用 asia-east1 的 Cloud Storage Standard；快取是可選的後續最佳化，先以量測證明需求。

書店以 global external Application Load Balancer 作公用 HTTP(S) 入口，依支援的後端與政策整合 Cloud Armor／Cloud CDN；CDN 只快取明確允許公開共享的內容。Order 在 Web/API 內部處理，不因為有邏輯模組就另建一個 LB。背景通知由事件觸發；後端防火牆依實際 LB 代理與健康檢查需求配置。

公用入口連到 asia-east1 的 GKE；Web/API 分別連 Cloud SQL 私有 IP、Firestore 與 Cloud Storage API，不是 Cloud SQL 再連到 Firestore。VPC 跨 region，兩區各有 subnet。Cloud SQL 向 asia-northeast1 的副本非同步複寫；備援區的應用、權限與流量切換也要演練。

Regional GKE 讓 control plane 跨 zone，但應用仍須配置足夠副本與分散排程，並驗證失去一個 zone 後的容量。CPU 百分比 HPA 以 Pod requests 為基準；副本擴容和節點擴容是兩件事。Cloud SQL regional HA 處理區內故障，跨 region 故障交由下一步的 DR 計畫。

區內 zone 故障由 Cloud SQL regional HA 處理；資料誤刪依可用備份／日誌做 PITR。Region 故障則依計畫提升 asia-northeast1 的跨區 read replica，再切換應用與流量。RPO 5 分鐘、RTO 30 分鐘只是練習目標，須依複寫延遲與端到端演練驗證；每日匯出本身不能證明 5 分鐘 RPO。

先採未折扣的 USD 試算：GKE Standard 節點規格／數量與管理費、Cloud SQL regional HA 的運算／儲存／備份、跨區 DR 副本、物件儲存、LB／CDN、Cloud Armor 與日誌分列。每項記錄計費單位、用量、查價地點和日期，再加總。