Back to Details

cloud-architecture

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Cloud Architecture

云架构

Design cloud architecture that aligns with the standards defined in your 
Platform-Engineering-Constitution.md
.
设计符合您
Platform-Engineering-Constitution.md
中定义标准的云架构。

Workflow

工作流程

  1. Read the platform constitution. Load 
    Platform-Engineering-Constitution.md
    from the repository root. Extract approved providers, regions, compute platforms, IaC tooling, naming conventions, tagging requirements, and network topology.
  2. Understand the workload. Ask what the application does, its traffic patterns, data requirements, and non-functional requirements (availability, latency, compliance).
  3. Propose architecture constrained by the constitution. Only recommend approved providers, regions, and tooling.
  4. Generate an Architecture Decision Record (ADR) documenting the design, trade-offs, and alternatives considered.
  5. Scaffold IaC using the approved tooling and module conventions from the constitution.
  6. Map to Radius resource types where applicable — use portable types so the same app.bicep works across environments.
  1. 阅读平台章程。从仓库根目录加载
    Platform-Engineering-Constitution.md
    。提取已批准的供应商、区域、计算平台、IaC工具、命名规范、标签要求和网络拓扑。
  2. 了解工作负载。询问应用程序的功能、流量模式、数据需求和非功能需求（可用性、延迟、合规性）。
  3. 提出符合章程约束的架构。仅推荐已批准的供应商、区域和工具。
  4. 生成架构决策记录（ADR），记录设计方案、权衡因素和考虑过的替代方案。
  5. 使用章程中批准的工具和模块规范搭建IaC脚手架。
  6. 在适用情况下映射到Radius资源类型——使用可移植类型，确保同一个app.bicep可在不同环境中运行。

Data Gathering Questions

数据收集问题

Ask these interactively, one at a time:
交互式逐一询问以下问题：

Workload Identity

工作负载标识

  • What does the application do? Brief description of the service.
  • What are its components? (e.g., web frontend, API backend, worker, scheduled jobs)
  • 应用程序的功能是什么？ 服务的简要描述。
  • 它包含哪些组件？（例如：Web前端、API后端、工作进程、定时任务）

Dependencies

依赖项

  • What data stores does it need? (PostgreSQL, Redis, MongoDB, blob storage, etc.)
  • What external services does it integrate with? (third-party APIs, message queues, email, etc.)
  • Does it need to communicate with other internal services?
  • 需要哪些数据存储？（PostgreSQL、Redis、MongoDB、对象存储等）
  • 需要集成哪些外部服务？（第三方API、消息队列、邮件服务等）
  • 是否需要与其他内部服务通信？

Traffic & Scale

流量与规模

  • Expected traffic volume? (requests/sec, concurrent users)
  • Does it need auto-scaling? (horizontal pod autoscaler, node autoscaler)
  • Any burst traffic patterns? (event-driven spikes)
  • 预期流量规模？（请求/秒、并发用户数）
  • 是否需要自动扩缩容？（水平Pod扩缩容、节点扩缩容）
  • 是否存在突发流量模式？（事件驱动型流量峰值）

Non-Functional Requirements

非功能需求

  • Availability target? (99.9%, 99.99%, etc.)
  • Latency requirements? (p99 response time)
  • Data residency / compliance constraints? (beyond what's in the constitution)
  • 可用性目标？（99.9%、99.99%等）
  • 延迟要求？（p99响应时间）
  • 数据驻留/合规约束？（超出章程规定的内容）

Deployment Strategy

部署策略

  • Environments needed? (dev, staging, production — or the constitution's standard set)
  • Multi-region / multi-cloud? Or single region per the constitution?
  • CI/CD pipeline? (GitHub Actions, Azure DevOps, etc.)
  • 需要哪些环境？（开发、预发布、生产——或章程规定的标准环境集）
  • 多区域/多云部署？ 还是按照章程采用单区域部署？
  • CI/CD流水线？（GitHub Actions、Azure DevOps等）

Architecture Output Format

架构输出格式

Architecture Diagram (ASCII)

ASCII架构图

Provide an ASCII architecture diagram showing the key components and their relationships:
┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│   Ingress   │────▶│  Frontend   │────▶│   Backend   │
│  (Gateway)  │     │  (Node.js)  │     │    (Go)     │
└─────────────┘     └─────────────┘     └──────┬──────┘
                                               │
                                    ┌──────────┼──────────┐
                                    ▼          ▼          ▼
                              ┌──────────┐ ┌───────┐ ┌────────┐
                              │PostgreSQL│ │ Redis │ │ Blob   │
                              │  (RDS/   │ │(Elast-│ │Storage │
                              │  Azure)  │ │iCache)│ │        │
                              └──────────┘ └───────┘ └────────┘
提供ASCII架构图，展示关键组件及其关系：
┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│   Ingress   │────▶│  Frontend   │────▶│   Backend   │
│  (Gateway)  │     │  (Node.js)  │     │    (Go)     │
└─────────────┘     └─────────────┘     └──────┬──────┘
                                               │
                                    ┌──────────┼──────────┐
                                    ▼          ▼          ▼
                              ┌──────────┐ ┌───────┐ ┌────────┐
                              │PostgreSQL│ │ Redis │ │ Blob   │
                              │  (RDS/   │ │(Elast-│ │Storage │
                              │  Azure)  │ │iCache)│ │        │
                              └──────────┘ └───────┘ └────────┘

Architecture Decision Record (ADR)

架构决策记录（ADR）

markdown
undefined
markdown
undefined

ADR-NNN: <Title>

ADR-NNN: <标题>

Status

状态

Proposed | Accepted | Superseded
提议 | 已接受 | 已取代

Context

背景

What is the problem or requirement?
存在什么问题或需求？

Decision

决策

What architecture was chosen and why?
选择了什么架构，原因是什么？

Consequences

影响

What are the trade-offs? What are we giving up?
有哪些权衡？我们需要放弃什么？

Alternatives Considered

考虑过的替代方案

What other approaches were evaluated?
还评估了哪些其他方法？

Constitution Alignment

与章程的一致性

How does this align with the platform engineering constitution?
  • Providers: ✅ Uses approved provider(s)
  • Regions: ✅ Deploys to approved region(s)
  • Compute: ✅ Uses approved compute platform
  • IaC: ✅ Uses approved tooling
  • Naming: ✅ Follows naming convention
  • Tags: ✅ Includes required tags
undefined
该架构如何符合平台工程章程？
  • 供应商：✅ 使用已批准的供应商
  • 区域：✅ 部署在已批准的区域
  • 计算平台：✅ 使用已批准的计算平台
  • IaC：✅ 使用已批准的工具
  • 命名：✅ 遵循命名规范
  • 标签：✅ 包含必填标签
undefined

Resource Mapping

资源映射

Map application needs to Radius resource types and cloud services:
NeedRadius Resource TypeAzure ImplementationAWS Implementation
SQL Database
Radius.Data/postgreSqlDatabases
Azure Database for PostgreSQLAmazon RDS for PostgreSQL
MySQL Database
Radius.Data/mySqlDatabases
Azure Database for MySQLAmazon RDS for MySQL
Object Storage
Radius.Storage/blobStorages
Azure Storage Account Blob serviceAmazon S3-compatible recipe or custom implementation
Secrets
Radius.Security/secrets
Key Vault-backed or Kubernetes Secret recipeSecrets Manager-backed or Kubernetes Secret recipe
Containers
Radius.Compute/containers
AKS podsEKS pods
Persistent Volume
Radius.Compute/persistentVolumes
Azure Disk or Azure Files-backed PVCEBS or EFS-backed PVC
Ingress
Radius.Compute/routes
Azure App GatewayAWS ALB
AI Agent Runtime
Radius.AI/agents
Azure OpenAI + AI Search + Kubernetes runtimeCustom recipe required
Keep 
Radius.Data/redisCaches
available as a custom or legacy cache pattern when the environment has a matching resource type and recipe registered.
将应用需求映射到Radius资源类型和云服务：
需求Radius资源类型Azure实现方案AWS实现方案
SQL数据库
Radius.Data/postgreSqlDatabases
Azure Database for PostgreSQLAmazon RDS for PostgreSQL
MySQL数据库
Radius.Data/mySqlDatabases
Azure Database for MySQLAmazon RDS for MySQL
对象存储
Radius.Storage/blobStorages
Azure存储账户Blob服务兼容Amazon S3的方案或自定义实现
密钥管理
Radius.Security/secrets
基于Key Vault或Kubernetes Secret的方案基于Secrets Manager或Kubernetes Secret的方案
容器
Radius.Compute/containers
AKS PodEKS Pod
持久化卷
Radius.Compute/persistentVolumes
基于Azure Disk或Azure Files的PVC基于EBS或EFS的PVC
入口网关
Radius.Compute/routes
Azure应用网关AWS ALB
AI Agent运行时
Radius.AI/agents
Azure OpenAI + AI Search + Kubernetes运行时需要自定义方案
当环境中注册了匹配的资源类型和方案时，保留
Radius.Data/redisCaches
作为自定义或遗留缓存模式。

IaC Scaffolding

IaC脚手架搭建

When generating Terraform scaffolds, follow the constitution's project structure:
infrastructure/
├── environments/
│   ├── dev/
│   │   ├── main.tf          # Environment-specific config
│   │   ├── variables.tf
│   │   ├── outputs.tf
│   │   └── terraform.tfvars
│   ├── staging/
│   └── production/
├── modules/
│   └── <service>/           # Custom modules for the app
├── backend.tf               # Remote state config
└── providers.tf              # Provider versions
生成Terraform脚手架时，遵循章程规定的项目结构：
infrastructure/
├── environments/
│   ├── dev/
│   │   ├── main.tf          # 环境特定配置
│   │   ├── variables.tf
│   │   ├── outputs.tf
│   │   └── terraform.tfvars
│   ├── staging/
│   └── production/
├── modules/
│   └── <service>/           # 应用的自定义模块
├── backend.tf               # 远程状态配置
└── providers.tf              # 供应商版本

Naming Convention Application

命名规范应用

Apply the constitution's naming pattern to all resources:
<org>-<env>-<region>-<service>-<resource-type>
对所有资源应用章程规定的命名模式：
<org>-<env>-<region>-<service>-<resource-type>

Tagging Application

标签规范应用

Apply all required tags from the constitution to every resource.
对每个资源应用章程中要求的所有必填标签。

Radius Integration

Radius集成

When the application uses Radius:
  1. Use portable resource types in 
    app.bicep
    — don't hardcode cloud-specific resources
  2. Let recipes handle cloud specifics — the same 
    app.bicep
    deploys to both Azure and AWS
  3. Map environments to recipe sets: 
    • dev
      → Kubernetes recipes (in-cluster PostgreSQL, Redis pods)
    • staging
      / 
      production
      → Cloud recipes (Azure Database for PostgreSQL, ElastiCache, etc.)
bicep
// Same app.bicep works in all environments
resource db 'Radius.Data/postgreSqlDatabases@2025-08-01-preview' = {
  name: 'database'
  properties: {
    environment: environment  // Environment determines which recipe runs
    application: application
    size: 'M'
  }
}
当应用使用Radius时：
  1. 在
    app.bicep
    中使用可移植资源类型    ——不要硬编码云特定资源
  2. 让方案处理云特定细节——同一个
    app.bicep
    可部署到Azure和AWS
  3. 将环境映射到方案集： 
    • dev
      → Kubernetes方案（集群内PostgreSQL、Redis Pod）
    • staging
      / 
      production
      → 云方案（Azure Database for PostgreSQL、ElastiCache等）
bicep
// 同一个app.bicep可在所有环境中运行
resource db 'Radius.Data/postgreSqlDatabases@2025-08-01-preview' = {
  name: 'database'
  properties: {
    environment: environment  // 环境决定运行哪个方案
    application: application
    size: 'M'
  }
}

Guardrails

防护规则

  • Never recommend providers, regions, or tooling not approved in the constitution. If the user needs something outside the constitution, flag it as a deviation requiring amendment.
  • Always apply naming conventions and tagging requirements from the constitution to proposed resources.
  • Prefer Radius portable resource types over cloud-specific resources for application dependencies.
  • Propose the simplest architecture that meets requirements. Don't over-engineer.
  • Document trade-offs in the ADR — cost, complexity, operational burden, compliance.
  • Separate dev from production — dev can use cheaper/simpler implementations (Kubernetes recipes), production uses managed cloud services.
  • Consider failure modes — what happens when a component goes down? Design for the stated availability target.
  • Validate network topology against the constitution — ensure the proposed architecture fits within the VNet/VPC standards.
  • 绝不推荐章程中未批准的供应商、区域或工具。如果用户需要章程外的内容，标记为需要修订章程的偏差项。
  • 始终对提议的资源应用章程中的命名规范和标签要求。
  • 优先使用Radius可移植资源类型，而非云特定资源作为应用依赖。
  • 提出满足需求的最简架构。不要过度设计。
  • 在ADR中记录权衡因素——成本、复杂度、运维负担、合规性。
  • 区分开发与生产环境——开发环境可使用更便宜/简单的实现（Kubernetes方案），生产环境使用托管云服务。
  • 考虑故障模式——当某个组件故障时会发生什么？根据既定的可用性目标进行设计。
  • 根据章程验证网络拓扑——确保提议的架构符合VNet/VPC标准。