PCA 雲端架構師之旅

看到 PCA 案例題，先別急著選服務。把業務目標、硬性限制和相關角色讀清楚，再談架構。

案例裡的「使用者」到底是誰？先分出幾種角色與使用方式，後面的 SLO、API 和儲存選擇才有依據。

「使用者要快一點」還不能拿來設計架構。把角色、動作和驗收條件寫成 User Story，再接到 SLI／SLO。

可用性寫 99.99%，到底量的是什麼？從 User Story 定出 SLI，再設定能負擔也能驗證的 SLO。

微服務要怎麼拆，才不會只是把單體分成更多難維護的部分？從團隊責任、資料和變更頻率找邊界。

API 發布後要改欄位、處理重試，該怎麼設計才不會讓串接者受傷？用登雲書店看版本、冪等和錯誤回應。

先別急著選 Cloud SQL 或 Firestore。把資料量、讀寫方式、一致性和保存期限列出來，選型才有根據。

資料的讀寫需求已經列好了，下一步怎麼選服務？沿著檔案、交易、文件、分析等路徑縮小範圍。

GCP 負載平衡器種類很多，先用流量協定、對外或對內、全域或區域三個問題縮小選項。

把 Region、Zone、VPC、Subnet、DNS 和負載平衡器畫在同一張圖上，檢查請求到底怎麼走。

一台機器壞了或流量突然變多，服務能不能繼續？分開檢查可靠性與擴展性，再找共同設計。

整個區域無法使用時，多久要恢復、最多能丟多久的資料？用 RTO／RPO 比較幾種災難復原做法。

架構圖畫好了，權限與帳單也要交代清楚。從 IAM、網路邊界到主要服務費用，檢查方案能否落地。