architecture-design

架构设计技能

设计全面的 Azure 架构，并遵循 Well-Architected Framework 和 Cloud Adoption Framework 最佳实践编写 HLD 文档。

适用场景

• 根据需求设计新的 Azure 解决方案
• 编写高层设计（HLD）文档
• 选择 Azure 服务和架构模式
• 规划云迁移或现代化
• 编写架构决策记录

设计流程

1. 收集需求

询问澄清性问题，了解：

• 工作负载类型：Web 应用、API、数据处理、IoT、AI/ML
• 规模：用户数量、数据量、地理分布
• 性能：响应时间、吞吐量、延迟 SLA
• 可用性：正常运行时间要求（例如，99.9%、99.99%）
• 安全性：数据分类、合规要求（HIPAA、GDPR、PCI-DSS）
• 预算：月度／年度成本限制
• 时间表：部署期限、分阶段需求

2. 选择 Azure 服务

服务选择优先级： PaaS > 容器 > IaaS

有关详细指南，请参阅 references.md：

• 计算选项（App Service、Functions、AKS、Container Apps、VMs）
• 数据存储（Azure SQL、Cosmos DB、PostgreSQL、Blob Storage）
• 消息传递（Service Bus、Event Hubs、Event Grid、Storage Queues）
• 网络（Front Door、Application Gateway、Load Balancer）

关键决策标准：

• 根据需求匹配服务功能
• 考虑团队专业能力和运维开销
• 评估成本与功能之间的权衡
• 优先选择托管服务以减少运维工作

3. 设计架构

根据需求应用相应模式：

N 层（传统）：

• 适用场景：标准 Web 应用、成熟模式、团队熟悉
• 结构：前端 → 负载均衡器 → 应用层 → 数据库
• 服务：App Service、Azure SQL、Application Gateway、Redis Cache

微服务：

• 适用场景：松散耦合的服务、独立扩展、多语言需求
• 结构：API 网关 → 服务 → 消息总线 → 数据库
• 服务：API Management、AKS/Container Apps、Service Bus、Cosmos DB

事件驱动：

• 适用场景：异步处理、响应式系统、解耦组件
• 结构：事件源 → Event Hub/Grid → Functions/Logic Apps → 存储
• 服务：Event Hubs、Azure Functions、Cosmos DB、Service Bus

无服务器：

• 适用场景：间歇性工作负载、事件处理、成本敏感型场景
• 结构：HTTP/计时器/队列触发器 → Functions → 存储/数据库
• 服务：Azure Functions、Logic Apps、Cosmos DB、Blob Storage

4. 应用 Well-Architected Framework

涵盖全部五大支柱（详细检查清单见 waf-assessment skill）：

可靠性：

• 生产环境使用可用性区域
• 关键任务工作负载采用多区域架构（99.99%+）
• 运行状况检查和自动修复
• 制定备份策略并明确 RPO/RTO

安全性：

• 使用托管标识（不在代码中存储凭据）
• 为 PaaS 服务配置专用终结点
• 仅使用 HTTPS，并采用 TLS 1.2+
• 网络安全组（最小特权）
• 使用 Azure Key Vault 管理机密
• 使用 Azure AD 进行身份验证和 RBAC

成本优化：

• 调整资源规格（从小规模开始，逐步扩展）
• 配置自动缩放策略
• 为可预测的工作负载预留实例
• 使用存储层级（Hot/Cool/Archive）
• 监控成本并配置警报

卓越运营：

• 基础设施即代码（Bicep 或 Terraform）
• CI/CD 管道
• Application Insights + Log Analytics
• 为关键场景配置警报
• 自动化部署和回滚

性能效率：

• 使用 CDN 分发静态内容
• 制定缓存策略（Redis、CDN）
• 采用异步处理
• 选择合适的计算 SKU
• 配置自动缩放规则

5. 创建命名约定

遵循 Cloud Adoption Framework：

{resource-type}-{workload}-{environment}-{region}-{instance}

Examples:
- rg-ecommerce-prod-eastus-001
- app-ecommerce-prod-eastus-001
- sql-ecommerce-prod-eastus-001
- kv-ecommerce-prod-eastus
- func-orderproc-prod-eastus-001

标准标记：

Environment: Production | Staging | Development | Test
Owner: [email protected]
CostCenter: IT-12345
Project: ProjectName
BusinessUnit: Sales | Marketing | Engineering
Criticality: Critical | High | Medium | Low
DataClassification: Public | Internal | Confidential | Restricted

6. 估算成本

调用 azure-pricing 技能以获取实时零售价。切勿凭记忆估算成本。

azure-pricing 技能将：

• 按可计费资源 SKU 和区域调用 azure-mcp/pricing（pricing_get）
• 返回一个三列的表格：按需付费 | 1 年预留 | 3 年预留
• 找出最适合预留实例 / 节省计划的候选项

请求定价前，请确认步骤 3 中的所有服务 SKU — 该工具需要指定的 SKU 或服务名称。

按类别组织成本输出：

• 计算（App Service、Functions、VM、AKS 节点）
• 数据（SQL、Cosmos DB、Storage）
• 网络（Front Door、App Gateway、Firewall、Bandwidth）
• 监控（Application Insights、Log Analytics）

高级设计输出格式

生成包含以下章节的全面 HLD 文档：

1. 执行摘要

• 解决方案概述（2–3 个段落）
• 主要优势和业务价值
• 高级成本估算
• 时间线和部署方法

2. 需求摘要

• 功能需求（项目符号）
• 非功能需求（性能、可用性、安全性）
• 限制和假设

3. 架构概述

• 架构图说明（组件及其连接）
• 使用的设计模式（N 层、微服务、事件驱动、无服务器）
• 架构方案的理由

4. 组件设计

对于每个组件：

• 服务名称：所选的 Azure 服务
• SKU/层级：具体的定价层级（例如，App Service P2v3、Azure SQL S2）
• 用途：在架构中的作用
• 配置：关键设置（区域、可用区、实例、容量）
• 命名：遵循 CAF 约定（rg-app-prod-eastus-001）

5. 网络设计

• 虚拟网络配置（地址空间）
• 子网和网络安全组
• 专用终结点和服务终结点
• 入站/出站模式（负载均衡器、网关）
• DNS 配置

6. 安全设计

• 身份验证和授权（Azure AD、托管标识）
• 机密管理（Key Vault）
• 加密（静态和传输中）
• 网络安全（NSG、防火墙、WAF）
• 合规要求

7. 数据设计

• 数据库架构方案
• 组件间的数据流
• 备份和恢复策略（RPO/RTO）
• 数据保留策略
• 灾难恢复方案

8. 监控和运维

• Application Insights 配置
• Log Analytics 工作区
• 要监控的关键指标
• 警报定义和阈值
• 仪表板建议

9. 部署策略

• 基础设施即代码方案（Bicep 或 Terraform）
• CI/CD 管道设计
• 环境策略（dev、staging、prod）
• 部署顺序和依赖关系
• 回滚流程

10. 成本明细

• 调用 azure-pricing 技能，按服务 SKU 和目标区域获取实时零售价
• 每项服务的月度成本和年度预测
• 并排比较表：按需付费 | 1 年预留 | 3 年预留
• 成本优化建议（调整资源规格、Spot/可抢占节点、存储层级）
• 最适合预留实例 / 节省计划的候选项及其预计月度节省额

11. 架构良好性评估

• 针对 WAF 各支柱的简要评估
• 设计的主要优势
• 未来可改进的方面

12. 风险与缓解措施

• 已识别的技术风险
• 缓解策略
• 依赖关系和假设

13. 后续步骤

• 立即采取的行动（阶段 1）
• 短期改进（阶段 2）
• 长期路线图（阶段 3）

HLD 片段示例

# High-Level Design: E-Commerce Web Platform

## 1. Executive Summary

This HLD describes a scalable e-commerce platform on Azure supporting up to 100K concurrent users
with 99.95% availability. The solution uses proven PaaS services with multi-region capabilities,
comprehensive security controls, and cost-optimized infrastructure.

**Key Benefits:**
- Global reach with Azure Front Door CDN
- Auto-scaling for traffic spikes (Black Friday, holidays)
- PCI-DSS compliant payment processing
- **Estimated cost**: see Section 10 — priced live via the `azure-pricing` skill per SKU and target region

**Timeline:** 8-week implementation with phased rollout

## 3. Architecture Overview

**Pattern:** N-Tier with asynchronous order processing

**Components:**

Azure Front Door（全球 CDN + WAF） └─ Application Gateway（区域 WAF + LB） ├─ App Service（Web 前端 - 3 个实例，P2v3） ├─ App Service（API 后端 - 3 个实例，P2v3） ├─ Azure Functions（订单处理器，Premium） ├─ Azure SQL Database（S2 DTU，50GB） ├─ Redis Cache（Basic C1，1GB） └─ Blob Storage（Hot 层，产品图片）

**Rationale:** N-tier provides proven scalability, PaaS reduces operational overhead,
Functions handle asynchronous order processing, Azure SQL provides ACID guarantees.

## 4. Component Design

**Frontend Web App**
- Service: Azure App Service (Linux)
- SKU: P2v3 (2 vCores, 8GB RAM)
- Instances: 3 (Availability Zones 1, 2, 3)
- Auto-scale: 3-10 instances based on CPU > 70%
- Naming: app-ecommerce-web-prod-eastus-001
- Purpose: Serves customer-facing website

[Continue with all components...]

编写出色的 HLD 的提示

具体明确： 使用准确的服务名称和 SKU（不要只说“数据库”，而要写“Azure SQL Database S2 DTU”） 说明权衡： 解释选择服务 X 而不是服务 Y 的原因 包含图表： 通过清晰的组件关系，以可视化方式描述架构 实时定价： 每个成本部分都调用 azure-pricing 技能——切勿凭记忆猜测价格；始终传入目标 region 和 currency（例如，英国工作负载使用 GBP） 关注成本： 始终提供成本估算和优化机会 安全优先： 涵盖身份验证、授权、加密和网络安全 与 WAF 保持一致： 在设计决策中引用具体的 WAF 原则 命名规范： 始终遵循 CAF 约定 可直接实施： 提供足够的细节以便生成 IaC

避免： 使用模糊术语、遗漏成本、忽视安全、跳过 WAF、组件不完整、缺少决策依据