你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure 上的 SaaS 工作负荷的计算
软件即服务（SaaS）应用程序需要在计算平台上运行。 与体系结构中的其他组件一样，它需要满足业务需求，并根据业务模型进行设计。 计算平台的选择是一个重要的设计决策。 你的决策会影响客户隔离、性能和复原能力，计算平台会影响整个 SaaS 解决方案的缩放和增长方式。
本文介绍选择托管模型的注意事项、该模型的操作方面，以及如何优化技术选项，以帮助你满足服务级别协议（SLA）和服务级别目标（SLO）。
选择计算平台
为 SaaS 工作负载选择正确的计算平台非常重要，但丰富的可用选项会使选择感到压倒性。 最佳平台取决于应用程序体系结构、规模、性能需求和租户隔离模型等因素。 对于一个应用程序而言，最佳效果可能不是另一个应用程序。
设计注意事项
托管模型。 Azure 提供各种托管模型，主要是基础结构即服务（IaaS）和平台即服务（PaaS），每个模型都有自己的优势和利弊。 评估应用程序的要求，并选择最合适的模型。
IaaS 提供虚拟机（VM）并完全控制它们，包括网络和存储。 但是，它需要管理和修补，这在操作上可能很密集。 示例包括虚拟机规模集和Azure Kubernetes 服务 （AKS） 群集。
PaaS 允许在不管理底层基础结构的情况下部署应用程序。 它包括用于自动缩放和负载均衡的内置功能。 示例包括Azure App 服务和 Azure 容器应用。
与 IaaS 相比，PaaS 服务提供的控制权较低，如果应用程序需要特定配置，则这可能会造成问题。 例如，应用程序可能在 PaaS 服务不支持的操作系统上运行。
工作负载类型。 某些平台专用于特定工作负荷，而另一些平台则多才多艺。 例如，App 服务专为 Web 应用程序设计，而 AKS 更通用。 它可以托管 Web 应用、AI 工作负载和批处理计算任务。
开发团队专业知识。 如果团队缺乏新平台的经验，则大更改可能会很困难。 评估团队的技能，并将其与平台要求相匹配。 从简单的平台开始，逐步改进体系结构，而不是直接跳转到更高级的选项。
例如，如果要生成容器化应用程序，请从容器应用开始轻松管理。 随着需求的增长更加复杂，在一段时间内更好地了解平台时，可以过渡到 AKS。
管理开销。 计算平台平衡开销和控制。 从团队转移的更多管理责任意味着对平台的控制更少。
例如，IaaS 对 VM 提供高控制，但开销很大。 如果应用程序部署在客户的环境中，则管理操作的访问权限可能有限。 评估这些利弊是否可接受且可行。
性能要求。 通过对 CPU、内存、网络（包括带宽和延迟、GPU 和可用性需求）进行建模来了解应用程序的性能要求。 还应考虑未来的增长。 使用此信息可以选择相应的计算资源，例如 VM 的系列和大小。 可能还需要选择支持特定 VM 系列的特定区域来满足专用要求。
可靠性要求。 考虑计算平台的可靠性功能，并确保它们满足可靠性目标。 可能需要使用特定的服务层来拥有解决方案的多个实例，或跨可用性区域部署以提高可靠性。
应用程序安全性和符合性。 评估每个计算平台的安全功能和 符合性认证 ，以确保它们满足你的需求。 例如，如果需要监视和筛选传出流量，可能需要选择特定的计算服务或层。
设计建议
| 建议 | 好处 |
|---|---|
| 通过估算 CPU、内存、网络和 GPU 缩放维度来评估计算性能要求。 执行负载测试以收集更准确的数据，以通知建模练习。 |
这些任务可帮助你为计算平台选择适当的大小调整，并在系统上的负载增加时适当缩放。 |
| 评估团队的熟练程度，并从最复杂的平台开始，以满足你的需求或团队已经熟悉的平台。 | 通过选择熟悉的计算平台，确保操作更流畅，避免过度负担团队。 |
| 在设计中灵活。 旨在一个解决方案，你可以随着时间的推移循环访问，以适应不断发展的业务和技术要求。 | 灵活性使你能够更轻松地适应一段时间内的更改和改进。 你可以有效地响应不断发展的业务和技术需求。 |
| 评估总拥有成本（TCO），包括操作解决方案的成本。 | 你清楚地了解了成本，这对规划定价模型和确保经济高效的运营至关重要。 |
| 评估是否需要使用特定计算平台，因为技术堆栈。 某些计算平台更适合某些编程语言、工具和操作系统。 努力使用原生支持技术选择的平台。 | 可以避免重新设计体系结构的成本，这可能包括迁移到新平台。 |
| 评估平台的可靠性功能，并将云服务提供商的保证纳入 SLO。 | 通过规划可靠性功能并使用可用性区域（如果可用）来降低本地化数据中心中断的风险。 |
租户模型和隔离
SaaS 业务模型确定是为客户托管资源，还是在客户环境中管理资源。 大多数 SaaS 提供商代表其客户托管资源，从而在计算平台设计方面具有灵活性。 有效地隔离客户工作负载，以优化成本效益，而不会影响客户体验或性能。
设计注意事项
规划租户模型。 租户模型确定客户之间的资源共享，并受业务和定价模型的影响。 与完全多租户模型相比，单租户模型的成本更高。 定价应反映这些差异。
客户要求。 某些客户可能对数据驻留、性能保证或安全符合性有特定需求。 如果这些要求需要比平常更高的隔离级别，请考虑如何反映业务模型中成本的增加。
吵闹的邻居问题。 在租户之间共享资源时，请注意干扰邻居问题。 计算资源受到的影响最大。 有关详细信息，请参阅 Noisy 邻居反模式。
选择租赁模型时，请平衡资源共享的成本节省，同时保证客户性能。 过度共享资源或允许过度消耗可能会降低客户体验。
权衡：性能和成本。 在客户之间共享资源可以经济高效，但如果某些客户使用的资源超出预期，此方法可能会降低其他客户的性能。 为防止这种情况，请实施适当的资源治理，以确保租户使用情况保持在预期限制范围内。
设计建议
| 建议 | 好处 |
|---|---|
| 评估计算平台的隔离功能，以确保它满足租户模型要求。 | 首先通过验证关键配置来避免重新工作平台。 |
| 强制实施隔离模型。 请谨慎使用本地磁盘缓存、系统内存和外部缓存等共享资源，因为它们在租户之间意外泄露数据（如果它们未正确管理）。 对于高隔离要求，在计算平台和应用程序中强制实施隔离。 |
强隔离可降低跨租户数据泄露的风险，这是一起严重的安全事件。 |
| 实现资源治理和监视，并查看客户级指标。 主动监视每个客户的资源消耗，以检测和缓解干扰性邻居问题。 |
可以通过提前监视资源消耗和缓解问题来防止问题影响其他客户。 |
配置可伸缩性和成本效益
客户可以将应用程序与不同的性能配置文件一起使用。 他们希望应用程序能够处理不断增长的用户需求、大规模数据和复杂的工作负载，而不会影响速度和性能。 系统体系结构必须确保可伸缩性和最佳性能，无论是管理数亿用户还是数百万用户，同时平衡性能需求和成本。
有关成本管理的详细信息，请参阅 Azure 上 SaaS 工作负荷的计费和成本管理。
设计注意事项
水平和垂直缩放策略。 水平和垂直缩放方法可用于处理增加的负载。 使用的方法取决于应用程序跨多个实例进行缩放的能力。
- 水平缩放涉及添加更多计算节点实例。 体系结构需要负载均衡器才能跨多个服务器或实例分配传入流量。
- 垂直缩放涉及在单个服务器上增加资源，例如 CPU 和内存。 对于不需要外部状态存储（如缓存）的有状态应用程序，请使用此方法。 垂直缩放可能会导致短暂的服务中断，并且单个服务器上存在资源限制。
自动缩放。 系统需要有效地处理不同级别的需求。 随着用户流量的增加，应用程序资源需要纵向扩展才能保持性能。 需求减少时，资源会缩减以控制成本，而不会影响用户体验。 CPU 使用率、一天中的时间或传入请求等因素会指导这些调整。 自动缩放有助于平衡性能和成本，并缓解高需求对其他租户的影响。
请参阅 RE：06 有关可靠缩放的建议。
容量规划和计算分配。 将新客户加入 SaaS 工作负载会消耗资源容量。 即使垂直或水平缩放，最终也会在解决方案的可伸缩性中达到网络或存储约束等限制。
设计建议
| 建议 | 好处 |
|---|---|
| 选择垂直缩放的水平缩放。 水平缩放通常比垂直缩放更复杂、更可靠且更具成本效益。 | 水平缩放通常更简单、更可靠且经济高效，这使你可以缩放到比垂直缩放更高的程度。 |
| 执行负载测试。 | 在部署到生产环境之前，模拟使用情况有助于识别瓶颈和缩放阈值。 |
| 定义用于部署新标记的缩放阈值，而不是水平或垂直缩放。 若要在不丢失性能的情况下实现经济高效的缩放，请将租户精简为尽可能少的资源。 |
你已做好应对当前基础结构以外的增长的准备。 |
| 尽可能实现自动缩放。 设置自动缩放规则以准确反映应用程序的负载。 | 可以通过根据需要增加和减少资源来优化性能和成本。 |
| 监视和评估客户使用模式。 | 你知道何时调整基础结构以提高性能或优化成本。 |
| 尽可能实现缓存机制。 | 可以减少计算层上的潜在处理负载。 |
| 使用 成本警报。 | 警告有助于提前检测高使用率和控制成本问题。 |
| 对长期承诺的客户使用 Azure 预留 ，并保证整个时间段的计算利用率。 | 可以最大程度地提高预留容量的成本效益。 |
复原设计
计算层的复原能力在总体复原策略中起着很大的作用。 应用程序应能够自动且无缝地容忍和恢复常见故障，而不会影响用户。
设计注意事项
可靠性要求。 设置明确的可靠性要求。 这些要求包括内部目标、SLO 以及客户承诺或 SLA，这些要求通常指定每月 99.9% 的运行时间目标。
部署策略。 云资源部署在特定地理区域中。 在 Azure 中，可用性区域是区域中的独立数据中心集。 若要实现复原能力，请跨多个可用性区域部署应用程序。 跨区域或云提供商进行部署可增强复原能力，但增加了成本和运营复杂性。
无状态工作负荷。 若要部署可复原的应用程序，通常需要在不同的位置运行冗余副本。 对于需要维护会话状态的有状态工作负荷，此任务可能很困难。 旨在尽可能生成无状态工作负荷。
设计建议
| 建议 | 好处 |
|---|---|
| 处理 应用程序中的 暂时性故障。 | 通过快速从次要问题中恢复来增加可用性。 |
| 选择无状态应用程序。 如果应用程序需要有状态，请使用外部状态存储机制（如缓存）来存储状态。 | 防止实例不可用（例如在错误负载均衡期间或中断期间）导致的状态丢失。 |
| 使用可用性区域。 | 通过缓解本地化的数据中心中断来提高复原能力。 |
| 设计多区域体系结构时，有业务理由这样做。 | 满足高运行时间要求并支持不同区域中的用户。 |
| 执行 混乱工程。 | 可以更好地了解故障点的位置，并在发生中断之前更正故障点。 |
| 限制多个标记共享的组件的使用。 | 消除单一故障点并降低中断的潜在影响区域。 |
其他资源
多租户是设计 SaaS 工作负载的核心业务方法。 以下文章提供有关计算平台注意事项的详细信息：
下一步
了解 SaaS 工作负载的网络注意事项。