Dress4Win
一句話描述:一家跑在自建機房多年、現在被擴充成本與佈署速度壓得喘不過氣的時尚電商平台,想用分階段遷移方式把業務搬上 GCP,同時不中斷現有營收。
🏢 商業背景
時尚電商屬於「高季節性 + 強流量波動」的產業:大型促銷檔(雙 11、黑五、換季)期間,流量能是平日的 10-30 倍,但平日凌晨可能只有離峰期的 5%。在自建機房時代,這代表你必須花固定資本買下「應付尖峰」的硬體,然後讓一整年九成的時間讓伺服器閒置吃電。對一家規模中大型的電商來說,光是這筆浪費就足以侵蝕毛利率好幾個百分點。
這類公司通常已經跑了 5-10 年,系統早期用 LAMP 或單體 Java 架構上線,多年下來堆積了各種依賴:本地 NFS 檔案系統、手動佈署腳本、OS 層級的排程任務、綁定特定硬體版本的資料庫。這些「歷史包袱」讓新功能上線的週期從理想的「每天多次」退化為「每季一次」,跟當代時尚的快時尚節奏完全不搭—今天抖音爆紅的款式,兩週後才能上架,訂單機會已經流失到競品。
商業上最現實的壓力是:搬雲不能影響現有營收。一家靠 24/7 線上販售的公司,無法接受週末 stop-the-world migration;但同時,投資人與董事會要看到明確的「雲端效益路線圖」,不能一拖三年。這讓 Dress4Win 的遷移必須是分階段、可回滾、混合雲並行運作的設計—典型的 brown-field migration。
⚡ 主要技術挑戰
- 不能中斷現有營收遷移期間舊系統與新雲端必須並行運作,資料一致性與雙向同步是最棘手的問題。
- DevOps 能力斷層工程團隊習慣手工佈署,對 IaC、CI/CD、container 陌生,需要邊搬邊學。
- 資料庫耦合太深單體應用程式直接 JOIN 十幾張表,很難切成微服務,拆分策略是頭痛題。
- 靜態資產龐大商品圖片、影片累積數十 TB,從機房搬到 Cloud Storage 本身就是專案等級。
- 成本必須透明化以前是固定資本支出,現在變浮動 OpEx,財務團隊沒有心理準備與工具監控。
🏗️ 建議 GCP 架構
這個案例我會採用三階段遷移策略:階段一(lift-and-shift)先把現有 VM 搬到 Compute Engine 上,用 Cloud Interconnect 跟地端做 VPN/專線,確保雙向資料同步;階段二(optimize)把無狀態 web 前端改造成 Cloud Run 或 GKE container,把檔案存取改到 Cloud Storage;階段三(modernize)再把單體資料庫拆成 Cloud SQL + Firestore 組合,引入 Pub/Sub 解耦批次任務。這樣每一階段都能獨立上線、獨立回滾。
[階段一：Lift-and-Shift]
┌──────────────┐ Cloud Interconnect ┌──────────────┐
│ On-Prem 機房 │ ◄────────────────────► │ GCP VPC │
│ (legacy DB) │ │ Compute │
└──────────────┘ │ Engine MIG │
└──────┬───────┘
│
[階段二：Optimize] ▼
┌───────────────────────┐
[Cloud Load Balancer]──────► │ Cloud Run / GKE │
│ │ (無狀態 web 前端) │
▼ └────────┬──────────────┘
[Cloud CDN] │
│ ▼
▼ [Cloud Storage]
[靜態資產] (商品圖 / 影片)
[階段三：Modernize]
┌───────────────┐ ┌──────────────┐ ┌──────────┐
│ Cloud SQL │────►│ Pub/Sub │───►│ Dataflow │
│ (交易、訂單) │ │ (事件解耦) │ └────┬─────┘
└───────────────┘ └──────────────┘ ▼
▲ [BigQuery]
│ ┌──────────────┐ (分析倉儲)
┌──────┴────────┐ │ Firestore │
│ Memorystore │ │ (session、 │
│ (cache layer) │ │ user pref) │
└───────────────┘ └──────────────┘
為什麼不直接 rewrite 成 cloud-native?因為 Dress4Win 的現實是「營運不能停、預算不能爆」。一次性重寫的失敗率極高,分階段搬最大的價值在「每一步都可驗證、可賺到短期效益」:階段一就能享受到 autoscaling 省錢,階段二就能縮短佈署週期,階段三才是深度最佳化。這種漸進式路徑,對 PCA 考試中出現的「brown-field migration」情境都適用。
🎯 關鍵設計決策
| 決策 | 選這個的理由 | 替代方案 |
|---|---|---|
| 用 Cloud Interconnect 維持混合雲過渡期 | 10Gbps 專線提供穩定低延遲,讓地端舊系統與雲端新系統能長期並行運作,不被迫一次切換 | IPSec VPN(頻寬與穩定性不夠)、全面斷網切換(風險太高) |
| 前端改寫成 Cloud Run 而非 GKE | 電商前端多為無狀態 HTTP,Cloud Run 免維運、按請求計費,搭配 Cloud Build 做 CI/CD 極簡單 | GKE(對 DevOps 能力斷層的團隊負擔太重)、App Engine Standard(語言與 runtime 受限) |
| 資料庫拆成 Cloud SQL + Firestore 組合 | 交易類資料需要 ACID → Cloud SQL;使用者偏好、購物車等彈性結構資料 → Firestore,各取所長 | 全部用 Cloud SQL(schema 僵化)、全部用 Spanner(成本過高、無必要) |
📝 PCA 考點拆解
考點 1:遷移策略選擇(6 R's)
PCA 很愛考「rehost vs replatform vs refactor」的取捨。看到題目強調「最快上線」選 rehost;強調「享受 cloud-native 好處」選 replatform;強調「長期最佳化」才考慮 refactor。Dress4Win 這類案例通常是「先 rehost 再逐步 replatform」。
考點 2:混合雲連線選型
連線地端與 GCP 時,Cloud VPN 適合低流量測試環境;Partner Interconnect 適合 50Mbps-10Gbps 中等穩定需求;Dedicated Interconnect 適合 10Gbps+ 生產流量與跨國公司。依題目流量描述倒推正確選項。
考點 3:CI/CD 現代化工具鏈
看到「縮短佈署週期」「自動化測試」,答案通常是 Cloud Build + Artifact Registry + Cloud Deploy。要能識別 Cloud Build 做 CI、Artifact Registry 存 container image、Cloud Deploy 做多環境 promotion。
🔗 延伸閱讀
- Google Cloud 官方 PCA exam guide — 原始情境敘述來源
- GCP 遷移指南 — Getting Started — 官方建議的遷移路徑與工具
- Cloud Interconnect 文件 — 混合雲連線選型官方指南
- GCP Architecture Framework — 可靠性、效能、成本等支柱的系統化設計原則