通过

Azure SQL 数据库的体系结构最佳做法

Azure SQL 数据库 是一个完全托管的平台即服务数据库引擎，可处理大多数数据库管理功能，而无需用户参与。 管理功能包括升级、修补程序、备份和监视。

单一数据库资源类型在 SQL 数据库中创建数据库。 数据库有自己的一组资源，并通过 逻辑服务器进行管理。 可以使用 弹性池在单个资源池中创建多个数据库。

本文假设作为架构师，你已查看 数据存储选项 ，并选择 SQL 数据库作为工作负荷的数据库引擎。 本文中的指南提供了映射到 Well-Architected 框架支柱原则的体系结构建议。

本文还假定你熟悉 SQL 数据库核心概念。 有关详细信息，请参阅 SQL 数据库的核心概念和 SQL 数据库中的新增功能？

重要

如何使用本指南

每个部分都有一个 设计清单，该清单提供关注的体系结构区域以及本地化为技术范围的设计策略。

此外，还包括有助于具体化这些策略的技术功能的建议。 这些建议并不表示可用于 Azure SQL 数据库及其依赖项的所有配置的详尽列表。 而是列出与设计视角相匹配的关键建议。 使用建议生成概念证明或优化现有环境。

演示关键建议的基础体系结构：
基线高可用性区域冗余 Web 应用程序。

技术范围

此次审查重点分析以下 Azure 资源的相关决策：

  • SQL 数据库

可靠性

可靠性支柱的目的是通过 建立足够的复原能力和从故障快速恢复来提供持续的功能。

可靠性设计原则 为各个组件、系统流和整个系统提供高级设计策略。

设计清单

根据可靠性设计评审核对清单开始实施您的设计策略。 确定其与业务需求的相关性，同时记住 SQL 数据库的可靠性。 扩展策略以根据需要包含更多方法。

  • 熟悉 SQL 数据库产品可靠性指南：
    有关详细信息，请参阅以下资源：

  • 选择适当的 SKU 配置： 对关键工作负荷使用业务关键层，因为它提供最高的可靠性保证。

    如果业务关键层不实用，请考虑 SQL 数据库超大规模层，以满足严格的恢复时间目标和恢复点目标。 超大规模层使用存储快照，而不是传统的数据库备份机制，从而提供零停机时间和快速恢复。

  • 生成冗余以提高复原能力： 使用活动异地复制、故障转移组和区域冗余增强数据库的可用性。

  • 使用本机灾难恢复和备份功能： 使用异地还原从服务中断中恢复。 可以在任何 Azure 区域中的任何 SQL 数据库服务器或托管实例上还原数据库。 还原使用最新的异地复制备份。

    发生人为错误后使用时间点还原进行恢复。 时间点还原会将数据库返回到较早的时间点，以便从意外更改中恢复数据。

  • 监视 SQL 数据库的可靠性和总体运行状况指标： 近乎实时地监视 SQL 数据库，以检测可靠性事件。

  • 实现重试逻辑和退避逻辑： 使用这些功能处理应用程序中的暂时性故障。

  • 备份 TDE 加密密钥： 将客户管理的密钥用于透明数据加密（TDE），将密钥备份到 Azure Key Vault。

建议

建议 益处
使用 活动异地复制 在不同的区域中创建可读辅助数据库。

如果应用程序支持只读连接字符串，请使用辅助数据库来处理只读数据库作。 此方法可减轻主实例的负担。		 如果主数据库出现故障，您可以手动故障转移到复制数据库，以确保应用程序在最小化停机时间的情况下继续运行。 具有只读连接的辅助数据库可提高整体性能，并确保读取作的可用性更高。
使用 故障转移组 自动从主数据库实例到辅助数据库实例的故障转移。 故障转移组提供在异地故障转移期间保持不变的读写和只读侦听器终结点。 异地故障转移会将组中所有的辅助数据库切换为主角色。 异地故障转移完成后，会自动更新域名系统 (DNS) 记录，以便将终结点重定向到新的区域。 异地故障转移组简化了异地复制数据库的部署和管理，这可确保持续可用性，而无需手动干预。 异地故障转移后无需更改应用程序的连接字符串，因为连接会自动路由到新的主数据库。
为数据库配置 区域冗余。 区域冗余可用性将数据分散到主要区域中的三个 Azure 可用性区域。 每个可用性区域都是一个单独的物理位置，具有独立的电源、冷却和网络。 如果某个可用性区域遇到服务中断，SQL 数据库实例将保持正常运行状态，并自动故障转移到操作区域，而不会丢失提交的数据。
在应用程序中实现 重试逻辑 。 SQL 数据库能够抵御基础设施的传递性故障，但这些故障可能会影响您的连接。 在重试逻辑中实现回退逻辑。 重试逻辑可提高应用程序的临时故障复原能力，并帮助应用程序在不手动干预的情况下恢复。 当应用程序与 SQL 数据库交互时遇到暂时性错误时，请确保代码可以重试调用。

退避逻辑增加了重试之间的延迟，这有助于防止网络拥塞和服务器过载。
备份加密密钥，当您使用自己的密钥时。 使用自己的加密密钥时，可以完全精细地控制密钥，但必须管理密钥和密钥轮换。 Key Vault 提供一个集中位置来管理加密密钥。 Key Vault 在一个工具中集中管理密钥，并帮助防止意外丢失密钥。

安全

安全支柱的目的是为工作负荷提供 保密性、完整性和可用性 保证。

安全设计原则通过对 SQL 数据库的技术设计应用方法，为实现这些目标提供了高级设计策略。

设计清单

根据 设计评审清单制定针对安全 的设计策略，并确定漏洞和控制，以增强安全防御能力。 扩展策略以根据需要包含更多方法。

  • 查看安全基线： 若要增强工作负荷的安全态势，请查看 SQL 数据库的 Azure 安全基线。

    有关可帮助工作负载满足安全性和符合性要求的功能的详细信息，请参阅 内置安全性和符合性功能。

  • 实施严格、有条件和可审核的标识和访问管理： 将 Microsoft Entra ID 用于工作负荷的身份验证和授权需求。 Microsoft Entra ID 提供集中式授权和访问管理。

    集中管理 逻辑服务器 级别的数据库集合的登录、防火墙规则、审核规则和威胁检测策略。

  • 加密数据： 启用数据加密来保护机密性和完整性。 使用类似 Always Encrypted 和 Always Encrypted with secure enclaves 的功能来保护高度敏感信息，如信用卡号和社会保障号码。 这些功能有助于防止加密密钥向数据库引擎公开。

  • 应用网络分段和安全控制： 在网络设计中创建有意的分段和外围，并使用所有网络边界的本地化网络控制来应用深度防御原则。

    使用 虚拟网络规则 控制来自虚拟网络中特定子网的通信。

    在数据库级别和服务器级别配置 SQL 数据库防火墙规则 ，以限制对数据库的访问。 如果使用 Azure 防火墙，请使用 SQL 完全限定的域名（FQDN）配置 Azure 防火墙应用程序规则。

    查看 SQL 数据库连接体系结构。 在实际情况下使用 Redirect 或 Proxy连接策略 。

建议

建议 益处
将 最小传输层安全性 （TLS） 版本 配置为至少版本 1.2，如果实际版本为 1.3。 Azure 弃用 TLS 版本 1.0 和 1.1，因为它们不安全。 版本 1.3 是最新且最安全的版本。
考虑基于分类帐来设计数据库表。 账本功能为所有数据更改提供审核、篡改证据和信任。
配置 Always Encrypted ，通过委派对加密密钥的数据访问来保护应用程序中的敏感数据。 Always Encrypted 有助于防止加密密钥向数据库引擎公开。 此功能提供拥有数据的人员与有权访问数据的人员以及管理数据但不应具有访问权限的人员之间的分离。 例如，本地数据库管理员、云数据库作员或其他高特权未经授权的用户不应具有访问权限。
通过启用安全 Enclave 扩展 Always Encrypted 的功能。 在服务器端，使用安全内存区来执行在 Always Encrypted 数据库中其他不受支持的操作。
使用 适用于 SQL 数据库的 Azure 专用链接 通过 专用终结点强制实施安全通信。 专用链接提供数据库和虚拟网络之间的专用连接，以便禁用公共访问。
使用 Microsoft Defender for SQL 数据库 漏洞评估扫描漏洞。 SQL 漏洞评估是 SQL 数据库的内置服务，用于识别和帮助修正潜在的安全漏洞。 它根据Microsoft最佳做法提供可作的步骤和自定义修正脚本。
使用 SQL 数据库的高级威胁防护来检测异常活动。 这些活动可能表明访问或利用数据库的异常和潜在有害尝试。 高级威胁防护为异常行为提供安全警报，以帮助在潜在威胁发生时进行检测和响应。 警报集成到 Microsoft Defender for Cloud 中。
使用 SQL 数据库审核跟踪数据库事件。 审核有助于保持合规性、了解数据库活动，以及深入了解可能表示存在业务问题或疑似安全违规的偏差和异常。
将 用户分配的托管标识 配置为服务器标识。 Azure 资源的托管标识功能消除了在代码中管理凭据的必要。
禁用基于 SQL 的身份验证，仅 允许Microsoft Entra 身份验证。 用于身份验证的 Microsoft Entra 将集中您对标识、访问和授权的管理，并提供对 SQL 数据库资源的精细权限。

成本优化

成本优化侧重于 检测支出模式、优先考虑关键领域的投资，以及优化其他 以满足组织预算，同时满足业务需求。

成本优化设计原则提供了实现这些目标的高级设计策略，并在与 SQL 数据库相关的技术设计中根据需要进行权衡。

设计清单

  • 熟悉 SQL 数据库成本管理资源： 查看 计划和管理 SQL 数据库成本 一文。 此资源包含节省成本的策略，包括有关如何优化经济高效实例和资源的建议，以及如何为工作负荷选择正确的计费模型。

  • 估算初始成本： 在成本建模练习中，使用 Azure 定价计算器 评估与工作负荷中的 SQL 数据库关联的近似成本。

  • 为工作负荷选择正确的 SQL 数据库服务层： 评估 SQL 无 服务器 层和 超大规模 层，以便更好地与用例保持定价一致。

    考虑 弹性池 来管理和缩放多个数据库。

  • 优化组件成本： 考虑为要长时间运行的静态工作负荷 的 SQL 数据库预留容量 。

    微调备份存储消耗，以避免过度使用产生费用。

  • 优化应用程序代码成本： 优化查询和其他作，以减少资源消耗，最大程度地减少运行时并提高整体性能。

  • 优化缩放成本： 将成本优化注意事项纳入数据库缩放策略。

    为了降低成本，在低使用率期间缩减数据库。 示例包括负载在数周或数月内减少的季节性工作负荷，或在夜间闲置的工作负荷。

建议

建议 益处
研究可用的 SQL 数据库 服务层级，并根据容量规划为每个用例选择最佳模型。 适当的服务层级有助于避免过度预配浪费成本。
使用查询性能见解和性能建议优化查询、表和数据库。 优化作有助于减少资源消耗，并帮助你确定适当的 SQL 数据库 SKU，以满足性能和预算要求。
使用 建议的备份策略 微调备份存储消耗。

对于 SQL 数据库中的 vCore 数据库，每种类型的备份使用的存储将作为单独的指标报告在数据库监视窗格中。 备份类型包括完整备份、差异备份和日志备份。 数据库的最高数据大小的备份存储消耗量包含在数据库的价格中。 存储成本过剩取决于单个数据库的工作负荷和最大大小。		 了解影响备份存储成本的因素，例如数据库大小、更改率和保留期。 正确配置备份存储以优化备份策略并最大程度地减少费用。
请考虑将 无服务器 层用于具有间歇性、不可预知的使用模式的单一数据库，并在空闲使用期后能够承受计算预热的延迟。 无服务器数据库会根据工作负荷需求自动暂停和缩放其计算资源。 计费基于每秒使用的计算量。 如果数据库具有不可预测的或突发使用模式，且使用时段较低或空闲，则无服务器数据库可以帮助优化成本和性能。
请考虑对所有工作负荷类型使用 “超大规模 ”层。 超大规模层的云原生体系结构提供独立可缩放的计算和存储，以支持各种传统和现代应用程序。 “超大规模”层中的计算和存储资源大大超出了“常规用途”和“业务关键”层中可用的资源。 超大规模数据库不需要额外的 SQL 许可成本。
使用预留容量节省资源成本。 确定区域中 Azure SQL 数据库的总计算容量和性能层后，使用该信息预留容量一或三年。 预先购买计算资源以减少 SQL 数据库的计算成本。 一年期预留最多可节省 40%，三年期预留最多可节省 60%。
通过将已启用软件保障的 SQL Server 许可证与 Azure 混合权益交换来节省 SQL 许可成本。 Azure 混合权益最多可节省 30% 的 SQL 数据库许可成本。 将数据库迁移到 Azure 时，可以利用现有的软件保障协议。
使用 弹性池 来帮助管理和缩放多个数据库。 SQL 数据库弹性池是一种简单、经济高效的解决方案，用于管理和缩放具有不同和不可预知使用需求的多个数据库。 同一弹性池中的所有数据库位于单个服务器上，并以固定价格共享固定数量的资源。

卓越运营

卓越运营设计原则 提供了一个高级设计策略，用于实现这些运营需求目标。

设计清单

根据 针对卓越运营的设计评审清单 启动设计策略，以定义与 SQL 数据库相关的可观测性、测试和部署过程。

  • 熟悉 SQL 数据库卓越运营资源： 请参阅 SQL 数据库文章中的监视和性能优化 。 本文包含详细的监视指南，包括有关监视查询性能、配置警报以及使用自动优化来提高效率的建议。

  • 使用基础结构即代码（IaC）技术： 使用 Bicep 和 Azure 资源管理器模板 等 IaC 技术部署 Azure SQL 数据库，以实现一致的结果并利用可重用性。

    使用最新版本的 Resource Manager API 来利用最新功能、安全更新和性能改进。

  • 监视 SQL 数据库： 使用监视来检测可靠性事件并优化性能。 首先监视工作负荷使用的 CPU 和输入/输出资源。 如需有关为您的工作负载设计可靠性与健康监控解决方案的帮助，请参阅 工作负载的健康建模。

  • 优化业务连续性和灾难恢复的管理： 使用 Azure 备份来保护 SQL 数据库并定期测试备份策略。

  • 使用本机数据库管理功能： 采用 SQL 数据库可以减轻数据库管理员的许多传统任务，例如基础架构相关的管理、备份管理，以及高可用性和灾难恢复操作。 鼓励他们在云原生管理方面的增长，并在采用数据即代码思维模式时与 DevOps 团队集成。

建议

建议 益处
使用数据库观察程序等工具监视 SQL 数据库，以检测可靠性事件。 通过快速检测可靠性事件，可以及时识别和解决性能问题，从而最大程度地减少工作负荷中断。
使用 持续集成和持续部署工作流 来简化 SQL 项目的部署过程。 用于发布更改的可重复工作流可最大程度地减少人工干预的需求，并减少错误的可能性。 此方法可确保更可靠、更高效的部署过程。
使用 Azure 备份 来备份 SQL 数据库服务器。 Azure 备份支持集中管理业务连续性和灾难恢复，以便可以有效地监视备份作。 Azure 备份支持长期保留恢复点，以确保数据在较长时间内保留。 它还执行跨区域和跨订阅还原，从而提高备份策略的灵活性和复原能力。

性能效率

性能效率就是通过管理容量来保持用户体验，即使负载增加也不例外。 该策略包括缩放资源、识别和优化潜在瓶颈，以及优化峰值性能。

性能效率设计原则 提供了一个高级设计策略，用于根据预期使用量实现这些容量目标。

设计清单

根据 性能效率的设计评审清单 ，根据 SQL 数据库的关键绩效指标定义基线，启动设计策略。

建议

建议 益处
应用 性能建议 以优化 SQL 数据库或解决工作负荷问题。 使用这些建议来提高数据库性能。
配置 自动优化 以自动优化数据库性能。 自动优化是监视查询、适应更改工作负载并自动应用优化建议的功能。 基于 AI 和机器学习的持续性能优化可以优化性能并稳定工作负荷。
使用 查询存储 来帮助优化查询的性能。 查询存储可帮助你快速找到查询计划更改导致的性能差异，从而简化了性能故障排除。 查询存储持续收集有关所有查询的详细信息。 此功能简化了查询性能故障排除，因为可以使用此信息快速诊断和解决查询性能问题。
使用 查询性能见解 工具确定工作负荷中资源消耗量最大的和长时间运行的查询。 查询性能洞察按 CPU、持续时间和执行次数提供有关数据库查询的详细信息。 可以查看资源使用情况的历史记录。 查询性能洞察提供有关数据库查询指标的深入了解，例如 CPU、持续时间和执行次数。 此功能可减少对数据库性能进行故障排除所需的时间。
使用内置工具 诊断和排查 CPU 使用率过高的问题。 这些工具可以帮助识别 CPU 使用率过高的原因，并优化 Transact-SQL 查询。 正确调整的应用程序和数据库会导致更高效的作，并可能降低成本。
了解 阻止 和 死锁 问题如何影响数据库性能。 解决阻塞和死锁问题有助于数据库更高效地运行、消除瓶颈并提高性能。
查看 Azure 门户使用情况报告，并根据需要缩放 单一数据库 或 弹性池 。 定期查看使用情况报告，确保有效使用资源。 这种做法有助于识别未充分利用的资源，从而降低成本。
在高性能、联机事务处理应用程序和实时分析等方案中，使用 内存中数据库对象 增强工作负荷的性能。 内存中技术使你能够提高工作负荷的性能，并可能降低数据库成本。

Azure 策略

Azure 提供了一组与 SQL 数据库相关的大量内置策略。 一组 Azure 策略可以审核上述一些建议。 例如，可以检查以下情况：

  • 在创建过程中，默认启用仅限 Microsoft Entra 身份验证。
  • 启用了区域冗余以提高可用性和复原能力。
  • 应为 Azure SQL 数据库启用长期异地冗余备份。
  • 将最低 TLS 版本设置为 1.2 可提高安全性，方法是确保只能从使用 TLS 1.2 的客户端访问 SQL 数据库。 请勿使用早期版本的 TLS，因为它们具有记录良好的安全漏洞。
  • SQL 服务器启用审核，以确保捕获针对 SQL 资产执行的操作。

有关全面的治理，请查看 Azure Policy 内置定义中列出的 SQL 数据库策略的内置定义。