多雲戰略和遷移

1）為什麼要多雲以及何時有理由

目標：業務連續性（提供商儲備），數據/司法管轄區主權，價值/折扣優化，獲得最佳托管服務（ML/antifrod/analytics）。
權衡：運營復雜性增加，能力重復，網絡成本降低。
關鍵：為了速度/價格，提前確定在哪裏需要便攜性，在哪裏允許先行者鎖定。

2）目標架構模型

可移植核心：關鍵核心（API，域服務，數據）-可攜帶（K8s，Postgres，Kafka，Redis，MinIO/Vault）；外圍設備-自然管理。
Active-Active Multi-Cloud：兩個雲一次服務於流量（復雜：數據沖突，全局路由）。
Active-Passive （Hot/Warm）：一個是主幹,第二個是熱/熱DR。
Hybrid：雲中的正時/部分部分（通常用於法律/PII限制）。

3）可移植性模式

Kubernetes作為基本平臺（alias：EKS/GKE/AKS/on-prem K8s）。

Service Mesh (mTLS, traffic shifting, locality/failover;Istio/Linkerd).

IaC： Terraform+模塊化抽象；для K8s — Helm/Kustomize + GitOps (Argo/Flux).

秘密：HashiCorp Vault/外部秘密操作員；KMS/HSM上的抽象。
存儲：Postgres（運算符/Patroni），Kafka（運算符/MirrorMaker2），Redis（哨兵/群集），S3兼容（MinIO）以實現API統一。
可觀察性：OpenTelemetry+供應商中性後端（Prometheus/Tempo/Loki/ClickHouse）。
身份驗證：OIDC/OAuth2（Keycloak/Auth0/Entra/Google），統一聯盟。
API層：Envoy/NGINX/Contour+通用策略（CORS，授權標題，限制等級）。

4）遷移策略（7R-簡述）

Rehost（Lift-and-Shift）：快速，無回收；對statless/VM有利，對成本不利。
Replatform：遷移到K8s/簡化依賴關系（風險小於refactor）。
Refactor/Repurchase：以可移植模式重寫,或用SaaS服務替換。
Retain/Retire：離開/退役不需要搬運的東西。

實踐：從服務註冊表（關鍵性，RTO/RPO，SLO，依賴性）開始，組成遷移波（跨域）。

5）數據和一致性

復制/CDC：Postgres/MySQL的Debezium/Straim Log；Kafka MirrorMaker2用於斧頭。
雙向同步：僅在嚴格的等容和旋轉鍵（矢量clock/updated_at)下。
Dual-write帶有重復數據消除功能：記錄標記為「Idempotency-Key」/「event_id」+outbox/inbox以確保交付。
所有權分離：領導者區域/雲對鍵/天線以避免沖突。
現金：本地區域；僅通過事件/TTL進行全局緩存（沒有具有強一致性的「共享」全局緩存）。

6）全球流量和網絡

GSLB/DNS：latency/geo-routing+health-checks，加那利群島/failover的權重。
Anycast/Edge/CDN靠近用戶,然後鋪設到最近的健康區域/雲。
直接通道：在雲/前端之間進行互連/ExpressRoute/Direct Connect以減少隱性/隱性。
客戶策略：短時間,指數backoff+jitter,叠代回程,寫操作的冪等。

7）安全性和合規性

mTLS無處不在（mesh+SPIFFE/SPIRE或本機PKI）。
KMS/HSM：通過Vault抽象API；按鍵分割管轄權/特南特。
IAM：單一角色和組模型（SCIM/SSO），最小特權政策，時間權證（STS）。
保密/輪換：代幣/密碼自動輪換；鎖定「長」靜態密鑰。
合規性：PCI DSS/GDPR-數據駐留、隔離審計日誌、地理單元。

8）可觀察性，SLO和錯誤預算

所有雲中的RED/USE+traces+profile信號；單一登錄格式（JSON +'trace_id）。
基於Trace采樣尾巴：保存錯誤/p99、「cloud」、「region」、「tenant」上的段。
SLO per雲/區域+總體；在burn-rate（多窗口）上。
加那利群島的「遷移前/遷移後」dashbords，回歸報告。

9） CI/CD和configs管理

GitOps：通過Helm values/Kustomize overlays的統一圖像文物,configa-按環境/區域。
通過外部秘密操作員（通往AWS/GCP/Azure秘密存儲庫的橋梁）進行秘密操作。
促銷流：dev → staging → canary（cloud A）→ canary（cloud B）→ full。
發布遊戲：在流量增加之前檢查SLO/合成/合同測試。

10）成本和FinOps

考慮雲之間的egress票價，RI/CUD/Savings Plans折扣，市場樂隊。
第80/20條規則：只攜帶20%的最大業務風險；剩下的就是更便宜/更容易的地方。
Downsampling指標，冷存儲邏輯，跟蹤限制（budget-aware采樣）。
資源標簽：「env」，「team」，「service」，「tenant」，「cost_center」-用於透明計費。

11）遷移計劃（劇本）

11.1個培訓

1.服務/數據/依存關系清單；目標RTO/RPO/SLO。
2.選擇模型（active-active vs active-passive）和網絡層（GSLB/Anycast）。
3.在目標雲中準備沙箱：K8s集群，mesh，observability，秘密。

11.2運行和驗證

4.Shadow-traffic：對查詢進行鏡像而不會影響探測。
5.合同測試（OpenAPI/gRPC/CDC）和關鍵路由上的合成。
6.CDC/復制：熱數據同步、一致性核對。

11.3切換

7.雙write（相等）有限的用戶/tenant百分比。
8.帶有SLO門的分階段交通交換（1%→10%→50%→100％）。
9.Freeze/移動狀態；租用最終的cutover；將舊路徑保持在「只讀」狀態，直到最終重新定位。

11.4遷移後

10.審核登錄記錄/日誌檢查,舊快照存檔,egress/cache優化。
11.更新runbooks和呼叫學習。

12） DR和容錯測試

GameDay：關閉整個雲/區域；衡量實際的RTO/RPO。
混沌註射：跨鏈接包丟失/潛伏期增加，經紀人/基地下降。
自動降級標誌：禁用「昂貴」的幻燈片,改用「stale-wile-revalidate」緩存。

13）反模式

無數據所有權協議的「幹凈」主動活動→沖突/重復。
具有強一致性的通用全局緩存-潛伏性/擁塞性。
無止境的恢復→重復註銷/訂單。
雲中不同的邏輯/跟蹤格式是相關性的喪失。
沒有統一的IAM/秘密模型。
「一勞永逸」遷移，沒有波浪和門。

14） iGaming/財務細節

司法管轄區和數據駐留：PII/支付日誌保持「在國家/地區內部」，跨雲僅保留單元/匿名。
支付提供商：按雲/地區分列的PSP和智能路由；webhooks-通過全球重復數據消除經紀商。
制裁/合規過濾器：區域概況；在允許的PSP上快速失敗。
SLO「金錢之路」高於一般方式；個別的Alerta/Deschbords per供應商/地區。
審計：不變事務日誌，同步寫入兩個獨立存儲（WORM/S3對象鎖）。

15）準備就緒支票清單

• 選擇目標模型（可移植核心/主動/待機）；RTO/RPO/SLO描述。
• IaC/GitOps：模塊化Terraform/Helm/Kustomize；一個混亂和安全政策。
• 可觀察性：在所有環境中的OTel；通用日誌格式；tail-sampling 按錯誤/p99。
• 數據：CDC配置；雙重寫作是冪等的；有一個解決沖突的計劃。

[] GSLB/DNS/Anycast и health-checks;帶有SLO門的分階段交通轉移。

• 秘密和KMS：通過Vault進行抽象；輪換；按地區劃分。
• FinOps：價值模型，價值限制，標簽和配額；成本報告。
• 進行了一次人力資源演習；測量實際RTO/RPO；更新了runbooks。
• API/事件合同在兩個雲端進行驗證；監視webhook。
• 適用於iGaming/finance： data residency, multi-PSP routing, WORM期刊。

16) TL;DR

構建可移植核心（K8s+IaC+mesh+OTel+Vault）,並根據RTO/RPO/SLO業務目標和成本選擇多倍模式。轉移成為波浪：shadow-traffic → CDC → dual-write →使用SLO門的分階段流量。通過偶數和outbox/inbox管理數據,通過GSLB/Anycast管理流量,通過mTLS/KMS/Vault管理安全性。對於iGaming，是嚴格的數據駐留和多個PSP規則，分別用於「現金」路徑的SLO。