关于 multi-cloud-architecture
为 AWS、Azure 和 GCP 上的应用架构提供决策框架与模式,面向规划多云策略、迁移和成本优化的团队。内容涵盖服务比较、架构模式、迁移阶段及环境验证注意事项。
主要功能
- 01比较 AWS、Azure 和 GCP 服务
- 02规划多云架构模式
- 03设计云无关抽象层
- 04分阶段制定迁移策略
- 05评估成本与优化方案
适用场景
- 01为新工作负载选择云服务
- 02规划跨云灾难恢复
- 03将应用迁移到另一云平台
- 04评估多云部署成本
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ sickn33/ agentic-awesome-skills --skill multi-cloud-architecture安装后在 Claude Code 中输入/multi-cloud-architecture确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
UPSTREAM-NOTICE.mdUPSTREAM-LICENSE.txtreferences/service-comparison.mdmulti-cloud-patterns.md详细介绍
捆绑的上游支持文件
支持文件位于相对于技能的路径中。有关其固定来源、许可证、哈希值和导入变更,请参阅 UPSTREAM-NOTICE.md。
多云架构
用于在 AWS、Azure 和 GCP 上设计应用程序的决策框架和模式。
请勿在以下情况下使用此技能
- 任务与多云架构无关
- 你需要此范围之外的其他领域或工具
说明
- 明确目标、约束和所需输入。
- 应用相关最佳实践并验证结果。
- 提供可执行的步骤和验证方法。
目的
设计与云无关的架构,并在不同云服务提供商之间做出明智的服务选择。
在以下情况下使用此技能
- 设计多云策略
- 在云服务提供商之间迁移
- 为特定工作负载选择云服务
- 实施与云无关的架构
- 优化跨云服务提供商的成本
服务行按广泛用途分组,并非可直接替换的等效服务。Azure SQL Database 并非 PostgreSQL/MySQL,Event Hubs 的 Kafka 兼容性并不涵盖完整的 Kafka 功能集,S3 兼容 API 也各不相同。请核实当前服务可用性、区域和合规限制,以及实际应用契约。多云复制需要明确设计一致性/冲突处理、RPO/RTO、身份验证和故障切回;仅按地理位置部署并不能确保符合数据主权要求。在做出承诺前,请评估双轨运行、网络/出口流量、备份和团队成本;下方的 30–70% 节省幅度只是历史示例范围,并非报价或购买承诺方案的建议。
云服务对比
计算服务
| AWS | Azure | GCP | 用例 |
|---|---|---|---|
| EC2 | Virtual Machines | Compute Engine | IaaS 虚拟机 |
| ECS | Container Instances | Cloud Run | 容器 |
| EKS | AKS | GKE | Kubernetes |
| Lambda | Functions | Cloud Functions | 无服务器 |
| Fargate | Container Apps | Cloud Run | 托管容器 |
存储服务
| AWS | Azure | GCP | 用例 |
|---|---|---|---|
| S3 | Blob Storage | Cloud Storage | 对象存储 |
| EBS | Managed Disks | Persistent Disk | 块存储 |
| EFS | Azure Files | Filestore | 文件存储 |
| Glacier | Archive Storage | Archive Storage | 冷存储 |
数据库服务
| AWS | Azure | GCP | 用例 |
|---|---|---|---|
| RDS | SQL Database | Cloud SQL | 托管 SQL |
| DynamoDB | Cosmos DB | Firestore | NoSQL |
| Aurora | PostgreSQL/MySQL | Cloud Spanner | 分布式 SQL |
| ElastiCache | Cache for Redis | Memorystore | 缓存 |
**参考:**完整对比请参阅 references/service-comparison.md
多云模式
模式 1:单一服务提供商加灾难恢复
- 在一个云中运行主要工作负载
- 在另一个云中进行灾难恢复
- 跨云复制数据库
- 自动故障转移
模式 2:择优选用
- 使用各服务提供商的最佳服务
- 在 GCP 上运行 AI/ML
- 在 Azure 上运行企业应用
- 在 AWS 上运行通用计算
模式 3:地理分布
- 通过最近的云区域为用户提供服务
- 符合数据主权要求
- 全局负载均衡
- 区域故障转移
模式 4:与云无关的抽象
- 使用 Kubernetes 进行计算
- 使用 PostgreSQL 作为数据库
- 使用 S3 兼容存储(MinIO)
- 使用开源工具
与云无关的架构
使用云原生替代方案
- **计算:**Kubernetes(EKS/AKS/GKE)
- **数据库:**PostgreSQL/MySQL(RDS/SQL Database/Cloud SQL)
- **消息队列:**Apache Kafka(MSK/Event Hubs/Confluent)
- **缓存:**Redis(ElastiCache/Azure Cache/Memorystore)
- **对象存储:**S3 兼容 API
- **监控:**Prometheus/Grafana
- **服务网格:**Istio/Linkerd
抽象层
Application Layer
↓
Infrastructure Abstraction (Terraform)
↓
Cloud Provider APIs
↓
AWS / Azure / GCP
成本对比
计算定价因素
- **AWS:**按需、预留、Spot、Savings Plans
- **Azure:**按需付费、预留、Spot
- **GCP:**按需、承诺使用、抢占式
成本优化策略
- 使用预留/承诺容量(节省 30-70%)
- 利用竞价/可抢占实例
- 合理配置资源
- 对负载可变的工作负载使用无服务器方案
- 优化数据传输成本
- 实施生命周期策略
- 使用成本分配标签
- 使用云成本工具进行监控
**参考:**参见 references/multi-cloud-patterns.md
迁移策略
阶段 1:评估
- 清点当前基础设施
- 识别依赖项
- 评估云兼容性
- 估算成本
阶段 2:试点
- 选择试点工作负载
- 在目标云中实施
- 进行全面测试
- 记录经验
阶段 3:迁移
- 逐步迁移工作负载
- 保持双运行期
- 监控性能
- 验证功能
阶段 4:优化
- 合理配置资源
- 实施云原生服务
- 优化成本
- 增强安全性
最佳实践
- 使用基础设施即代码(Terraform/OpenTofu)
- 为部署实施 CI/CD 流水线
- 跨云按故障场景进行设计
- 尽可能使用托管服务
- 实施全面监控
- 自动化成本优化
- 遵循安全最佳实践
- 记录云平台特定配置
- 测试灾难恢复流程
- 培训团队使用多个云平台
参考文件
references/service-comparison.md- 完整的服务对比references/multi-cloud-patterns.md- 架构模式
相关技能
terraform-module-library- 用于 IaC 实施cost-optimization- 用于成本管理hybrid-cloud-networking- 用于连接
限制
- 仅当任务明确符合上述范围时才使用此技能。
- 不要将输出视为针对特定环境进行验证、测试或专家审查的替代品。
- 如果缺少必需的输入、权限、安全边界或成功标准,请暂停并请求澄清。
评论
支持 Markdown