你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure API 管理是跨所有环境（包括混合和多云）API 的管理平台和网关。 作为平台即服务（PaaS）解决方案，API 管理可帮助支持工作负荷的 API 生命周期。
本文假设作为架构师，你已查看 集成服务决策树 ，并选择 API 管理作为工作负载的集成服务。 本文中的指南提供了映射到 Well-Architected 框架支柱原则的体系结构建议。
重要
如何使用本指南
每个部分都有一个 设计清单，该清单提供关注的体系结构区域以及本地化为技术范围的设计策略。
此外，还包括有助于具体化这些策略的技术功能的建议。 这些建议并不表示可用于 API 管理或工作负荷后端 API 服务器的所有配置的详尽列表。 而是列出与设计视角相匹配的关键建议。 使用建议生成概念证明或优化现有环境。
演示主要建议的基础体系结构： API 管理登陆区域体系结构。
技术范围
此审查重点讨论以下 Azure 资源的相互关联决策：
- Azure API 管理
本指南的范围是 API 管理服务，主要是网关组件（数据平面），它代理来自客户端应用程序的 API 请求到托管在各种平台或跨界位置上的后端 API。 工作负荷的体系结构应考虑到 API 管理控制平面和相关组件，例如访问网关的客户端应用程序和处理路由请求的后端 API。 它还集成了支持 Azure 服务，包括网络、监视、标识管理和其他功能。
本指南不包括 Azure API 中心。 它旨在解决 API 级别主题，因为它们与 API 管理相关，并不涉及为 API 设计注意事项提供精巧的观点。
注释
并非所有建议都适用于 API 管理的所有 服务层 。 本指南中的许多建议侧重于 API 管理的标准 v2 和经典高级层，这是大多数企业工作负荷的建议生产层。
重要
具有企业功能的 Premium v2 层处于预览状态。 为了确定您的设计是否应依赖于抢先体验功能或普遍可用功能，请评估您的设计和实施时间线，并与有关 Premium v2 发布和迁移路径的可用信息进行比较。
可靠性
可靠性支柱的目的是通过 建立足够的复原能力和从故障快速恢复来提供持续的功能。
可靠性设计原则 为各个组件、系统流和整个系统提供高级设计策略。
设计清单
根据可靠性设计评审核对清单开始实施您的设计策略。 确定其与业务需求的相关性，同时记住 API 管理和依赖项的层和功能。 扩展策略以根据需要包含更多方法。
评估网关功能的可靠性与冗余： 确定满足每个环境工作负载可靠性要求所需的 API 管理 层和功能 。
评估网关冗余功能，包括可用性区域、多个网关单元、多个区域和工作区。 高级层支持这些功能。 开发人员层（不包括服务级别协议（SLA））不适合用于生产工作负荷。 考虑采用诸如外部缓存等功能的利弊，这些功能可能会带来潜在的故障点和性能瓶颈。
查看可观测性功能： 考虑服务的 可观测性功能，包括 Azure Monitor 日志和指标、Application Insights、内置分析和内置诊断。 使用这些功能监视工作负荷的可靠性信号。
例如，请考虑使用 Azure Monitor 警报 来通知 API 管理网关或其依赖项的潜在问题。
查看缩放策略：通过添加单元来维持服务可靠性，定义网关横向扩展的条件。 考虑是根据请求、异常还是两者来进行缩放。 评估缩放网关组件对工作负荷的其他组件的影响。 例如，它对网络地址空间和后端的缩放功能的影响。
隔离关键工作负荷： 确定是否需要计算隔离来满足 API 中的工作负荷要求，例如数据主权或性能优化。 将专用网关用于关键 API，将共享网关用于不太关键的 API。
选择隔离方法，例如使用 专用工作区网关 或单独的 API 管理实例。 对于多个实例，请将环境保持同步，作为安全部署实践的一部分。
服务级别目标 (SLO) 对齐：制定工作负载的 SLO 时，将网关的 SLA 范围考虑在内。 该服务提供自己的 SLA，但还需要考虑其他工作负荷组件的预期可靠性，例如 API 后端。
解决后端故障： 规划预期和意外后端故障。 在这些方案中测试客户端体验。 评估网关 策略 以提高复原能力并增强客户端体验。 重点介绍 API 规范中所述的配额、速率限制、重试策略、后端断路器、负载均衡和异常处理。
定义测试策略： 使用来自网络内的 Azure 负载测试 等测试解决方案来反映实际生产工作负荷。 不要依赖于已发布的吞吐量或其他可能不适用于工作负荷的估计。
规划灾难恢复（DR）： 查看用于备份和还原网关基础结构和 API 的选项。 在某些情况下，内置 备份和还原功能 可能很有用。 但是，也可以考虑客户管理的选项，例如 APIOps 工具和基础结构即代码（IaC）解决方案。 制定维护其他系统数据（包括用户订阅）的策略。
建议
这些可靠性建议可以应用于服务本身或流经 API 及其策略的流量。 （服务）或（API）指定符指示建议是针对服务还是 API。
| 建议 | 益处 |
|---|---|
| （服务）在高级层中启用 区域冗余 ，并且至少部署了三个单元。 在此配置中，在正常作条件下，所有已配置区域中的所有缩放单元都处于活动状态，并为网关流量提供服务。 在任何主动-主动应用场景下，计划在剩余的活动区域中支持横向扩展来处理原本由故障区域中的单元处理的流量。 |
在区域内数据中心中断期间，可以确保复原能力。 在数据中心完全丢失期间，API 流量将继续流经部署在其他区域中的剩余单元。 |
| （服务）启用基于流量需求的自动扩展。 在多区域部署中，次要区域没有自动扩容或自动缩容功能。 需要实现一个自定义函数或逻辑应用，以响应 Azure Monitor 指标警报以按需管理单元调整。 |
保证有足够的资源来满足 API 客户端的需求，这可以防止由于容量不足而导致故障。 |
| （服务）使用 多区域拓扑 支持针对完整区域故障的复原能力。 此方法要求你与工作负荷中的其他组件协调，并了解其计划的故障转移特征。 在任何主动-主动场景中，计划支持在剩余活跃区域内扩容，以处理原本由现已非活跃区域处理的流量。 确保多区域拓扑符合传输中的数据或缓存驻留中的数据的任何符合性要求。 |
在完整的区域中断期间提供可靠的复原能力，这有助于通过部署在其他区域中的单元确保不间断的 API 流量。 |
| （服务）将不相关的 API 与 工作区 或其他 API 管理实例隔离。 | 错误配置或中断导致的故障影响最小化，方法是将 API 分离到不同的计算实例中。 |
| （API）全面测试策略表达式和逻辑，并将其与 API 管理策略中的 弹性错误处理技术 配对。 | 通过防止网关上的新故障源并提供正常降级或安全的暂时性故障处理来增强客户端体验。 |
| （服务与 API） 收集可靠性指标。 典型的 API 可靠性指标包括： - 速率限制和配额违规。 - 基于 HTTP 状态代码的错误率。 - 请求速率与基线的偏差。 - 健康检查，包括依赖关系健康。 |
标识与预期行为和过去的基线的偏差。 此数据可用于跟踪根本原因，例如更改的用户行为、常规作的干扰、新功能的意外影响或工作负荷中的计划外故障。 |
| （服务与 API）使用 API 管理中内置的 备份和还原 功能作为 DR playbook 的一部分。 通过 IaC 工件和 APIOps 流程增强这些功能，形成一个能够应对各种场景的强健解决方案，包括与依赖项和后端的故障恢复协调。 | 通过在系统完全丢失后允许恢复 API 网关并还原预设的 API 来确保业务连续性。 |
安全
安全支柱的目的是为工作负荷提供 保密性、完整性和可用性 保证。
安全设计原则通过对保护 API 管理网关的技术设计方法应用方法，为实现这些目标提供了高级设计策略。
注释
本部分中的清单和建议侧重于保护 API 管理网关资源。 仅对 API 本身的安全问题略加讨论。 有关详细信息，请参阅 API 管理中的缓解 OWASP API 安全十大问题。
设计清单
根据 设计评审清单制定针对安全 的设计策略，并确定漏洞和控制，以增强安全防御能力。 扩展策略以根据需要包含更多方法。
建立安全基线： 查看 API 管理的安全基线 ，并在基线中包含适用的度量值。
保护部署管道： 确定管理服务平台、持续集成和持续部署（CI/CD）管道以及单个 API 所需的个人和基于角色的访问控制角色。 确保只有经过授权的个人有权管理服务及其 API。
评估数据敏感度： 如果敏感数据在 API 管理网关中流经 API 请求和响应，请确保其在整个生命周期内受到保护。 考虑不同区域的不同数据保护要求。 评估服务功能（例如 多个区域 ）以隔离特定数据。 此外，请确认缓存策略是否符合这些隔离要求。
在共享网关上制定分段策略： 如果 API 管理实例托管多个工作负荷团队的 API，请使用 工作区 来隔离角色、网络和可能网关。 此方法可确保每个团队对管理 API 进行适当的访问和控制，同时限制对其他团队 API 的访问。
考虑网络控制： 使用 虚拟网络确定隔离或筛选入站和出站网关流量的要求和选项。 确定是否可以通过 Azure 专用链接限制对网关的访问，或者是否需要对网关的公共访问。 评估体系结构是否应包括 Web 应用程序防火墙（例如 Azure 应用程序网关中的 Azure Web 应用程序防火墙或 Azure Front Door），以实现所需的网络隔离并筛选网络流量。
考虑 API 身份验证和授权的功能： 评估标识提供者（如 Microsoft Entra ID）的使用（包括内置组），或 Microsoft Entra 外部 ID 来筛选网关请求，并为后端 API 启用 OAuth 授权。
加密网络流量： 确定工作负载可以支持的最安全的传输层安全性（TLS） 协议版本和密码 。 不需要不安全的 TLS 版本。 客户端支持时使用 TLS 1.3。
对 API 管理执行威胁建模并减少其外围应用： 确定是否可以禁用、限制或删除特定的 API 管理组件，例如直接管理 API 或对开发人员门户的公共访问。
确定工作负荷所需的机密： 网关作可能需要证书、API 密钥或其他机密值。 查看 Azure Key Vault 的要求和功能，以存储机密和证书。 或查看内置的 API 管理功能，例如 命名值 和 托管证书。
建议
这些安全建议可以应用于服务本身或流经 API 及其策略的流量。 （服务）或（API）指定符指示建议是针对服务还是 API。
| 建议 | 益处 |
|---|---|
| （服务）禁用已弃用的 直接管理 API。 使用 Azure 资源管理器作为控制平面。 | 通过删除控制平面接入点来减少服务的表面积。 |
| （服务）仅根据合法客户端从何处进行连接来限制网关的公开。 - 当所有客户端都可以通过虚拟网络路由流量时，使用没有公共 IP 地址的虚拟网络注入。 使用 网络安全组（NSG） 进一步将流量限制为仅预期客户端源 IP 地址。 - 如果必须通过 Internet 传输任何流量，请使用应用程序网关或 Azure Front Door 的虚拟网络集成。 将 NSG 配置为仅接受来自单个入口点的流量。 |
网络流量的机密性通过限制对预期包含合法客户端的源 IP 地址范围进行公开来保护。 这些限制阻止来自不应启动合法客户端通信的源的访问。 限制对合法流量源的公开可增强服务的保密性、完整性和可用性。 |
| （服务）禁用 开发人员门户 （如果未使用）。 如果门户正在使用， 请禁用注册体验、 禁用匿名访问，并仅限制对受信任的网络位置的访问。 | 减少了服务的外围应用以及错误配置或忽略的几率。 |
| （服务）为客户端和后端显式设置最窄支持的 TLS 版本、协议和密码 。 | 将版本和支持的密码减少到仅客户端和后端支持的那些选项。 此方法有助于确保连接优先于可能实现机密性的最高等级连接。 |
| （服务）将 自定义证书存储在 Key Vault 中。 | 证书管理功能是使用 Key Vault 提供的，它支持常规轮换和审核对证书的访问。 |
| （服务）后端应仅接受来自 API 网关的流量，并应阻止所有其他流量。 | 阻止恶意流量绕过卸载到网关的安全和其他交叉关注点。 |
| （服务）对于为多个团队或分段工作负荷托管 API 的 API 管理实例，必须设计可靠的访问控制隔离策略。 使用 工作区 或实现严格的 APIOps 过程 来实现此策略。 各个团队只能访问他们各自拥有的 API。 它们不应有权访问可能托管在同一实例中的其他 API。 |
减少了攻击者从一个遭入侵的 API 集横向移动到其他不相关 API 的情况。 |
| （API） 将机密存储在 Key Vault 中，并通过命名值将其公开给策略。 不要使用 Key Vault 来存储非机密。 直接为这些值使用命名值属性。 | 建议通过密钥保管库的统一管理平台进行机密轮换，这类似于证书的方法。 此过程可确保相应地更新 API 管理。 命名值还可以确保机密和非机密的策略配置体验一致。 Key Vault 中还会审核所有机密访问，以提供访问历史记录。 仅将机密存储在 Key Vault 中可最大程度地减少对 Key Vault 的依赖关系，并且不会将 Key Vault 转换为应用程序配置服务。 |
| （API）通过使用 身份验证-托管标识 策略，为不同的 API 分配不同的用户托管标识。 | 每个 API 都启用了独立的标识，该标识通过每个 API 的最小特权访问支持分段目标。 它还在后端系统中提供更好的可审核性。 |
| （API）如果可能，要求客户端 使用 OAuth 2.0 流进行身份验证 ，而不是仅使用预共享密钥（包括 订阅密钥 或 客户端证书）。 | 改进了用于审核目的的客户端标识，消除了密钥轮换，与使用预共享密钥相比，保护机密的客户端负担会降低。 |
| （API）通过使用可能公开实现详细信息的 set-header 策略，禁止来自 API 响应的 HTTP 标头。 | 通过不发送实现信息，增加了攻击者的成本。 |
| （API）请勿在生产环境中使用 API 跟踪 。 | 阻止在请求跟踪中公开敏感数据。 |
| (API) 使用 Defender for API。 | 提供了 API 安全见解、建议和威胁检测。 |
| （API）通过在 API 策略中委托密钥安全检查来保护后端资源，例如 validate-jwt、 ip-filter、 validate-headers、 validate-content。 | 通过在网关进行安全检查，减少到达后端服务的非法流量。 这种卸载方法有助于保护这些资源的完整性和可用性。 |
| （API）将 安全开发生命周期（SDL） 做法应用于 API 策略更改的方式与对工作负载中的应用程序代码应用建议的更改相同。 具有高特权 API 流量视图的策略执行。 | 阻止避开遭入侵的 API 网关的保密性、完整性和可用性后端保护。 |
| （服务与 API）将 托管标识 用于服务和 API 依赖项。 | 与 Key Vault、Azure 事件中心和其他依赖项（例如证书和命名值）的连接是建立的，而无需依赖于预共享机密。 |
| （服务与 API）尽可能通过专用网络连接连接到 Key Vault、事件中心和后端等依赖项。 | 通过不公开专用网络之外的流量来保护流量的机密性。 |
| （服务与 API）面向 Internet 公开 API 的客户端流量应首先通过 Web 应用程序防火墙（例如 Web 应用程序防火墙），然后才能到达 API 管理。 此外，使用 Azure DDoS 防护保护公共终结点。 | 使用 Web 应用程序防火墙进行安全检查，以减少到达网关和后端服务的非合法流量。 减少此流量有助于保护这些资源的完整性和可用性。 |
| （服务与 API）评估和启用与工作负荷相关的所有 Azure Policy 法规遵从性控制 措施。 | API 管理实例与期望的状况一致，并通过制定安全策略在工作负载不断变化时保持一致。 |
成本优化
成本优化侧重于 检测支出模式、优先考虑关键领域的投资，以及优化其他 以满足组织预算，同时满足业务需求。
成本优化设计原则为实现这些目标并提供高级设计策略，并在与 API 管理及其环境相关的技术设计中做出权衡。
设计清单
请考虑 API 管理成本模型： 将 Azure 定价计算器 与组织的帐户权益和 SLA 和可伸缩性条件配合使用，以开发使用 API 管理服务层的准确成本估算。 确定是否需要退款模型，并确定如何根据指标、标记和令牌计算它。
服务成本模型主要受服务层级、单位数和网关数的影响。 评估与维护预留单元或实现主动-被动 DR 配置相关的额外成本。
如果实现 工作区，请评估使用独立与共享工作区网关来解决各种 API 团队或利益干系人的不同 API 流要求的成本。
估计缩放成本： 制定缩放条件，以保持网关资源的高使用率。 评估预生产环境中的基线成本，并执行测试，以根据预期工作负荷流量对横向扩展的成本进行建模。
设计一种缓解策略来防止滥用网关，这可能导致缩放成本高昂，超出预期使用量。
优化逻辑放置： 评估后端服务器是否对处理逻辑更具成本效益，或者网关是否应处理资源使用情况。 虽然网关是一种实施交叉关注点的强大组件，但在某些应用场景下可能会执行过多功能。 确定网关执行的资源密集型请求处理任务，并确定将逻辑移到后端服务器是否可以降低成本。
建议
这些成本优化建议可以应用于服务本身或流经 API 及其策略的流量。 （服务）或（API）指定符指示建议是针对服务还是 API。
| 建议 | 益处 |
|---|---|
| （服务）使用支持工作负荷要求的 成本最低的级别。 例如，如果工作负载不会从增加的功能中获益，投资回报率 (ROI) 不尽理想，则请选择标准层而不是高级层。 | 避免购买未使用或使用不足的能力。 |
| （服务）在较低环境中使用 非生产层 或暂时性基础结构，例如开发环境、概念证明部署和初始成本建模活动。 | 在环境无需完全复制生产的确切配置或运行时间要求即可保持有用的情况下，资源成本得以节省。 |
| （服务）当需求减少时进行横向缩减。 配置 自动缩放规则 或其他自动化过程，以在网关容量低于定义的阈值时减少单位数。 | 通过将容量与需求相匹配来降低不必要的成本。 |
| （服务）通过使用工作区来为 API 管理提供服务，同时确保团队隔离，以计算联合模型的任何成本优势。 | 减少了部署和管理外围。 此方法旨在从时间和资源购买中实现规模经济。 |
| （服务）当不再使用时解除工作区。 | 避免对未使用的资源进行支出。 |
| （服务）如果工作负荷的缓存数据符合层中内置缓存的约束，请使用内置 缓存 。 | 避免了购买和维护与 Redis 兼容的外部缓存所涉及的成本。 |
| （服务）在使用网络控制、 DDoS 防护和 Web 应用程序防火墙到达网关之前阻止恶意流量。 特定层级的 API 管理会根据网关处理的 HTTP 请求操作数量产生费用。 因此，不需要的流量（如机器人生成的请求）可能会增加成本。 评估阻塞机制的成本与减少HTTP操作的预估成本，来评估这种方法是否具有投资回报率。 |
由于针对网关的恶意或滋扰性的 HTTP 操作过多而产生的费用有所减少。 |
| （API）优化 策略表达式和处理 和代码，以避免过多的计算资源使用情况，例如处理器、网络或内存。 | 避免对更多单元进行不必要的部署，以便为未优化的策略实现和代码提供容量。 |
| （API）评估网关、后端或公共入口点（例如，Azure Front Door）几者之间的逻辑放置成本。 同一处理通常发生在这些层中的任何一个，每个层都有其自己的利弊。 但是，由于该级别可用的未使用容量，某些层可能会节省成本。 例如，最初在后端实现的缓存逻辑，可以通过使用内置缓存在网关级别更有效地实现，从而降低成本。 此方法可减少后端服务的额外网络和计算开销。 | 通过在最经济高效的层中放置功能，将高成本资源的负载降到最低。 此方法将工作负荷转移到具有备用容量或低成本计算选项的层。 |
卓越运营
卓越运营主要侧重于 开发实践、可观测性和发布管理的各个过程。
卓越运营设计原则 提供了一个高级设计策略，用于实现这些运营需求目标。
根据 卓越运营的设计评审清单 启动设计策略，以定义与 API 管理相关的可观测性、测试和部署过程。
设计清单
查看作服务所需的关键知识和技能： 领域包括 API 生命周期、DevOps 进程、网络和连接、监视和可观测性以及软件开发。 此方法包含策略配置、单元测试和 CI/CD 管道的创建。
请考虑文档需求： 组织应致力于记录服务级别和 API 级配置、生命周期作以及 API 团队的不同访问模式的过程。
评估标准工具 以支持服务操作。 例如，采用 APIOps 方法（如 GitOps 和 CI/CD）发布 API 和管理 API 配置。 使用 IaC 工具进行服务级别配置更改。 设计可无缝从开发环境过渡到生产环境的可重用组件。 考虑将 Linter 工具（例如 Spectral）集成到 API 审批管道中，可以选择自行管理或集成到 Azure 服务中，如 Azure API 中心。
确定关键运营指标和日志： 查看生产的指标。 这些指标包括网关容量、CPU 使用率、内存使用情况和请求数。 查看日志和 可观测性工具，例如 Azure Monitor 和 Application Insights。 确定在生产环境中有效管理大量观察数据所需的策略和工具。 确定能够为网关运营商和监视特定托管 API 的利益相关者提供可操作见解的查询。
使用负载测试计划定期测试生产工作负载。
识别在 CI/CD 或 IaC 过程之外需要自动化的操作任务。 在 API 管理策略源管理、Azure 策略和特定开发人员门户配置等领域规划自动化。
建议
这些卓越运营建议适用于服务本身或流经 API 及其策略的流量。 （服务）或（API）指定符指示建议是针对服务还是 API。
| 建议 | 益处 |
|---|---|
| （服务） 为 API 管理配置 Azure 诊断资源日志。 | 平台生成的日志可用于查询日常作、按需需求或紧急方案，例如安全审核。 |
（服务）根据 API 管理实例引发的有意义的事件（例如 APICreated），使用 Azure 事件网格实现自动化。 |
可以围绕 API 管理实例中发生的关键生命周期事件生成自动化或通知任务。 |
| （服务）如果应用场景中有 Microsoft 托管的网关单元可正常工作，则避免使用自托管网关。 | 可以围绕 API 管理实例中发生的关键生命周期事件生成自动化或通知任务。 |
| （服务）应用所有 内置 Azure Policy 策略 ，这些策略可帮助你管理实例并约束它以符合工作负载要求，包括安全要求。 例如，使用 拒绝 策略防止通过 HTTP 公开 API 或防止启用直接管理 REST API。 如果拒绝策略不可用，请使用 审核 策略，或者创建自定义拒绝策略（如果对工作负荷很重要）。 | API 管理实例与设计保持一致，并且随着工作负荷的发展而保持一致。 |
| （服务）熟悉 Azure 门户中的 诊断和解决问题 功能。 使用门户中的 “网络状态”边栏选项卡 排查网络连接问题。 |
站点可靠性工程人员可以识别和排查所有环境中的网关性能、服务可用性和网络连接问题。 |
| （API）使用 事件中心 处理 API 调用中的日志或事件流，这些调用需要近实时反应或短时周期窗口化操作。 | 提供了日志条目的近实时可用性。 避免在 API 中登录到 Azure Monitor 时发生的 日志数据引入延迟 。 |
| （API）支持在开发中使用 API 跟踪 来帮助开发人员了解其策略实现。 | 开发人员工作效率通过提供有关 API 中策略实现的见解来优化。 如果没有此功能，开发人员需要在策略实现中引入黑客攻击以获取见解。 |
| （API）始终使用 API 管理的 后端功能 来定义后端。 使用 set-backend-service 在策略中按 ID 引用这些后端。 负载均衡后端应定义为 后端池。 | 后端连接更改适用于使用后端的所有 API，而无需更新单个策略代码。 错误配置或忽略的 API 策略更改的风险会降低，并且多个 API 共享同一后端的方案适合通过这一层配置抽象。 |
| （API）设计 API 的版本控制方法，使其与 API 管理 的版本控制和修订功能保持一致。 将此方法纳入 API 部署操作。 | API 管理现成支持的 API 版本控制策略用于利用内置功能，而不是生成自定义解决方案。 |
| （服务与 API）定义用于添加、修改和删除 API 的一致且可持续的作过程。 确定是否通过门户手动管理此体验，还是通过 APIOps 过程实现此体验。 首选使用基于 IaC 的方法，而不是基于门户的方法。 API 管理在资源管理器 API 中的表示形式包含许多 子资源，因此必须采用基于 IaC 的 分层方法来 管理此资源集合。 |
API 规范及其网关实现已集成到工作负荷的变更控制流程中。 此方法可防止处理后端 API 的更改，这与通过网关向 API 客户端公开的方式不同。 |
性能效率
性能效率就是通过管理容量来保持用户体验，即使负载增加也不例外。 该策略包括缩放资源、识别和优化潜在瓶颈，以及优化峰值性能。
性能效率设计原则 提供了一个高级设计策略，用于根据预期使用量实现这些容量目标。
根据 性能效率的设计评审清单 ，根据 API 管理的关键绩效指标定义基线，启动设计策略。
设计清单
定义性能目标： 用于评估 API 管理网关性能的关键指标包括容量指标，例如网关基础结构的 CPU 和内存使用率百分比、请求持续时间和请求吞吐量。 在多区域部署中，为每个区域定义性能目标。 客户需要根据流量模式、API 工作负载和缩放时间定义适当的缩放阈值。
收集性能数据： 查看内置分析、Azure Monitor 指标、Azure Monitor 日志、Application Insights 和事件中心的功能，以收集和分析不同粒度级别的性能。
查看如何识别实时性能问题： 实时性能问题的指标包括 Azure 服务可用性、HTTP 响应错误和门户中诊断 和解决问题 部分引发的错误。 使用 Azure 门户中 API 管理诊断提供的 Application Insights、Kusto 查询和建议来排查性能和可用性问题。
测试性能： 使用负载测试在生产条件下测试性能。
评估可能提高性能的相邻服务： 缓存策略或外部缓存可能会提高特定 API作的性能。 Azure Front Door 和应用程序网关是 TLS 卸载的常见选择。
查看记录的限制和约束：API 管理具有限制和约束。 查看记录的约束，并将其与工作负载的要求进行比较，以确定是否需要设计避免这些约束的解决方案。
建议
这些性能效率建议可以应用于服务本身或流经 API 及其策略的流量。 （服务）或（API）指定符指示建议是针对服务还是 API。
| 建议 | 益处 |
|---|---|
| （服务）动态扩展以应对需求的变化。 配置 自动缩放规则 或其他自动化过程，以调整网关单元以匹配目标使用容量。 | 弹性是基于并发使用量实现的，这可以防止当前部署的单位的资源耗尽或容量过度分配。 |
| （API）通过对大型请求正文使用验证-内容策略或维持大量的活动 WebSockets，最大限度减少处理成本高的任务（例如，生成大缓冲的有效负载大小）。 | 减少了缩放单元上的负载，让它们无需先进行横向扩展即可并发处理更多请求。 |
| （服务与 API） 收集性能指标。 常见的 API 性能指标包括： - 网关本身以及整个操作的请求处理时间。 - 网关单元资源使用情况指标。 - 吞吐量度量，例如每秒请求数或每秒兆位。 - 缓存命中率百分比。 |
实际性能根据工作负荷的目标进行度量。 |
| （服务与 API） 为 Application Insights 定义一个采样百分比，该百分比 可提供足够的可见性，而不会影响性能。 | 满足可观测性数据需求，不会影响整体性能。 |
| （服务与 API）评估逻辑在网关、后端或公共入口点（例如 Azure Front Door）之间的放置对性能的影响。 相同的处理任务可以在这些层中的任何一个发生，每个层都有性能权衡，以及优化机会方面的限制。 如果某个任务（如 API 管理 API 策略）引入过多的延迟，请考虑该任务是否可以以更优化的方式在其他位置运行。 | 向 API 添加延迟的任务在经过优化的计算上运行，以满足工作负荷要求。 |
Azure 策略
Azure 提供了一组与 API 管理及其依赖项相关的大量内置策略。 可以通过 Azure Policy 审核上述一些建议。 例如，可以检查以下情况：
- 网关配置为区域冗余。
- API 管理网关设置了适当的网络控制，例如，在虚拟网络中进行部署。
- 无法公开访问服务配置终结点。
- 直接管理 REST API 已禁用。
若要进行全面的治理，请查看 Azure Policy 内置定义 和其他可能影响 API 管理网关安全性的策略。
Azure 顾问建议
Azure 顾问是一名个性化的云顾问，可帮助你遵循最佳做法来优化 Azure 部署。
有关详细信息，请参阅 Azure 顾问。
顾问可能会在生产系统中提出其他建议，例如：
- 在 validate-jwt 策略中未能要求长的 JWT 密钥大小。
- 你使用了旧版资源管理器 API 版本来部署资源。
- API 密钥令牌接近其到期日期。
- 证书轮换操作失败。
权衡
如果使用支柱清单中的方法，可能需要进行设计权衡。 下面是一些优点和缺点示例。
通过冗余和隔离实现高可用性
高可用性。 将冗余添加到体系结构会影响成本。 例如，至少预配三个单元以避免区域中断在经济上对于工作负载而言可能并不可行的情况。 使用多区域体系结构进一步增加成本，这至少需要 6 个单位，或每个区域的 3 个单位。 多区域设置还增加了协调安全部署、可靠缩放和与后端的故障转移协调的运营成本。
隔离。 跨工作区或 API 管理实例隔离工作负载会增加操作复杂性，因为其中包含管理具有计算隔离的多租户系统。
缩放以满足需求
自动横向扩展以满足行为良好的客户端的需求时，这些成本已纳入成本模型。 但是，此缩放功能还允许服务缩放以处理来自滋扰和恶意流量的流量。
控制不必要的流量会产生成本。 添加 Web 应用程序防火墙和 DDoS 保护等服务会增加费用。 缩放服务来处理流量会由于新增的单元致使成本增加。 设置上限的缩放限制可能会限制支出，但如果恶意或有害的流量使 API 不堪重负，则可能会导致合法用户的可靠性问题。
联合与分布式方法
API 管理中的基本决策是是将不同的工作负荷并置在单个 API 管理实例中，还是将工作负荷隔离到完全自治拓扑中的多个实例上。
API 管理工作区可让多个 API 团队作为一个多租户场地租用平台实现高效操作。 分层定价模型旨在允许在使用网关的所有租户之间共享服务成本。 但是，与任何共置平台一样，中断或配置不当可能会导致对共享相同基础结构的不相关的工作负载产生广泛影响。
一个完全分布式模型，其中每个工作负荷团队管理自己的实例，在例行作中引入了重复成本和冗余。 但是，它为可靠性、安全性和性能相关事件提供固有的爆炸半径缓解措施。
后续步骤
API 管理通常与以下服务相结合。 如果工作负荷包含以下服务，请务必查看其服务指南或产品文档。
以下文章演示了本文中讨论的一些建议。