Выпущено руководство по проектированию production API‑инфраструктуры на API Gateway

Руководство описывает, как API Gateway выступает управляемым слоем для определения API, аутентификации, контроля трафика, маршрутизации бэкендов и мониторинга, а также какие конфигурационные и операционные решения нужно учитывать при развёртывании

Опубликовано подробное руководство по проектированию production‑инфраструктуры на базе API Gateway: документ объясняет, как шлюз служит управляемым уровнем для экспонирования, защиты и управления распределёнными бэкендами и почему это важно для стабильности сервисов в продакшене. Руководство адресовано архитекторам и операционным командам: оно помогает выбирать конфигурации и операционные практики, которые снижают риск сбоев при масштабировании и интеграции с внешними поставщиками идентичности.

API Gateway в руководстве описан как набор функций для работы с внешними API: определение конечных точек, аутентификация, контроль трафика, маршрутизация к бэкендам и мониторинг. Входящие запросы проходят серию настраиваемых этапов обработки, а конечные точки логически объединяются в «Groups» — коллекции API с общим хостом, настройками TLS и средой (например, RELEASE / PRE / TEST). Параметры пути задаются в виде {parameter} и извлекаются для передачи в бэкенды и использования плагинами. Особое внимание уделено практическим архитектурным задачам современных распределённых приложений: микросервисы, контейнеры, управляемые вычисления (Function Compute), виртуальные машины (ECS), VPC-сетевые конфигурации и сторонние интеграции. Шлюз описан как средство снижения хрупкости интеграций: он позволяет централизовать политику аутентификации, защищать компоненты от аномального трафика и сглаживать несовместимые изменения между сервисами.

Для аутентификации руководство приводит четыре поддерживаемые модели, выбираемые на уровне отдельного API: Alibaba Cloud APP (AppKey/AppSecret), OpenID Connect, JWT и анонимный доступ. В одном Group разные API могут применять разные механизмы аутентификации — выбор ориентирован на модель идентичности потребителя, а не только на технические предпочтения архитектуры. Техническая реализация модели AppKey/AppSecret описана подробно: используется пара AppKey/AppSecret и подпись HMAC‑SHA256. Каноническая строка подписи формируется из HTTP‑метода, заголовков Accept и Content‑Type, хэша содержимого, метки времени, выбранных пользовательских заголовков и пути с query‑параметрами, что усложняет воспроизведение и подмену запросов. По умолчанию действует отсечка по времени в 15 минут для предотвращения повторного использования подписанных запросов.

При работе с JWT шлюз проверяет подпись по настроенному JSON Web Key Set (JWKS), валидирует стандартные поля (iss, aud, exp, nbf) и экспортирует дополнительные claims в контекст запроса, доступный бэкенду и плагинам. JWKS забирается и кешируется с настраиваемым TTL, причём авторы руководства подчёркивают компромисс между быстрой реакцией на ротацию ключей и дополнительной нагрузкой на поставщика идентичности. В разделе по сети и безопасности закреплены требования к TLS (минимум TLS 1.2), рекомендации по использованию SNI при обслуживании нескольких доменов на одном endpoint и варианты загрузки сертификатов для различных сценариев развертывания. Это помогает поддерживать безопасные соединения и корректную маршрутизацию при мультидоменных конфигурациях.