📚 课程目录第2章多云基础

多云基础：主流云平台核心服务对比、多云策略与场景

核心原理：为什么需要“多云”而非“单云”

在AI DevOps的落地实践中，企业往往不会只绑定一家云厂商。所谓多云（Multi-Cloud），是指同时使用AWS、Azure、GCP等两家或以上公有云平台，将不同工作负载分布到最适合的云上。其核心驱动力并非“技术炫技”，而是来自四个现实诉求：

规避供应商锁定：单一云厂商的API、服务配额、定价策略都可能成为长期约束，多云保留了谈判与迁移的主动权。
利用各自优势：AWS的生态最全、Azure的企业级与AD集成最好、GCP的数据分析与AI/ML平台最突出。AI训练任务放在GCP，生产业务放在AWS，可各取所长。
容灾与高可用：区域性故障（如可用区断电、网络中断）时，流量可切换至另一朵云，实现跨云容灾。
合规与数据驻留：某些行业要求数据必须存储在特定国家或地区，多云可满足不同司法辖区的合规要求。

但多云也带来显著挑战：网络延迟、身份认证不统一、成本账单分散、运维工具碎片化。这正是AI DevOps需要解决的——通过基础设施即代码（IaC）与自动化流水线，将多云差异封装起来，让开发团队无感使用底层资源。

核心认知：多云不是“多买几台机器”，而是“多套API、多套IAM、多套网络策略”的统一抽象。DevOps的自动化程度越高，多云的管理成本才越可控。

三大云平台核心服务对比

下表从AI DevOps最关心的维度，对比AWS、Azure、GCP的核心服务。注意，同一类服务在不同云上的命名与抽象层级差异很大，这直接影响IaC代码的编写方式。

能力维度	AWS	Azure	GCP
计算（虚拟机）	EC2	Virtual Machines	Compute Engine
容器编排	EKS（Kubernetes）	AKS	GKE
Serverless 函数	Lambda	Functions	Cloud Functions
对象存储	S3	Blob Storage	Cloud Storage
托管数据库（PostgreSQL）	RDS for PostgreSQL	Database for PostgreSQL	Cloud SQL for PostgreSQL
AI/ML平台	SageMaker	Azure ML	Vertex AI
IaC 原生工具	CloudFormation	ARM / Bicep	Deployment Manager
身份认证	IAM（用户/角色/策略）	Entra ID（原Azure AD）+ RBAC	Cloud IAM
监控与日志	CloudWatch	Monitor / Log Analytics	Cloud Monitoring / Logging

从DevOps自动化视角，最关键的差异在于IAM模型与服务配额。AWS IAM以“策略文档（JSON）”为核心，Azure RBAC以“角色分配”为核心，GCP IAM则以“角色绑定到成员”为核心。编写跨云流水线时，必须为每个云单独定义认证凭证，并注意各云对资源命名的全局唯一性要求（如AWS S3桶名全局唯一，Azure存储账户名也全局唯一）。

方法流程：多云策略的三种典型模式

并非所有场景都需要“同时运行”多朵云。根据业务目标，多云策略通常分为以下三种模式，每种模式的DevOps自动化侧重点不同。

模式一：故障转移型（Active-Passive）
主业务运行在AWS，GCP作为冷备或温备。通过DNS（如Route53或Cloud DNS）实现健康检查与自动切换。此模式要求两朵云上的镜像、数据库备份必须持续同步。
模式二：负载分担型（Active-Active）
同一应用同时部署在Azure与GCP，通过全局负载均衡器（如Azure Front Door或GCP Global Load Balancer）分发流量。此模式对应用的无状态化要求极高，会话数据必须外置到Redis或数据库。
模式三：服务选型型（Best-of-Breed）
AI训练跑在GCP（利用TPU），业务API跑在AWS（利用Lambda与API Gateway），数据分析跑在Azure（利用Synapse）。此模式最复杂，需要处理跨云数据同步与网络互通（通常通过云间专线或VPN）。

案例/场景：AI推理服务的多云容灾实战

假设某智能客服公司需要部署一个基于大模型的推理服务，要求SLA达到99.95%，且必须满足欧盟与北美两地的数据驻留法规。最终架构设计如下：

训练侧：使用GCP Vertex AI + TPU v5e进行模型微调，训练产物（模型权重）导出至GCS，并通过事件触发器同步到AWS S3（跨区域复制）。
推理侧：主集群部署在AWS EKS（法兰克福区域），使用SageMaker作为弹性补充；备集群部署在Azure AKS（弗吉尼亚区域），通过Azure Front Door进行全局流量分发。
数据同步：用户会话数据写入Aurora Global Database（AWS），通过MySQL binlog同步到Azure Database for MySQL，实现双向同步（实际为单向主从）。
DevOps流水线：GitLab CI中定义三个部署阶段：build（构建Docker镜像并推送至三个云的镜像仓库）、deploy-aws（使用Terraform更新EKS部署）、deploy-azure（使用Helm更新AKS）。

# 流水线关键片段（.gitlab-ci.yml）
stages: [build, deploy-aws, deploy-azure]

build:
  stage: build
  script:
    - docker build -t ${IMAGE_TAG} .
    - docker push ${AWS_ECR_URL}/${IMAGE_TAG}
    - docker push ${AZURE_ACR_URL}/${IMAGE_TAG}
    - docker push ${GCP_GCR_URL}/${IMAGE_TAG}

deploy-aws:
  stage: deploy-aws
  script:
    - cd terraform/envs/aws
    - terraform init -backend-config="bucket=${TF_STATE_BUCKET}"
    - terraform apply -auto-approve -var="image_tag=${IMAGE_TAG}"
  environment: production-aws

deploy-azure:
  stage: deploy-azure
  script:
    - cd terraform/envs/azure
    - terraform init -backend-config="storage_account_name=${TF_STATE_SA}"
    - terraform apply -auto-approve -var="image_tag=${IMAGE_TAG}"
  environment: production-azure
  when: manual  # 生产环境需要人工确认

该方案中，Terraform的远端状态（Remote State）必须分云存储，避免锁冲突。同时，每个云提供独立的服务账号（AWS IAM Role、Azure Service Principal、GCP Service Account），密钥统一托管在Vault中，流水线通过OIDC动态获取临时凭证，而非硬编码。

误区与复盘：多云落地中的常见陷阱

误区一：盲目追求“完全一致”的多云抽象。试图用一层封装屏蔽所有云差异，结果导致无法使用各云的高级特性（如AWS Lambda的容器镜像支持、GCP的Live Migration）。正确做法是：抽象80%的通用能力（计算、存储、网络），保留20%的差异化能力通过条件判断注入。

误区二：忽略网络成本与延迟。跨云数据传输通常按GB计费，且公网延迟远高于云内延迟。若AI训练频繁读取另一朵云上的数据集，会产生高昂的流量费。复盘建议：将高频数据在本地云各存一份，通过对象存储的事件通知触发增量同步，而非实时跨云读取。

误区三：多云环境下的“配置漂移”失控。当AWS、Azure、GCP三套环境分别由不同团队维护时，很容易出现某朵云的VPC网段、安全组规则与其他云不一致。必须使用Terragrunt或Atlantis等工具统一管理Terraform代码，并设置定时drift detection任务，每周自动比对实际资源与代码定义。

最后复盘一个真实教训：某团队在故障转移演练时，发现DNS切换后，Azure上的应用无法连接AWS上的数据库，因为安全组只允许来自AWS VPC的IP访问。这提醒我们——多云环境中的网络安全组、防火墙规则、路由表必须纳入版本控制，并作为流水线的一部分进行跨云联调测试。建议在非生产环境每周执行一次“故障注入”演练（如用Chaos Mesh随机终止一个云上的Pod），验证自动恢复链路是否真正畅通。