多云战略和迁移
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。