欢迎使用 FlowZap,快速、清晰、掌控的绘图应用。

无服务器多云架构

Architecture

多云无服务器架构图,展示基于 DNS 的流量路由在 AWS 和 Azure 区域之间切换、健康检查失败时的自动故障转移以及跨云提供商的双向数据复制与冲突解决。该模板模拟多云策略以实现最大可用性和供应商独立性,使用 AWS(Lambda、DynamoDB)和 Azure(Functions、Cosmos DB)的无服务器服务。对于需要云提供商冗余的企业至关重要。

完整 FlowZap 代码

TrafficManager { # Global Traffic Manager
n1: circle label:"User Request"
n2: rectangle label:"DNS-Based Routing"
n3: diamond label:"Primary Cloud Healthy?"
n4: rectangle label:"Route to Primary (AWS)"
n5: rectangle label:"Failover to Secondary (Azure)"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> n3.handle(left)
n3.handle(right) -> n4.handle(left) [label="Healthy"]
n3.handle(bottom) -> n5.handle(top) [label="Unhealthy"]
n4.handle(bottom) -> AWS.n6.handle(top) [label="Forward"]
n5.handle(bottom) -> Azure.n11.handle(top) [label="Forward"]
}
AWS { # AWS Region
n6: rectangle label:"API Gateway"
n7: rectangle label:"Lambda Functions"
n8: rectangle label:"DynamoDB"
n9: rectangle label:"S3 Storage"
n10: rectangle label:"CloudWatch Monitoring"
n6.handle(right) -> n7.handle(left) [label="Invoke"]
n7.handle(right) -> n8.handle(left) [label="Read/Write"]
n7.handle(bottom) -> n9.handle(top) [label="Store"]
n10.handle(top) -> TrafficManager.n3.handle(bottom) [label="Health Check"]
}
Azure { # Azure Region
n11: rectangle label:"Azure API Management"
n12: rectangle label:"Azure Functions"
n13: rectangle label:"Cosmos DB"
n14: rectangle label:"Blob Storage"
n15: rectangle label:"Azure Monitor"
n11.handle(right) -> n12.handle(left) [label="Invoke"]
n12.handle(right) -> n13.handle(left) [label="Read/Write"]
n12.handle(bottom) -> n14.handle(top) [label="Store"]
n15.handle(top) -> TrafficManager.n3.handle(bottom) [label="Health Check"]
}
DataSync { # Cross-Cloud Sync
n16: rectangle label:"Event Bridge"
n17: rectangle label:"Bi-Directional Replication"
n18: rectangle label:"Conflict Resolution"
n16.handle(right) -> n17.handle(left) [label="CDC Events"]
n17.handle(right) -> n18.handle(left) [label="Last-Write-Wins"]
n17.handle(top) -> AWS.n8.handle(bottom) [label="Sync"]
n17.handle(top) -> Azure.n13.handle(bottom) [label="Sync"]
}

为什么需要这个工作流?

Relying on a single cloud provider creates vendor lock-in risk and single points of failure at the provider level. A multi-cloud serverless architecture distributes workloads across AWS and Azure, providing automatic failover, negotiating leverage, and compliance with data sovereignty requirements.

工作原理

  1. Step 1: A global traffic manager routes requests based on DNS health checks.
  2. Step 2: If the primary cloud (AWS) is healthy, traffic routes to AWS Lambda and DynamoDB.
  3. Step 3: If the primary fails health checks, traffic automatically fails over to Azure Functions and Cosmos DB.
  4. Step 4: Bi-directional data replication keeps both clouds synchronized.
  5. Step 5: Conflict resolution (last-write-wins) handles concurrent writes during split-brain scenarios.
  6. Step 6: Both clouds report health status back to the traffic manager for continuous monitoring.

替代方案

Single-cloud with multi-region provides simpler redundancy within one provider. Kubernetes abstracts cloud differences but adds operational complexity. This template shows true multi-cloud failover with serverless services.

Key Facts

Template Name无服务器多云架构
CategoryArchitecture
Steps6 workflow steps
FormatFlowZap Code (.fz file)

相关模板

无服务器 Step Functions 编排架构

Architecture

AWS Step Functions 编排架构图,展示状态机工作流,包括选择状态、并行处理、等待回调模式以及失败步骤的补偿回滚。该模板模拟无服务器工作流编排,复杂的多步骤流程定义为具有内置错误处理和重试逻辑的状态机。对于构建需要人工审批或长时间运行流程的可靠无服务器工作流的团队至关重要。

微服务 API 网关架构

Architecture

微服务 API 网关架构图,展示请求路由、JWT 身份验证、速率限制、服务发现以及跨分布式后端服务的响应聚合。该模板模拟微服务生态系统中所有客户端流量的入口点,在请求到达内部服务之前执行安全策略。适合设计具有集中式横切关注点的可扩展 API 基础设施的平台工程师。

微服务服务网格架构

Architecture

服务网格架构图,展示 Istio 或 Linkerd 边车代理处理 mTLS 加密、流量策略、熔断器和跨微服务的分布式追踪。该模板可视化服务网格如何将网络关注点从应用代码中抽象出来,实现服务间的零信任通信。对于采用服务网格基础设施以提升可观测性和安全性的团队至关重要。

微服务每服务独立数据库架构

Architecture

每服务独立数据库架构图,每个微服务拥有其专用数据存储,通过 Kafka 进行事件驱动同步以实现跨服务数据一致性。该模板展示了微服务数据隔离的核心原则,展示 PostgreSQL 和 MongoDB 如何在多语言持久化策略中共存。对于在保持最终一致性的同时强制服务自治的架构师至关重要。

按业务能力分解微服务架构

Architecture

按业务能力组织的微服务分解架构图:身份认证、产品目录、定价和订单履行,每个都有独立的数据存储和 API。该模板展示如何将单体应用拆分为与业务领域对齐的服务,使用 Backend-for-Frontend (BFF) 模式进行客户端特定的聚合。适合规划领域驱动微服务边界的架构师。

微服务绞杀者模式迁移架构

Architecture

绞杀者模式迁移架构图,展示使用路由层在新旧系统之间分流流量,逐步用新微服务替换遗留单体应用。该模板模拟经过验证的迁移策略,新功能作为微服务构建,遗留端点逐步退役。对于在不进行高风险大爆炸重写的情况下现代化遗留系统的团队至关重要。

返回所有模板