Microsoft AZ-204: Azure API Management — Руководство по подготовке

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) предоставляет унифицированный интерфейс для разнообразных серверных служб, сочетая в себе высокопроизводительный шлюз с настраиваемым механизмом политик, средства для подключения разработчиков и полноценную плоскость управления. Он обеспечивает единообразное управление безопасностью, регулированием, преобразованием, наблюдаемостью и жизненным циклом для REST, SOAP и GraphQL бэкендов. APIM — это одновременно и шлюз времени выполнения для трафика, и система, управляемая конфигурацией через портал Azure, ARM/Bicep/CLI или CI/CD. Понимание конвейера обработки запросов, возможностей политик, управления версиями/ревизиями, модели подписки и характеристик уровней является основой для создания надёжных и безопасных API в любом масштабе.

Архитектура, уровни и основные компоненты

Шлюз — это плоскость данных (data plane). Он завершает клиентские подключения, применяет политики в детерминированном порядке, направляет запросы на серверные службы и возвращает ответы. Он поддерживает встроенное кэширование, проверку JWT, взаимную аутентификацию TLS и преобразование контента на скорости канала. Шлюзы могут быть размещены Microsoft в каждом регионе или быть саморазмещаемыми (контейнеризированными) для запуска ближе к локальным или пограничным рабочим нагрузкам, оставаясь при этом под централизованным управлением. Шлюз предоставляет данные трассировки и метрики и интегрируется с Application Insights для распределённой телеметрии.

Портал разработчика — это интерфейс для потребителей API, предназначенный для обнаружения, документирования и управления подписками. Он отображает документацию OpenAPI/GraphQL, предоставляет интерактивные консоли «Попробовать», обрабатывает потоки OAuth 2.0 в браузере и поддерживает кастомный брендинг и поставщиков удостоверений. Здесь разработчики самостоятельно управляют подписками на продукты и ротируют ключи.

Плоскость управления (management plane) — это интерфейс для конфигурации и администрирования. В ней хранятся 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.

Политики inbound выполняются до того, как запрос будет перенаправлен на серверную службу. Типичные задачи включают требование или проверку ключей подписки, проверку JWT (принудительное указание издателя, аудитории, подписи), проверку IP-адресов клиентов, применение ограничений скорости и квот, нормализацию заголовков, перезапись URI и преобразование полезной нагрузки. Вы можете условно маршрутизировать запросы на разные серверные службы и устанавливать переменные для последующих этапов.

Секция backend настраивает и изменяет вызов вышестоящего сервиса. Используйте её для выбора серверной сущности, прикрепления учётных данных клиента (базовая аутентификация, клиентские сертификаты или токены, полученные через управляемое удостоверение для серверных служб, защищённых Azure AD), установки тайм-аутов, включения повторных попыток и применения механизма размыкания цепи (circuit breaking). Взаимная аутентификация TLS (mTLS) с серверной службой настраивается здесь путём привязки клиентского сертификата, который будет представлять шлюз.

Политики outbound выполняются после получения ответа от серверной службы. Они обычно выполняют преобразования ответа (например, из JSON в XML или наоборот), перезапись заголовков, формирование данных, маскирование внутренних деталей и кэширование ответов. Здесь также можно применять преобразования для согласования содержимого (content negotiation) или нормализовать коды состояния.

Политики on-error выполняются, если в любой из предыдущих секций, включая вызов серверной службы, возникает исключение. Используйте эту секцию, чтобы сопоставлять ошибки серверной службы со стандартизированными форматами ошибок API, устанавливать соответствующие коды состояния, скрывать конфиденциальные сообщения, добавлять идентификаторы корреляции или предоставлять резервные ответы.

Распространённые шаблоны политик:

Ограничение скорости контролирует пиковую пропускную способность и защищает серверные службы. Политика rate-limit-by-key применяет ограничение для каждой идентификации, используя ключ, такой как ключ подписки, утверждение (claim) JWT или IP-адрес. Для более длительных периодов времени используйте её в сочетании с quota-by-key, чтобы ограничить суточное или месячное использование.
Фильтрация по IP-адресам блокирует или разрешает трафик по IP-адресу клиента или диапазонам CIDR с помощью ip-filter, часто размещаемой в начале секции inbound для минимизации затрат и рисков.
Проверка JWT с помощью validate-jwt обеспечивает соблюдение параметров OpenID Connect. Настройте URL конфигурации OpenID или издателя, определите допустимые аудитории/области (scopes), выберите обязательные утверждения (claims) и настройте допустимое расхождение часов и проверки времени жизни токена. Запретите анонимный доступ, требуя действительный токен для всех операций, где анонимные вызовы не разрешены.
Преобразование включает 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.

Бэкенды, отказоустойчивость, управление версиями и ревизиями

Бэкенды в APIM — это первоклассные, многократно используемые сущности, которые инкапсулируют базовый URL целевого сервиса, протокол, учетные данные, настройки TLS, шаблоны заголовков и конфигурацию прокси. Связывание API и операций с бэкендами отделяет маршрутизацию от политик и централизует детали подключения. Используйте set-backend-service с указанием ID бэкенда в политиках для маршрутизации запросов без жесткого кодирования URL-адресов, что упрощает продвижение между средами разработки, тестирования и продакшена.

Отказоустойчивость обеспечивается с помощью повторных попыток и механизма автоматического выключателя (circuit breaker). Повторные попытки с экспоненциальной задержкой (exponential backoff) могут смягчить временные сбои; их следует применять только к идемпотентным операциям и ограничивать разумными таймаутами для предотвращения лавинообразного роста нагрузки. Политика автоматического выключателя размыкает цепь, когда частота сбоев, количество последовательных сбоев или задержка превышают настроенные пороговые значения в пределах окна выборки, немедленно отклоняя запросы на определенный период разрыва. В разомкнутом состоянии политика может немедленно вернуть резервный ответ или направить запрос на резервный бэкенд. В полуразомкнутом состоянии ограниченное количество пробных запросов проверяет работоспособность бэкенда перед замыканием цепи. Это защищает бэкенды, улучшает клиентский опыт и стабилизирует системы в условиях частичного сбоя.

Балансировка нагрузки и маршрутизация могут быть реализованы на уровне политик. Условная маршрутизация с помощью choose может направлять трафик в зависимости от сегмента пользователей, географии, содержимого запроса или сигналов о работоспособности. Взвешенная маршрутизация может быть достигнута с помощью выражений в политиках, которые псевдослучайно выбирают бэкенд в соответствии с заданными весами, что позволяет выполнять канареечные релизы и постепенное развертывание. Бэкенды в режиме active-active в разных регионах могут быть реализованы с помощью развертывания APIM уровня Premium в нескольких регионах в сочетании с условной маршрутизацией к ближайшему работоспособному региону; в качестве альтернативы можно интегрировать APIM с Azure Front Door для глобальной балансировки нагрузки на уровне 7, в то время как APIM будет обрабатывать аутентификацию и преобразование данных.

Управление версиями и ревизиями определяет жизненный цикл API. Наборы версий (version sets) определяют, как несколько версий API предоставляются клиентам, используя схему версионирования по пути, строке запроса или заголовку. Используйте версии для несовместимых изменений (breaking changes); каждая версия является отдельной сущностью API, связанной с одним и тем же набором версий. Совместимые, итеративные изменения реализуются как ревизии. Ревизия — это изменяемый снимок API, который можно вызывать явно (через суффикс ревизии) для тестирования, в то время как более ранняя ревизия остается текущей рабочей (production) ревизией. После проверки новая ревизия повышается до текущей без изменения идентификатора версии. Такое разделение обеспечивает безопасную, постепенную доставку: ревизии для совместимых обновлений; версии для несовместимых изменений, которые отображаются через понятное обнаружение и документацию на портале для разработчиков.

Наконец, наблюдайте и управляйте. Включите трассировку, устанавливайте идентификаторы корреляции и экспортируйте диагностику в Application Insights для сквозной видимости. Управляйте конфигурацией с помощью ARM/Bicep или APIM DevOps Resource Kit для достижения повторяемых развертываний и применяйте RBAC на уровне управления для разделения обязанностей между авторами, издателями и операторами API.

Практический сценарий проблемы

Starbucks необходимо предоставить единый публичный API для мобильных заказов, который объединяет микросервисы в двух регионах Azure. API должен блокировать анонимный доступ, ограничивать злоупотребляющих клиентов, защищать региональные бэкенды от каскадных сбоев и позволять постепенное развертывание схемы заказов v2 без нарушения работы клиентов v1.

Разверните экземпляр APIM уровня Premium в двух регионах и включите многорегиональное развертывание. Уровень Premium выбран за наличие шлюзов в нескольких регионах, расширенные сетевые возможности и корпоративный масштаб. Региональные шлюзы уменьшают задержку для мобильных клиентов и обеспечивают отказоустойчивость в режиме active-active.
Импортируйте бэкенд-сервисы как сущности бэкендов в APIM, включая экземпляры App Service в обоих регионах. Сущности бэкендов централизуют базовые URL-адреса, настройки TLS и учетные данные, обеспечивая чистые политики маршрутизации и переносимость между средами.
Защитите соединение от клиента к шлюзу с помощью Azure AD OAuth 2.0 и проверяйте токены с помощью validate-jwt во входящей секции (inbound). Azure AD обеспечивает централизованное управление удостоверениями, условный доступ и надежную проверку токенов. validate-jwt гарантирует, что только аутентифицированные вызывающие стороны с правильными аудиториями/областями действия (audiences/scopes) могут вызывать API.
Требуйте подписки на продукты и выдавайте ключи подписки для каждого партнерского приложения. Это добавляет уровень управления и учета, независимый от OAuth, и позволяет устанавливать квоты для каждого партнера, легко ротировать ключи и самостоятельно регистрироваться через портал.
Настройте rate-limit-by-key и quota-by-key во входящей секции, используя ключ подписки. Ограничение частоты запросов (throttling) защищает бэкенды от всплесков нагрузки и позволяет предоставлять дифференцированные SLA для партнеров. Использование ключей подписки в качестве дискриминатора приводит принудительные меры в соответствие с бизнес-контрактами.
Реализуйте IP-фильтрацию для блокировки известных вредоносных диапазонов и разрешения корпоративных диапазонов Starbucks для администрирования. ip-filter уменьшает поверхность атаки на раннем этапе конвейера и экономит ресурсы на последующих этапах.
Настройте взаимную аутентификацию по TLS (mTLS) для чувствительных сервисов, загрузив клиентские сертификаты в APIM и привязав их к соответствующим сущностям бэкендов. mTLS обеспечивает надежную аутентификацию между сервисами, когда бэкенды требуют сертификаты, удовлетворяя внутренним политикам безопасности.
Добавьте authentication-managed-identity в секцию бэкенда для сервисов, защищенных Azure AD. Управляемое удостоверение APIM получает токены доступа для бэкенда, устраняя необходимость в секретах и интегрируясь с Azure RBAC и условным доступом.
Реализуйте механизм автоматического выключателя (circuit-breaker) с повторными попытками и резервным вариантом в секции бэкенда. При повторных сбоях в течение определенного временного окна размыкайте цепь и направляйте запросы на работоспособный региональный бэкенд; если оба недоступны, возвращайте стандартизированный, кэшированный резервный ответ. Это защищает деградировавшие сервисы и обеспечивает предсказуемое поведение при сбое.
Используйте условную маршрутизацию для балансировки нагрузки на чтение к ближайшему региону и для переключения при отказе на основе сигналов о работоспособности. Выражения в политиках выбирают локальный регион, проверяя пользовательский заголовок или геолокацию по IP; пробы работоспособности заполняют переменные для принятия решений о маршрутизации. Это обеспечивает низкую задержку и непрерывность работы во время региональных инцидентов.
Создайте набор версий для Orders API с версионированием на основе пути (/v1, /v2). Создайте новую ревизию v2 для тестирования, проверьте ее с избранными клиентами, вызывая URL-адрес конкретной ревизии, а затем повысьте ее до текущей. Наборы версий четко сообщают о несовместимых изменениях, в то время как ревизии обеспечивают безопасные, совместимые итерации.
Включите кэширование ответов для конечных точек с высокой нагрузкой на чтение (меню/каталог) в исходящей секции (outbound) с помощью cache-lookup и cache-store, с вариацией по языку и типу устройства. Кэширование снимает нагрузку с бэкендов от повторяющихся запросов и улучшает производительность мобильных приложений; уровень Premium поддерживает эти функции в большом масштабе.

Такая архитектура обеспечивает аутентифицированные, ограниченные по частоте, отказоустойчивые и развиваемые API. APIM Premium предоставляет глобальный, безопасный шлюз; политики обеспечивают управление удостоверениями, ограничение частоты, преобразование данных и отказоустойчивость; сущности бэкендов и управляемые удостоверения защищают и разделяют соединения; наборы версий и ревизии обеспечивают дисциплинированный жизненный цикл для непрерывной доставки без сбоев для клиентов.

← Аутентификация · Все домены · Решения Azure для событий и сообщений →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →