将 WAF 模式应用于实际架构

将 WAF 模式应用于真实架构并不是理论练习，而是需要根据五大支柱评估每项设计决策，并进行有依据的取舍。一个常见的起点是架构图：跟踪用户请求经过每个组件的路径，并针对每一跳询问：如果该组件发生故障会怎样、需要多少成本，以及如何确保其安全。

请考虑一个传统的单体 Web 应用程序：单个 VM 同时运行 Web 服务器和数据库，并位于公共 IP 后面。根据 WAF 支柱进行评估时，它在五个方面的表现都很差：没有冗余（可靠性）、数据库与 Web 层位于同一主机（安全性）、无论流量如何 VM 始终运行（成本）、没有持续集成/持续交付（卓越运营），以及只能进行垂直扩展（性能效率）。

为了应对可靠性支柱，您可以将 Web 层分布到不同可用性区域中的多个 VM 上，使用异地复制将数据库备份到次要区域，并在前端部署Azure 负载均衡器。这样可以消除单一故障点，使应用程序能够在区域或地域发生中断时无需人工干预即可继续运行。

对于安全性支柱，请将 Web 层和数据库划分到不同的子网中，并使用NSG 规则，仅允许 Web 层连接到数据库端口。将数据库连接字符串存储在Azure 密钥保管库中，并在 Web 应用上使用托管标识在运行时获取该字符串，从而避免在应用程序代码和配置文件中硬编码凭据。

对于成本优化，请使用在非高峰时段缩减实例数量的Virtual Machine Scale Set替代始终运行的 VM。对于数据库，请评估采用具有合适 DTU 层级的托管 PaaS 服务（例如Azure SQL Database）是否比使用完整的 SQL Server VM 成本更低。对于能够提前 12 个月预测的基准容量，请购买预留实例。

将整个基础设施定义为存储在版本控制中的Bicep或 ARM 模板，以提升卓越运营水平。在 Azure Pipelines 或 GitHub Actions 中构建 CI/CD 管道，自动部署基础设施变更和应用程序代码。在变更进入生产环境之前，添加部署门禁，包括自动化冒烟测试和人工审批。

对于性能效率，请在数据库前引入Azure Cache for Redis，缓存频繁读取的查询并减少数据库负载。通过Azure CDN部署静态资源（图像、CSS、JavaScript），从靠近全球用户的边缘节点提供这些资源。每次变更后都要对应用程序进行负载测试，以确认改进效果可以量化。

每项架构变更都涉及权衡取舍。例如，迁移到多区域架构可以提高可靠性，但会增加成本（两个区域 = 两个 VM）。添加 Redis 缓存可以提升性能，但会增加运维复杂性（需要监视和维护另一项服务）。优秀的架构文档会明确记录这些权衡取舍，使未来的架构师能够理解做出决策的原因。

请避免试图通过一次重新设计就实现完美——这种方法成本高、风险大且进展缓慢。相反，请采用迭代改进周期：执行一次 Well-Architected Review，找出影响最大的三个问题，修复这些问题，衡量改进效果，然后重复这一过程。这种方法可以将架构改进与敏捷交付结合起来，并让利益相关者在每个冲刺中都能看到进展。

Microsoft 在 Azure Architecture Center 中发布了适用于常见工作负载模式的参考架构。其中包括 Web 应用程序架构、AKS 上的微服务、数据分析管道等众多内容。每个参考架构都已经根据 WAF 支柱进行评估，并包含针对该特定模式所作权衡取舍的说明。

使用架构决策记录（ADR）记录重要的架构选择、做出选择时的背景、考虑过的替代方案以及对 WAF 支柱的影响。将 ADR 与代码库一起存储在版本控制中，可以形成可审计的历史记录，帮助新团队成员理解架构为何采用当前的形式。

在本课中，您学习了以下内容：通过针对五个支柱评估每项架构决策来应用WAF 模式；可以通过先处理影响最大的问题来迭代改进；并且必须记录权衡取舍，以便未来的架构师理解决策依据。接下来，我们将学习 Azure SLA，以及如何计算多服务架构的组合 SLA。