用于选择正确服务的体系结构策略

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

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

定义

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

了解工作负荷要求

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

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

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

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

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

• 考虑团队技能。 你的团队构建和维护工作负荷。 不同的服务需要不同的技能。 选择团队知道如何使用的服务，或在选择服务之前提交培训服务。 确保团队成员拥有专业知识和知识，以有效使用服务并优化其性能。

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

了解服务

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

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

了解服务限制

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

首选平台功能

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

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

评估基础结构要求

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

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

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

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

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

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

评估网络要求

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

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

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

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

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

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

评估计算要求

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

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

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

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

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

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

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

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

评估负载均衡要求

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

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

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

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

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

评估数据存储要求

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

评估数据库要求

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

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

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

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

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

评估存储要求

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

评估缓存要求

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

Azure 便利化

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

了解和评估服务：查看 Azure 服务和产品 ，以确定它们是否符合性能要求。 Azure 提供多种服务来实现相同的结果。 你可以灵活地将所选服务与性能需求、团队技能集和成本要求保持一致。

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

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

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

• 区域
• 计算服务
• 容器服务
• 数据存储服务
• 负载均衡服务
• 存储服务

相关链接

• 支持可用性区域的 Azure 区域
• 有关定义性能目标的建议
• 有关使用可用性区域和区域的建议
• 什么是可用性区域？
• 选择 Azure 区域

性能效率清单

请参阅完整的建议集。