你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure 上的 SaaS 工作负荷的数据
将数据视为解决方案中最有价值的资产。 作为独立的软件供应商（ISV），你负责管理客户的数据。 数据设计策略和数据存储的选择可能会显著影响客户。
本文提供有关在满足业务性能要求时如何确保客户的数据完整性和机密性的指导。 它重点介绍了帮助你有效实现这些目标的关键注意事项。
选择数据存储
软件即服务（SaaS）解决方案中的数据存储会影响其体系结构、性能、可靠性和事务复杂性。 将 Azure 托管服务的功能与类似的非Microsoft产品/服务进行比较。 在某些情况下，还可以考虑在虚拟机上运行开源产品。
设计注意事项
区分事务性操作和分析操作。 事务数据存储旨在支持应用程序，分析数据存储用于报告和分析数据存储，以及机器学习等任务。 这些商店是使用专用产品构建的，具有性能、访问模式、架构和用例的独特需求。
本指南重点介绍事务数据存储。
了解数据需求。 估计卷、更改频率以及需要存储的数据类型。
预计数据会随着时间推移而显著增长。 对于 SaaS 解决方案，增长发生在多个维度中。 预计随着客户数量的增长，数据的量和类型将增加。 请确保你计划这种增长，并投资于能够支持它的技术。
根据数据的性质在关系数据平台或非关系数据平台之间进行决定。 对于许多事务工作负荷，关系数据库是将应用程序实体建模为离散表的好选择。 此方法允许查询跨关系数据模型运行。 或者，如果数据自然适合文档模型或遵循图形结构，则非关系方法可能更合适。
有关详细信息，请参阅 SQL 与 NoSQL 数据平台。
尽量减少数据存储的类型。 将不同类型的数据存储存储在多个不同的数据存储中，对于跨各种数据平台具有专业知识的成熟组织来说，这非常有用。 但是，此方法通常为初创公司和小型组织带来不必要的复杂性。 更有效地专注于一个或多个数据存储。
如果没有使用多个数据存储的业务理由，请将精力集中在一个或多个数据存储上。
使用你知道的内容，并投资它。 如果你的团队已经拥有特定数据存储的专业知识，则通常最好使用该数据存储，而不是投资学习新技能。 数据存储和平台很复杂，设计决策可能难以逆转。
但是，请记住潜在的增长。 如果当前数据存储不再满足你的要求，请选择可增强解决方案性能、复原能力、安全性和运营效率的数据存储。 它还应帮助你的团队加深其专业知识。
设计建议
| 建议 | 好处 |
|---|---|
| 将日常操作的事务数据存储与分析和报告数据存储区分开。 | 混合数据存储的意图可能会导致不必要的复杂性。 数据分段提高了运营效率，并最大程度地提高了每个数据存储的利用率。 |
| 根据要求在关系数据结构或非关系数据结构之间进行选择。 从一个或多个数据存储开始。 确定托管数据存储的优先级。 常见选择包括 Azure Cosmos DB、Azure SQL、MySQL、MongoDB 和 PostgreSQL。 |
此方法有助于最大程度地降低复杂性，并确保使用正确的产品最大限度地提高效率。 托管数据存储可灵活管理资源和成本，并根据需要进行缩放。 与在自己的基础结构上部署自己的数据存储相比，使用托管数据存储会产生更少的管理负担。 |
| 投资学习所选的技术。 使团队能够管理高缩放要求和其他 SaaS 解决方案的复杂性。 | 了解你使用的工具及其更广泛的生态系统，以便在缩放时有效地使用数据平台。 |
| 在数据设计中采用灵活性。 | 随着 SaaS 解决方案的增长或需求的变化，可以通过添加或更改数据存储来适应。 这种灵活性使你可以从一个数据存储开始，并随着时间的推移而发展以满足你的需求。 |
租户模型和数据库策略
数据设计的关键方面是决定代表客户托管资源或在其环境中托管资源。 大多数 SaaS 提供程序为所有客户托管资源，这为数据库管理提供了灵活性。 如果在客户环境中托管资源，请考虑如何访问和管理这些资源。
设计注意事项
规划数据库分段。 在企业到企业（B2B）SaaS 解决方案中，我们建议为每个客户创建专用数据库。 此方法通过保持客户之间的严格隔离来增强数据安全性，从而降低混合数据并支持客户管理的加密密钥的风险。 它还有助于满足某些客户的法规合规性要求。
将客户数据分离到单个数据库可以通过最大程度地减少 干扰邻居问题来提高性能。 一些托管数据存储包括资源分配控制，以缓解这些问题，提供成本效益，并整合用于大规模管理多个数据库的工具。
在某些情况下，适合将多个客户的数据存储在单个数据存储中。 例如，在企业对消费者（B2C）解决方案中，可以根据客户 ID 在具有逻辑分区的单个存储中保存数据。 在共享组件的 B2B 解决方案中，可以对特定部分（例如事件存储）使用单个数据存储，同时确保在每个事件中包含客户 ID。
将数据存储与应用程序组件并置。 如果代表客户托管资源，请部署在同一 Azure 区域中，以避免出口带宽费用和延迟。 在客户环境中托管应用程序和数据存储时，将它们一起部署在同一环境中，以避免跨环境的复杂性。
尽可能规范数据存储管理。 统一性是跨客户管理数据的关键。 随着业务的发展，客户之间的差异会增加风险和复杂性。 这些差异还可以使生产中断的可能性更大，并且故障排除更加困难。
避免管理中的一次性更改以支持单个客户。 例如，若要支持客户管理的元数据，请避免架构更改，例如向数据库添加额外的列。 相反，为客户生成功能以添加自己的元数据。 同样，如果需要为不同的客户提供不同级别的数据库性能，请创建一个可用于将不同配置应用于不同层客户的单个过程。
有关租户模型如何影响数据策略的详细信息，请参阅。
设计建议
| 建议 | 好处 |
|---|---|
| 评估是在多个客户之间共享数据库还是提供共享数据平台。 根据需要为每个客户的数据部署单一数据库。 如果严格隔离不是必需的（例如 B2C 解决方案中），请放宽此策略。 |
此方法将干扰性邻居问题降到最低，并可以支持某些客户的合规性要求。 |
| 在同一区域中部署应用程序及其数据库。 | 此方法优化跨区域数据库访问产生的带宽成本和延迟。 |
| 设计用于存储客户定义数据或元数据的标准化方法。 避免更改单个客户的架构或导致客户环境不同。 | 此方法可帮助你避免管理每个客户的数据库之间的不一致性的操作负担。 |
| 在客户部署的环境中规划日常维护操作。 规划如何访问数据库以执行更新、架构更改、维护和其他操作。 |
这种主动方法可最大程度地减少缺少维护的问题，并降低停机和性能问题的风险。 |
计划容量
容量规划是指资源利用率的管理，重点是 CPU、内存、存储和磁盘操作，例如每秒输入和输出操作（IOPS）。 某些数据存储将这些资源合并为简单的综合资源消耗指标，例如 Azure SQL 中的数据库吞吐量单位（DTU）或 Azure Cosmos DB 中的请求单位（RU）。 托管数据存储在资源管理方面提供了灵活性，这允许随时间推移而发生更改。 建立初始计划并随着需求的发展而迭代至关重要。
设计注意事项
了解资源分配要求。 SaaS 解决方案中的不同客户可能具有不同的资源需求。 较小的客户可能需要最少的资源，而较大的客户可能需要更多资源。 较大的客户通常支付更多费用，这可以证明资源分配较高。 通过使用每个客户的单独数据库，可以根据其大小和需求调整资源分配。
了解数据平台提供的不同容量模型。 基于云的数据平台通常提供多个资源模型。 例如，某些 Azure 服务（如 Azure Cosmos DB）提供预配的、基于吞吐量的模型和无服务器模型。 Azure SQL 数据库还提供弹性池。
预配的吞吐量需要预先确定的资源分配，无论是从单一数据库还是一组数据库。 弹性池 允许在多个数据库之间共享资源。 弹性池通常用于 SaaS 解决方案。
即使预配的吞吐量要求提前分配资源，Azure Cosmos DB 等服务也提供 自动缩放吞吐量。 可以根据指定的触发器设置动态添加或删除资源的规则。
无服务器资源模型可根据需求自动缩放。 如果无法提前预测容量需求，则此功能使其成为一个很好的起点。 但是，它们可能支持更少的功能，并在增长时成本低下。 无服务器模型在 Azure SQL 数据库 和 Azure Cosmos DB 中可用。
设计建议
| 建议 | 好处 |
|---|---|
| 为每个客户建模数据库要求。 确定是应该有多个小型数据库、更少的大型数据库，还是混合使用这两个数据库。 使用 T 恤大小调整练习将客户分类为小型、中型和大型存储桶。 |
此方法可大致估计每个客户所需的资源，并帮助你将客户映射到计费模型。 |
| 根据使用资源池的客户数据库的大小对资源池进行分段。 利用预配容量的优势。 例如，你可以为较小的客户创建共享 SQL 弹性池，为中型客户创建单独的池，并为大型客户创建专用资源。 |
根据客户的数据库大小对资源池进行分段，可以优化资源分配和成本效益。 |
| 利用托管服务提供的内置缩放功能。 | 可以将缩放责任卸载到平台。 弹性池和自动缩放等功能可帮助优化资源使用。 |
| 定期查看无服务器数据存储，以确保它们继续满足你的需求。 | 可以确保数据存储在不断发展的需求下保持有效。 随着需求的变化，优化性能和成本效益。 |
高可用性和灾难恢复
SaaS 解决方案的客户通常对高可用性（HA）和灾难恢复（DR）寄予厚望。 如果客户在受管制行业运营或依赖解决方案进行日常运营，则其要求可能更加严格。
HA 和 DR 不是一刀切的解决方案，取决于各种因素。 清楚地了解适用于你和你的客户要求的可用选项，以做出有关缓解不同风险的明智决策。
权衡：可靠性、成本和性能：数据服务的复原能力通常需要跨更广泛的地理区域分发数据的副本或副本，以降低风险。 然而，有利弊。 数据必须行驶的距离越长，对本地化故障的保护就越大。 但是，跨较长距离复制数据会增加延迟，并且通常成本更高。 许多托管数据存储提供自动数据复制，但它们可能会对不同距离执行的复制类型施加限制，以保持性能。
设计注意事项
量化复原能力。 使用服务级别目标（SLO）衡量复原要求，其中包括运行时间、恢复时间和恢复点等指标。 这些指标由业务需求和客户（可能具有不同需求）驱动。 如果代表客户存储大量数据，则 HA 和 DR 解决方案可能需要更加复杂，以满足严格的要求。
有关复原指标的详细信息，请参阅 RE：04 有关定义可靠性目标的建议。
使用平台功能。 Azure 通过可用性区域，以及使用多个区域跨更广泛的地理区域提供数据中心内的复原能力。 结合可用性区域、跨区域备份和多区域部署等策略，以实现解决方案的适当复原级别。 对于高复原要求，请考虑使用区域之间的异步数据复制的多区域主动-被动体系结构。 此方法可能会导致在灾难性服务中断期间丢失一些数据。
权衡：具有复制的多区域、主动-主动设计是最有弹性的设计，但构建和测试很复杂。 对于大多数主动-主动解决方案，需要设计一种冲突解决方法，用于应对数据同步延迟。 大多数解决方案不需要这种复原能力。使用部署标记来隔离组件的爆炸半径。 部署标记模式在 SaaS 解决方案中广泛使用，因为它为部署、管理、性能和复原提供了优势。 例如，在美国部署一个印章，在欧洲部署另一个模具可确保一个区域中的客户独立于另一个区域的服务中断，并且可以独立运行。
设计建议
| 建议 | 好处 |
|---|---|
| 在考虑客户的总体数据要求时，请专注于复原能力要求。 | 通过在这些要求中制定设计决策，可以确保做出适当的权衡，并避免需求不足或过度工程。 |
| 在计费模型中反映不同级别的复原能力。 与客户设置期望。 灾难性服务中断期间零数据丢失或 100% 的运行时间可能不切实际。 |
计费模型可以帮助客户了解他们注册的保证复原能力。 例如，对于较低层，客户可以获得最少的保证。 在更高的层中，客户将获得更多的复原能力，因为你可以承受跨多个区域复制其资源。 |
| 将 Azure 可用性区域用于生产解决方案。 如果可能，请使用区域冗余数据存储。 | 可用性区域提供针对数据中心中断的复原能力，而不会显著增加解决方案的成本、延迟或复杂性。 |
| 使用可用的跨区域复制，以全局冗余格式保留数据存储的备份。 | 数据的跨区域备份增加了额外的复原能力级别。 |
| 使用部署标记在地理分布式位置创建解决方案的单独实例。 | 通过使用部署标记在地理分布式位置创建解决方案的单独实例，可以提高复原能力并提供更多优势，例如简化运营管理。 |
| 评估是否需要多区域部署，以及是否需要主动-主动设计来满足要求。 考虑所涉及的权衡。 与有状态组件（如数据存储）相比，无状态组件更易于复制。 |
通过复制区域之间的数据，跨区域分布解决方案或标记可提供更高级别的复原能力。 |
安全性与符合性
你负责确保客户的数据的保密性和完整性。 构建安全基线时，请考虑安全要求和承诺。 计划满足客户的合规性需求，包括数据保留。
设计注意事项
网络： 考虑谁将访问数据存储。 通常，只有应用程序需要直接通信，因此请将其配置为专用网络。
标识： 考虑如何访问数据存储。 许多 SaaS 解决方案对所有数据存储使用单个应用程序标识，应用程序层强制实施隔离和授权。 对于行级安全性或数据库级授权，可能需要将用户的标识传播到数据存储，该数据存储在多租户环境中很复杂。
数据保留： 提前规划数据保留策略。 维护更多数据会增加存储成本和管理复杂性。 例如，事务数据库中的大量数据可能会使查询和截断进程复杂化。
对于长期数据保留（例如符合性或将来的分析），请考虑将数据重新定位到适合长期保留的存储。
设计建议
| 建议 | 好处 |
|---|---|
| 将数据存储配置为使用专用终结点，并禁用公共终结点。 | 此方法通过限制对内部网络的访问来提高安全性。 通过限制访问，可以降低未经授权的访问和潜在数据泄露的风险。 |
| 使用托管标识和Microsoft Entra ID 进行身份验证。 避免使用数据库密钥或凭据。 | 托管标识无需数据库密钥或凭据，从而降低凭据被盗的风险并简化访问管理。 |
使用共享数据存储时，请确保应用程序通过将租户标识符包含在子句中 WHERE 来限定对单个租户的所有请求的范围。 |
此过程有助于降低跨租户数据泄露或模拟的风险。 |
| 根据合规性和业务需求规划数据保留策略。 避免保留不必要的历史数据。 对于长期保留，将数据从主存储移动到存档存储。 | 通过避免不必要的保留，可以维护较小的外围应用。 |
| 使用数据存储功能来支持数据生命周期需求。 在 Azure Cosmos DB 中，设置 文档生存 时间。 在 Azure SQL 中，使用 表分区 实现滑动窗口策略，以最大程度地减少存档过程对数据库的影响。 |
这些方法可确保高效的数据生命周期管理，通过存档或删除过时的数据来优化存储，并尽可能减少手动干预。 |
Operations
SaaS 解决方案通常包括大量数据库或其他存储。 请务必规划车队的例行维护，并探索自动化选项以高效管理这些任务。
设计注意事项
了解团队的功能。 如果没有大型数据库管理员团队，他们可以对各个客户的数据库执行详细分析，请制定计划大规模执行操作，并尽可能使用平台工具。
规划常规维护过程。 列出所需的定期维护操作及其频率。 具体操作因所使用的数据存储类型而异。 例如：
- 监视位于特定实体（如重要表）中的数据总量。
- 重新生成索引。
- 根据更改查询模式创建或删除索引。
- 重新平衡分区。
探索可帮助你定期执行维护并主动查找新问题的平台功能。 例如，Azure SQL 数据库监视器中SQL 数据库顾问来查找问题。
自动化设计。 自动操作对于 SaaS 解决方案有效缩放至关重要。 确定常规和偶尔的任务，并为其创建 playbook 或自动化脚本。 对于无法立即自动执行的任务，请全面记录流程以确保一致性和清晰度。
设计建议
| 建议 | 好处 |
|---|---|
| 尽量争取客户数据存储之间的一致性。 如果客户需要特殊住宿，请将它们集成到整个流程中，而不是自定义该客户的配置。 例如，对每个数据库使用相同的架构，并使用相同的进程来部署和管理资源。 |
一致性使大规模更改变得更容易，并最大限度地减少部署或维护过程中意外问题的风险。 |
| 仔细部署有限的资源，并寻求简化操作的机会。 | 可以避免小效率，提高资源利用率和整体性能。 |
| 为重复任务生成自动化。 选择购买自动化工具，而不是生成自定义解决方案。 了解平台和非Microsoft供应商提供的选项。 |
通过投资质量自动化，可以反复使用这些资产并减少经常容易出错的手动任务。 如果你不是正在使用的数据存储专家，或者不确定必要的维护任务，则自动化工具非常有用。 |
| 请仔细部署团队的数据库管理功能。 为影响最大的活动保留人工数据库管理员，例如处理大型客户或构建可跨多个客户缩放的自动化。 | 通过确定有价值的函数的优先级，可以最大限度地提高效率。 |
客户对数据的访问权限
某些客户可能会请求直接访问其数据进行自定义报告或分析。 仔细考虑客户如何访问解决方案中的数据，以及是否授予这些请求或提供满足其需求的替代方法。
设计注意事项
证明直接访问的原因合理。 通过获取有关其业务问题的信息，了解客户为何需要访问原始数据的原因。 协作查找满足其需求的解决方案，而不会给平台带来风险。
查找满足要求而不是提供直接访问权限的替代方法。 如果需要访问才能进行报告，则最好使用应用程序层方法。 例如，可以使用 Microsoft Power BI 为其生成报表，也可以将数据子集导出到提供给它们的文件中。 还可以创建可用于访问数据的 API。
评估安全性和隔离影响。 提供对数据存储的直接访问会带来重大安全风险。 避免向外部方公开内部资源，包括客户。 在具有许多客户共享解决方案的 SaaS 环境中，风险甚至更高，因为可以利用环境来访问其他客户的数据。
请考虑以不影响生产系统的安全隔离方式向客户提供对数据的访问权限，并允许在不中断客户的查询的情况下进行内部数据库设计更改。
请考虑对性能的影响。 允许直接访问事务数据存储可能会导致主应用程序出现性能问题。 例如，客户可能会运行资源密集型查询，以中断应用程序的功能。
设计建议
| 建议 | 好处 |
|---|---|
| 避免直接访问数据存储。 如果必须授予直接访问权限，请提供对只读副本的访问权限（如果数据平台支持该副本）。 |
应用程序层方法可让你控制客户如何使用数据。 如果无法创建应用程序层构造，则通过只读副本进行访问可以减少客户对操作的查询压力。 |
| 避免公开内部实现详细信息。 | 通过控制对数据结构的访问，可以阻止客户对数据库架构的功能做出假设。 这种灵活性使你能够随着时间推移而改进和优化数据库结构，而不受客户生成工具的约束或不准确的假设。 |
其他资源
多租户是设计 SaaS 工作负载的核心业务方法。 以下文章提供有关数据设计注意事项的详细信息：
下一步
了解 SaaS 工作负载的 DevOps 注意事项，包括高效的客户生命周期管理和安全部署做法。