你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

有关选择正确服务的建议

  • 项目

适用于此 Azure Well-Architected 框架性能效率清单建议：

PE：03 选择正确的服务。 服务、基础结构和层选择必须支持你能够达到工作负载的性能目标并适应预期的容量更改。 选择还应权衡使用平台功能或生成自定义实现的好处。

本指南介绍为工作负荷选择合适的服务的建议。 以下建议可帮助你选择最能满足工作负载要求和需求的服务。 使用旨在处理工作负载需求的服务时，可以确保工作负载满足性能目标。 如果为工作负荷选择不适当的服务，则服务可能无法处理工作负载的需求。 服务不足可能会导致响应时间变慢、瓶颈或工作负荷失败。

定义

术语 定义
可用性区域 区域中的一组独立的数据中心。 每个可用性区域都独立于其他可用性区域，具有自己的电源、冷却和网络基础结构。 许多区域支持可用性区域。
计算服务 提供运行应用程序所需的基础结构的服务。
数据库服务 为应用程序提供关系数据库和非关系数据库的服务。
基础结构 云计算的物理组件以及组件的地理位置。
基础结构即服务 (IaaS) 客户在其中负责操作系统、标识、应用程序和网络的服务。
平台即服务 (PaaS) 云服务提供商在其中负责操作系统的服务。 云服务提供商与客户分担管理标识、应用程序和网络的责任。
区域 包含一组数据中心的地理外围。
资源 可以在云服务提供商中创建、配置和利用的单个实体或组件。
服务 云服务提供商提供的产品/服务。
库存单位 (SKU) Azure 服务的服务层。
存储服务 为对象、块和文件提供存储的服务。

关键设计策略

你选择的服务应与工作负载的性能目标保持一致，并适应未来的容量需求。 随着工作负载的扩展或演变，所使用的服务应符合性能标准，而无需进行重大调整。 考虑平台功能和自定义实现之间的平衡。 平台功能提供即时解决方案，但自定义的选项提供精确的定制。 服务选择应具有前瞻性，并针对你的特定需求进行定制，同时考虑到便利性和自定义之间的权衡。

了解工作负载要求

了解工作负载要求是指掌握工作负荷的技术和功能需求。 此分析有助于确定运行工作负载所需的资源、存储、计算、网络和其他规范。 使服务与工作负载的特定需求保持一致有助于防止过度预配或资源利用不足。

评估工作负载的需求和特征以确定要求，并使工作负载要求与每个层的性能目标保持一致。 必须考虑约束或依赖项。 了解工作负载要求后，可以做出明智的决策。 可以确定正确的基础结构并实施策略来处理峰值负载或需求变化。

  • 满足性能目标。 选择使你能够满足工作负载的性能目标的服务。 确保服务可以支持性能需求，并且你可以监视其性能。 收集关键组件的性能数据。

  • 请考虑组织限制。 熟悉组织可能对你部署的服务的限制。 设计解决方案时，请考虑这些限制。

  • 考虑合规性和安全要求。 合规性和安全要求可能会影响你选择的服务和配置。 确保所选服务满足与存储、加密、访问控制、审核日志和数据位置相关的要求。

  • 考虑团队技能。 你的团队生成和维护工作负载。 不同的服务需要不同的技能。 选择团队知道如何使用的服务，或在选择服务之前承诺对其进行培训。 确保团队成员具有有效使用服务和优化其性能的专业知识和知识。

权衡：专业服务提供特定功能，但可能会限制自定义。 与专用服务相比，灵活资源需要更多的管理和配置。 托管服务易于管理，但与自管理资源相比，你对底层基础结构的控制可能更少。

了解服务

了解服务是了解供应商工具和产品/服务的功能、限制和功能。 了解服务有助于使用内置功能，减少对复杂自定义解决方案的需求并提高性能效率。

在选择服务之前，请考虑各种因素并全面了解服务。 研究和评估提供商提供的服务和工具。 确定哪些服务和工具最符合工作负载要求。 请考虑托管服务、无服务器选项和专用服务等因素。

了解服务限制

服务限制是服务提供商设置的预定义阈值或边界。 服务限制定义该服务中资源或功能的最大使用量。 熟悉服务限制后，可以避免资源争用、性能降低或意外的服务中断等问题。 可以相应地规划和缩放基础结构。 规划会考虑数据量、处理能力和数据驻留要求等因素。

首选平台功能

首选平台功能是使用提供程序提供的内置功能来处理特定任务，而无需自定义代码。 供应商设计平台功能，以高效大规模处理特定任务，并定期维护这些功能。 平台功能使你能够更好地利用云基础结构功能。 选择允许将功能卸载到平台的服务，而不是编写和维护自己的自定义代码。 在许多情况下，平台即服务 (PaaS) 解决方案比自定义代码提供更好的性能效率。 自定义代码增加了复杂性，使工作负荷容易出现性能问题。 仅当服务功能不够时，才开发自定义代码。

权衡：最适合工作负荷的服务可能是团队不熟练、负担不起的技术，或者可能需要额外的安全层。 例如，公共负载均衡器可能满足性能需求。 但是，如果没有 Web 应用程序防火墙，则可能必须部署防火墙来保护工作负荷。

评估基础结构要求

资源的性能效率与它们驻留的基础结构有关。 它使选择正确的基础结构对于服务性能效率至关重要。 评估基础结构要求意味着确定最适合支持工作负载的地理区域和可用性区域。 此决策中的主要注意事项包括：

  • 了解区域和可用性区域。 每个区域对应于不同的地理位置。 可用性区域表示给定区域内的各个物理数据中心。

  • 单区域部署模型与多区域部署模型。 单区域部署模型在单个区域中部署所有资源。 多区域部署模型跨多个区域部署资源。 多区域部署可以减少最终用户的延迟并缓解容量限制。 但是，它还会增加工作负荷的成本和复杂性。 选择最适合工作负荷需求的部署模型。

  • 了解可用功能。 不同区域具有不同的可用功能，例如服务和可用性区域的数量。 先了解区域中可用的功能，然后再选择它。 确保某个区域满足工作负载性能需求。

  • 考虑延迟。 延迟，即数据从源传输到目标所花费的时间，增加了彼此之间的进一步服务。 跨区域或可用性区域通信的服务可能面临更高的延迟。 建议确定经常通信的服务并将其定位在同一区域中。 此外，选择与主要用户群相近的区域可以最大程度地减少延迟，从而提供更好的用户体验。

  • 了解数据中心映射。 可用性区域可能无法跨不同订阅一致映射到同一数据中心。 例如，“订阅 A”中的“区域 1”可能与“订阅 B”中的“区域 1”不同。 使用多个订阅操作时，应了解这些映射，以选择以最佳方式提升性能的区域。

评估网络要求

评估网络需要确定适当的工作负载服务和配置。 确保网络可以支持你的工作负载。 若要评估网络要求，请考虑：

  • 了解网络流量。 评估工作负荷的预期网络流量。 了解数据传输需求和网络请求的频率。

  • 了解带宽要求。 确定工作负载的带宽要求。 考虑通过网络传输和接收的数据量。

  • 了解网络延迟。 评估工作负荷所需的延迟。 使用专用虚拟网络和主干网络，而不是遍历公共 Internet。 此方法可降低工作负荷的延迟。

  • 了解吞吐量。 请考虑工作负荷所需的吞吐量。 吞吐量是指在给定时间内可以通过网络传输的数据量。 配置网络路由选项以利用网络吞吐量优势。

权衡：专用虚拟网络会限制公共访问，并使得部署和管理资源变得困难。

评估计算要求

评估计算要求涉及评估工作负荷的特定计算需求，包括实例类型、可伸缩性和容器化等因素。 不同的计算服务具有不同的功能和特征，可能会影响工作负荷的性能。 选择最佳计算服务以确保工作负荷高效运行。 请考虑以下策略：

  • 了解实例类型。 不同的实例类型针对不同的工作负载进行优化，例如 CPU 优化、内存优化和 GPU 实例。 选择符合需求的实例类型。

  • 请考虑自动缩放。 如果工作负荷的需求不定，请考虑具有自动缩放功能的计算服务，该功能可根据需求自动调整计算容量。 自动缩放有助于确保在高峰期拥有足够的资源，并防止在低需求时段过度预配。

  • 请考虑容器化。 与非容器化工作负载相比，容器具有性能优势。 如果适合体系结构需求，请考虑使用容器化。 容器通过隔离、资源效率、快速启动时间和可移植性来提高计算性能。

    使用容器时，请考虑设计因素，例如将所有应用程序组件容器化。 将基于 Linux 的容器运行时用于轻型映像。 为容器提供较短的生命周期，使其不可变且可替换。 从容器、容器主机和基础群集收集相关日志和指标。 使用此数据监视和分析性能。 容器只是整体体系结构的一个组件。 选择适当的容器业务流程协调程序（如 Kubernetes），以进一步增强性能和可伸缩性。

    容器权益 说明
    隔离 容器为应用程序提供隔离的环境。 容器可确保应用程序资源不会相互干扰。 这种隔离可确保分配给容器的计算资源专用于运行特定应用程序，从而提高性能。
    资源效率 容器是轻型的，共享主机操作系统的内核，从而可以有效地利用资源。 多个容器可以在同一虚拟化基础结构上运行，从而最大限度地利用计算资源。
    快速启动时间 容器映像是预生成的，可在需要时快速启动。 这种快速的启动时间可实现快速的可伸缩性。 它允许应用程序根据需要纵向扩展或缩减，并避免性能瓶颈。
    可移植性 容器封装映像中的所有必需依赖项和库。 借助容器，可以更轻松地跨不同的操作系统或环境移动应用程序。 这种可移植性可灵活部署应用程序，并允许在云提供商或本地环境之间轻松迁移。

  • 选择适当的层。 在每个计算服务中，可以设置计算容量、选择功能和启用功能。 根据性能目标，为计算服务选择适当的服务层级。

  • 确定实例计数。 确定工作负荷所需的最小实例计数。 某些工作负载（即使在最低负载下）可能需要计算资源的多个实例。 相应地设置最小实例计数。

评估负载均衡要求

负载均衡可确保网络流量均匀分布，并防止任何单个服务器因请求过多而过载。 负载均衡有助于防止瓶颈和缩短响应时间。 评估云提供商提供的不同负载均衡服务。 查看云提供商的文档和比较工具以了解这些功能。 选择最适合工作负荷的服务。 若要选择负载均衡服务，请考虑：

  • 了解流量类型：确定负载均衡服务是否需要处理 Web 流量（如 HTTP 和 HTTPS）或其他协议，例如传输控制协议 (TCP) 或用户数据报协议 (UDP) 。

  • 了解全局或区域路由：确定工作负荷是在特定区域内还是跨多个区域进行负载均衡。

  • 了解 SLO) (服务级别目标 ：请考虑服务级别协议 (SLA) 。 不同的负载均衡服务提供不同级别的性能。

  • 了解功能：考虑提供站点加速、最佳流量分布和低延迟第 4 层负载均衡的负载均衡服务。

评估数据存储要求

评估数据存储要求是评估存储、检索和管理数据的特定需求和条件。 此评估考虑数据量、访问速度、一致性和持续性等因素。 根据不同的业务和技术要求，工作负荷可能需要多种类型的数据存储。 确定正确的数据存储服务和适当的实现有助于防止瓶颈并确保快速访问数据。

评估数据库要求

数据库可能会影响数据存储和检索、事务处理、一致性保证以及处理大型或快速变化的数据等因素。 评估数据库的需求和条件。 选择可以满足这些要求的数据库系统。 在选择数据库之前，请评估数据库要求。 若要评估数据库要求并选择合适的数据库，请执行以下步骤：

  • 确定工作负载需求。 了解工作负荷的特定要求，例如数据量、预期的事务速率、并发性、数据类型和预期增长。 根据工作负载需求评估不同的数据库系统。 例如，如果工作负载需要高性能实时数据处理，则可以选择针对快速数据引入和低延迟进行优化的数据库系统。

  • 考虑数据模型。 确定最适合工作负荷的数据模型。 评估数据库要求，确保所选数据库支持所需的数据结构、关系和完整性约束。 例如，如果数据具有高度关系结构，则可以选择关系数据库管理系统 (RDBMS) ，为事务和引用完整性提供可靠的支持。 数据模型可以是分层模型、网络模型、关系模型、面向对象模型或 NoSQL。 评估数据模型的复杂性。 确保所选数据库支持所需的数据结构和关系。

  • 评估功能。 请考虑读取/写入模式、查询复杂性、延迟要求和可伸缩性需求等因素。 相应地评估不同数据库系统的性能。 某些数据库擅长读取密集型工作负载，而其他数据库则针对写入密集型或分析工作负载进行了优化。

  • 评估负载。 考虑数据量、事务速率、读/写比率和预期增长等因素。 选择可以处理预期工作负荷的数据库，以确保顺利运行，并防止在扩展工作负荷时出现性能瓶颈。 请考虑工作负荷的可伸缩性要求。 这些要求包括预期的数据增长、并发用户访问以及水平或垂直缩放的需求。 评估不同数据库系统提供的可伸缩性选项和可用性功能。

评估存储要求

选择符合数据访问模式、持续性要求和性能需求的存储服务。 大多数云工作负载使用存储技术的组合。 此方法称为多语言持久性方法。 确定适合工作负荷的存储服务组合。 你可能还希望分离数据以避免污染。 例如，你可能有单独的存储帐户来监视数据和业务数据。 选择正确的组合和正确的实现对于优化应用程序性能非常重要。

评估缓存要求

缓存存储经常访问的数据。 缓存可减少数据访问延迟，并降低数据存储组件的负载。 它允许工作负载在不缩放的情况下处理更多请求。 缓存工作负载数据和静态内容很常见。 Redis 缓存可以存储会话数据、数据库结果、API 响应和引用数据，例如配置设置。 内容分发网络或静态 Web 应用可以缓存和提供静态内容。 请考虑缓存数据以提高工作负荷性能。 为工作负载选择适当的缓存选项，优先使用平台缓存服务，例如 Azure Redis 缓存，而不是自定义或自承载服务。

Azure 简化

了解要求：使用 Azure Monitor 收集和分析工作负载中的数据。 监视器提供工作负载性能和运行状况的见解，使你能够识别和排查问题。

了解和评估服务：查看 Azure 服务和产品 以确定它们是否满足性能要求。 Azure 提供了多个可实现相同结果的服务。 你可以灵活地根据性能需求、团队技能集和成本要求调整所选服务。

有关最常见的 Azure 限制的列表，请参阅 Azure 订阅和服务限制、配额与约束。

查询限制和配额示例演示如何查询常用资源的限制和配额。

Azure 有许多服务可以容纳任何工作负载。 查看每种服务类型的 选择指南 ，以帮助你根据要求简化选择。 请参阅以下指南进行选择：

性能效率清单

请参阅完整的建议集。

性能效率清单