Microsoft AZ-204: Azure API 管理 — 学习指南

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

属于 Microsoft Azure Developer Associate AZ-204 — 学习指南. 使用经过验证的答案练习： Microsoft 考试中心, 或参加限时模拟考试： ExamRoll.io.

概述

Azure API Management (APIM) 为各种后端服务提供了一个统一的外观（façade），它将一个高性能网关与可配置的策略引擎、开发者引导流程以及一个完整的管理平面结合在一起。它能够在 REST、SOAP 和 GraphQL 后端上实现一致的安全性、限制、转换、可观测性和生命周期控制。APIM 既是处理流量的运行时网关，也是一个通过 Azure 门户、ARM/Bicep/CLI 或 CI/CD 进行管理的配置驱动系统。理解请求管道、策略功能、版本/修订、订阅模型以及各定价层的特性，是构建稳健、安全且可大规模扩展的 API 的基础。

架构、定价层和核心组件

网关是数据平面。它负责终止客户端连接，以确定性的顺序应用策略，将请求路由到后端，并返回响应。它支持内置缓存、JWT 验证、双向 TLS 以及线速内容转换。网关可以是由 Microsoft 在每个区域托管的，也可以是自承载的（容器化），以便在更靠近本地或边缘工作负载的地方运行，同时保持集中管理。网关会公开跟踪和指标，并与 Application Insights 集成以实现分布式遥测。

开发者门户是面向消费者的体验，用于 API 的发现、文档查阅和订阅管理。它能呈现 OpenAPI/GraphQL 文档，提供交互式的“试用”控制台，在浏览器中处理 OAuth 2.0 流程，并支持自定义品牌和身份提供程序。开发者可在此处自助获取产品订阅并轮换密钥。

管理平面是配置和治理的接口。它存储 API、操作、策略、产品、用户/组、后端、证书和诊断设置。可以通过 Azure 门户、ARM/Bicep/CLI/PowerShell、Management REST API 以及基于 Git 的配置同步来访问它。该平面负责协调部署、版本控制、修订和 RBAC。

APIM 的定价层决定了其规模、功能和网络能力：

Consumption（消费）层是无服务器的，按调用次数计费。它能自动扩展，非常适合流量突发或低吞吐量的场景，并支持大多数核心策略。它不包含内置的响应缓存，也缺少高级网络和多区域功能。
Developer（开发者）层用于非生产环境。它提供几乎完整的功能，但没有 SLA，也不具备生产级别的吞吐能力。
Basic（基本）和 Standard（标准）层是专用的单区域生产层，具有可预测的吞吐量、横向扩展单元和内置的响应缓存。它们适用于许多不需要多区域或高级网络功能的企业工作负载。
Premium（高级）层增加了多区域部署、高级网络功能（包括 VNet 集成）、更高的扩展性、在支持区域内的可用区，以及自承载网关的许可。对于全球性的、任务关键型的部署和私有网络环境，应选择 Premium 层。

策略和请求管道

APIM 策略是一些声明性语句，它们按照严格的顺序在四个部分中执行：入站 (inbound)、后端 (backend)、出站 (outbound) 和错误处理 (on-error)。

入站策略在请求转发到后端之前运行。典型任务包括要求或验证订阅密钥、验证 JWT（强制执行颁发者、受众、签名）、检查客户端 IP、应用速率限制和配额、规范化标头、重写 URI 以及转换负载。您可以根据条件将请求路由到不同的后端，并为后续阶段设置变量。

后端部分配置和修改对上游服务的调用。使用它来选择后端实体、附加客户端凭据（基本身份验证、客户端证书，或通过托管身份为受 Azure AD 保护的后端获取的令牌）、设置超时、启用重试以及应用断路器。到后端的双向 TLS 在此配置，通过关联一个网关将出示的客户端证书来实现。

出站策略在收到后端响应后运行。它们通常执行响应转换（例如，JSON 到 XML 或反之）、标头重写、数据整形、屏蔽内部细节以及响应缓存。这里也是应用内容协商转换或规范化状态码的地方。

错误处理策略在任何早期部分（包括后端调用）发生异常时执行。使用此部分将后端错误映射为标准化的 API 错误形态、设置适当的状态码、隐去敏感信息、添加关联 ID 或提供回退响应。

常见的策略模式：

速率限制控制突发吞吐量并保护后端。rate-limit-by-key 使用订阅密钥、JWT 声明或 IP 等密钥来强制执行基于身份的节流。对于更长的时间窗口，可与 quota-by-key 结合使用，以限制每日或每月的用量。
IP 筛选使用 ip-filter 按客户端 IP 或 CIDR 范围阻止或允许流量，通常放置在入站策略的早期阶段，以最大限度地降低成本和风险暴露。
JWT 验证使用 validate-jwt 强制执行 OpenID Connect 参数。配置 OpenID 配置 URL 或颁发者，定义可接受的受众/范围，选择必需的声明，并调整时钟偏移和令牌生命周期检查。通过要求所有不允许匿名调用的操作都必须提供有效令牌，来拒绝匿名访问。
转换包括 rewrite-uri、set-header、set-query-parameter、set-body 和 find-and-replace。使用 xml-to-json 或 json-to-xml 来桥接不匹配的客户端/后端格式，而无需更改代码。
缓存利用 cache-lookup 和 cache-store，基于可包含路径、查询、标头和 JWT 声明的密钥来缓存整个响应。使用 cache-lookup-value/cache-store-value 在策略内部进行键/值缓存，例如缓存令牌。请注意，内置响应缓存在 Consumption（消费）层中不可用。

安全性、身份和订阅

前端客户端到网关的安全性，以及后端网关到服务的安全性，都必须得到解决。

对于前端安全性，使用 Azure AD 的 OAuth 2.0 是主流模式。客户端从 Azure AD 获取令牌并将其提供给网关。APIM 使用 validate-jwt 策略来强制执行令牌要求，该策略引用 Azure AD OpenID Connect 元数据（租户的知名端点）。策略可以强制执行受众（audience）检查，以确保令牌面向正确的 API；强制执行范围（scope）声明，以确保调用者具有适当的权限；以及强制执行应用角色等可选声明。为杜绝匿名调用，应将 validate-jwt 应用于所有操作。可以为开发人员门户配置 Azure AD，以简化测试期间的令牌获取过程。

对于客户端证书和双向 TLS (mTLS)，APIM 可以要求调用者提供入站客户端证书，并使用 validate-client-certificate 策略验证颁发者/使用者/有效期，以及可选地验证 CRL/OCSP 状态。这适用于 B2B 和高保障性集成场景。对于网关到后端的 mTLS，可将客户端证书上传到 APIM，将其与后端实体或 set-backend-service 策略关联，APIM 将在 TLS 握手期间出示该证书以向后端进行身份验证。强制执行证书身份验证的安全 App Service 或自定义服务通常需要这种方法。

对于受 Azure AD 保护的后端，请在后端部分使用 authentication-managed-identity 策略，以通过 APIM 的系统分配或用户分配的托管标识来获取访问令牌。该策略会为后端调用注入 Authorization 标头。这样可以避免存储机密，并满足现代零信任要求。

订阅提供了一种粗粒度的访问和商业化模型。产品是 API 的捆绑包，受条款、审批和使用限制的约束。开发人员通过订阅产品来获取订阅密钥（主密钥和辅助密钥），这些密钥通过 Ocp-Apim-Subscription-Key 标头或查询参数使用。借助双密钥机制，可以无停机轮换密钥。订阅范围决定了密钥的应用范围：所有 API、单个 API 或特定产品。基于订阅的访问是 OAuth 2.0 的补充；可以同时要求两者，从而在身份验证依赖令牌的同时，实现独立的限制/计费。产品可以强制执行每个订阅的配额和速率限制，这独立于每个操作的策略，从而提供了分层的保护和治理。

后端、弹性、版本控制和修订

APIM 中的后端是一等的可重用实体，它封装了目标服务的基础 URL、协议、凭据、TLS 设置、标头模板和代理配置。将 API 和操作与后端关联，可将路由与策略解耦，并集中管理连接细节。在策略中使用 set-backend-service 并通过后端 ID 来路由请求，无需硬编码 URL，从而简化了在开发、测试和生产环境之间的提升过程。

弹性通过重试和断路器策略来强制执行。带指数退避的重试可以缓解瞬时故障；它们应限定于幂等操作，并设置合理的超时时间以防止放大效应。当故障率、连续故障次数或延迟在采样窗口内超过配置的阈值时，断路器策略会打开，在定义的断开持续时间内对请求进行短路处理。在打开状态下，该策略可以立即返回一个回退响应或路由到一个备用后端。当处于半开状态时，有限数量的试探性请求会探测后端健康状况，然后再关闭断路器。这可以保护后端，改善客户端体验，并在部分故障下稳定系统。

负载均衡和路由可以在策略层实现。使用 choose 的条件路由可以根据用户分段、地理位置、请求内容或健康信号来引导流量。加权路由可以通过策略表达式实现，该表达式根据期望的权重伪随机地选择一个后端，从而实现金丝雀发布和渐进式部署。对于跨区域的主-主后端，可以通过 Premium 层的多区域 APIM 部署，结合条件路由到最近的健康区域来处理；或者，与 Azure Front Door 集成以实现全局第 7 层负载均衡，而 APIM 则负责处理身份验证和转换。

版本控制和修订管理着 API 的生命周期。版本集定义了如何使用路径、查询字符串或标头等版本控制方案向客户端呈现多个 API 版本。版本用于重大变更；每个版本都是一个独立的 API 实体，与同一个版本集相关联。非重大的迭代式变更则通过修订来实现。修订是 API 的一个可变快照，可以通过修订版后缀显式调用以进行测试，而早期的修订版则仍然是当前的生产修订版。验证后，可以将新修订版提升为当前版本，而无需更改版本标识符。这种分离实现了安全的渐进式交付：修订用于非重大更新；版本用于重大变更，并通过开发者门户中的清晰发现和文档来呈现。

最后，进行观察和治理。启用跟踪，设置相关性 ID，并将诊断信息导出到 Application Insights 以实现端到端可见性。通过 ARM/Bicep 或 APIM DevOps 资源工具包管理配置以实现可重复的部署，并在管理平面上应用 RBAC，为 API 作者、发布者和操作员分离职责。

实际问题场景

星巴克必须为移动点餐应用暴露一个统一的公共 API，该 API 聚合了分布在两个 Azure 区域的微服务。该 API 必须阻止匿名访问、限制滥用型客户端、保护区域后端免受级联故障影响，并允许在不破坏 v1 客户端的情况下逐步推出 v2 订单模式。

在两个区域部署 APIM Premium 实例并启用多区域部署。选择 Premium 是因为它具备多区域网关、高级网络功能和企业级规模。区域网关可以降低移动客户端的延迟并提供主-主弹性。
将后端服务（包括两个区域中的 App Service 实例）作为 APIM 后端实体导入。后端实体集中管理基础 URL、TLS 和凭据设置，从而实现了清晰的路由策略和环境可移植性。
使用 Azure AD OAuth 2.0 保护客户端到网关的通信，并在入站部分使用 validate-jwt 强制执行令牌验证。Azure AD 提供集中式身份、条件访问和强大的令牌验证。validate-jwt 确保只有具有正确受众/范围的已验证调用者才能调用 API。
要求产品订阅，并为每个合作伙伴应用颁发订阅密钥。这增加了一个独立于 OAuth 的治理和计量层，并允许按合作伙伴设置配额、轻松轮换密钥以及基于门户的自助式注册。
在入站部分配置 rate-limit-by-key 和 quota-by-key，并以订阅密钥为键。流量限制可以保护后端免受流量尖峰的影响，并为合作伙伴提供差异化的 SLA。使用订阅密钥作为区分符，使强制执行与商业合同保持一致。
实施 IP 筛选，以阻止已知的恶意范围，并允许星巴克自有的公司范围用于管理。ip-filter 在管道早期减少了攻击面，并节省了下游资源。
通过将客户端证书上传到 APIM 并将其绑定到相关的后端实体，为敏感服务配置后端双向 TLS。mTLS 为需要证书的后端提供了强大的服务到服务身份验证，满足了内部安全策略。
对于受 Azure AD 保护的服务，在后端部分添加 authentication-managed-identity。APIM 的托管标识为后端获取访问令牌，从而消除了密钥并与 Azure RBAC 和条件访问集成。
在后端部分实施带重试和回退的 circuit-breaker。当在时间窗口内重复发生故障时，打开断路器并将请求路由到健康的区域后端；如果两个后端都宕机，则返回一个标准化的、缓存的回退响应。这可以保护降级的服务，并在故障下提供可预测的行为。
使用条件路由将读取操作负载均衡到最近的区域，并根据健康信号进行故障转移。策略表达式通过检查自定义标头或 IP 地理位置来选择本地区域；健康探测会填充用于路由决策的变量。这在区域性事件期间提供了低延迟和业务连续性。
为订单 API 引入一个版本集，采用基于路径的版本控制（/v1, /v2）。为 v2 创建一个新的修订版进行测试，通过调用特定于修订版的 URL 与选定的客户端进行验证，然后将其提升为当前版本。版本集清晰地传达了重大变更，而修订则实现了安全的、非重大的迭代。
在出站部分为读取密集型端点（菜单/目录）启用响应缓存，使用 cache-lookup 和 cache-store，并按区域设置和设备类型进行区分。缓存减轻了后端的重复获取负载，并提高了移动性能；Premium 层支持大规模使用这些功能。