Открыть сервис
Главная → Блог → API-шлюз

API-шлюз

API-шлюз (англ. API Gateway) — это промежуточный сервер (или служба), который выступает единой точкой входа для клиентских запросов к внутренним микросервисам, API или бэкенд-системам. API-шлюз выполняет функции маршрутизации, аутентификации, авторизации, ограничения скорости (rate limiting), кэширования, трансформации протоколов и агрегации ответов, скрывая внутреннюю архитектуру от внешних клиентов.

История

Концепция API-шлюза возникла в конце 2000-х — начале 2010-х годов в связи с распространением архитектуры микросервисов. В монолитных приложениях единая точка входа не требовалась, так как все функции были частью одного процесса. С переходом к микросервисам, когда приложение разбивается на множество независимых сервисов, у каждого из которых может быть свой API, возникла необходимость в унифицированном интерфейсе для клиентов (веб-браузеров, мобильных приложений, внешних систем).

Первые коммерческие решения, такие как Amazon API Gateway (запущен в 2015 году) и Kong (изначально open-source, 2015), стали стандартом де-факто. В 2016 году Netflix опубликовал собственную реализацию API-шлюза — Zuul, которая позже вошла в экосистему Spring Cloud. Параллельно развивались шлюзы на основе NGINX и Envoy (2016), а также облачные сервисы от Google (Apigee, Cloud Endpoints) и Microsoft (Azure API Management).

Классификация

API-шлюзы можно разделить по способу развёртывания и функциональности:

По способу развёртывания

  • Облачные (managed) — предоставляются как сервис (SaaS): Amazon API Gateway, Azure API Management, Google Cloud Apigee, Yandex API Gateway. Не требуют управления инфраструктурой.
  • Самостоятельные (self-hosted) — развёртываются на собственном оборудовании или в контейнерах: Kong, Tyk, Apache APISIX, KrakenD, NGINX Plus.
  • Встраиваемые (embedded) — встраиваются в код приложения или в sidecar-контейнер (например, Envoy в составе сервисной сетки Istio).

По функциональному назначению

Устройство и характеристики

Типичный API-шлюз состоит из следующих компонентов:

  • Маршрутизатор — на основе URL, заголовков, метода HTTP или параметров запроса направляет запрос к соответствующему сервису.
  • Аутентификатор — проверяет идентификацию клиента (токены JWT, OAuth 2.0, API-ключи, сертификаты).
  • Авторизатор — проверяет права доступа (роли, политики, ACL).
  • Ограничитель скорости — предотвращает превышение лимитов запросов (rate limiting, throttling, quota).
  • Трансформатор — преобразует запросы/ответы: изменение формата (JSON → XML), добавление/удаление заголовков, перекодировка.
  • Кэш — временное хранение ответов для снижения нагрузки на бэкенд.
  • Балансировщик нагрузки — распределение запросов между несколькими экземплярами сервиса.
  • Логирование и мониторинг — сбор метрик, логов, трассировка запросов.

Характеристики

  • Пропускная способность — измеряется в запросах в секунду (RPS). Для облачных шлюзов обычно высокая (до десятков тысяч RPS), для self-hosted зависит от аппаратного обеспечения.
  • Задержка (latency) — дополнительное время обработки, вносимое шлюзом. Обычно составляет 1–10 мс для self-hosted и 10–50 мс для облачных.
  • Протоколы — HTTP/1.1, HTTP/2, gRPC, WebSocket, GraphQL, SOAP.
  • Масштабируемость — горизонтальное масштабирование (добавление экземпляров) или вертикальное (увеличение ресурсов).
  • Безопасность — поддержка TLS, защита от DDoS, WAF (Web Application Firewall), проверка подлинности.

Применение

API-шлюзы используются в следующих сценариях:

Микросервисная архитектура

В микросервисной архитектуре API-шлюз является обязательным компонентом. Он скрывает от клиента сложность внутренней структуры, обеспечивает единую точку входа для всех сервисов, реализует сквозную аутентификацию и авторизацию, а также агрегирует ответы от нескольких сервисов в один. Например, при загрузке страницы интернет-магазина шлюз может одновременно запросить данные о товаре, цене, отзывах и наличии на складе, объединив их в один ответ.

Публикация внешних API

Компании, предоставляющие API сторонним разработчикам (например, платёжные системы, сервисы карт, погоды), используют API-шлюзы для управления доступом: выдача API-ключей, ограничение числа запросов, мониторинг использования, биллинг. Примеры: Amazon API Gateway, Google Cloud Endpoints, Yandex API Gateway.

Безопасность и контроль доступа

API-шлюз может выступать как единый барьер безопасности: проверять токены, блокировать подозрительные запросы, фильтровать SQL-инъекции и XSS-атаки, ограничивать частоту запросов от одного IP.

Трансформация протоколов

Шлюз может преобразовывать запросы из одного протокола в другой, например, из REST (HTTP/JSON) в gRPC (HTTP/2/Protobuf) или наоборот, что позволяет интегрировать старые системы с новыми.

Кэширование

Для часто запрашиваемых данных (например, список стран, курсы валют) шлюз может кэшировать ответы, снижая нагрузку на бэкенд и ускоряя ответ клиенту.

Примеры популярных API-шлюзов

  • Amazon API Gateway — облачный сервис от AWS, поддерживает REST, HTTP, WebSocket, интеграцию с Lambda, DynamoDB, S3. Позволяет создавать, публиковать и мониторить API.
  • Kong — open-source (лицензия Apache 2.0) и коммерческая версия. Работает на основе NGINX и OpenResty. Поддерживает плагины (аутентификация, кэширование, логирование).
  • NGINX Plus — коммерческая версия веб-сервера NGINX с функциями API-шлюза (маршрутизация, балансировка, аутентификация, rate limiting).
  • Envoy — высокопроизводительный прокси-сервер, часто используется в сервисных сетках (Istio, Consul). Поддерживает gRPC, HTTP/2, WebSocket.
  • Tyk — open-source (лицензия MPL 2.0) и коммерческая версия. Имеет встроенный портал разработчика, поддержку GraphQL, аналитику.
  • Apache APISIX — open-source (лицензия Apache 2.0), поддерживает динамическую маршрутизацию, плагины, gRPC, WebSocket.
  • Yandex API Gateway — облачный сервис от Яндекса, интегрирован с Yandex Cloud Functions, Yandex Serverless Containers, Yandex Object Storage. Поддерживает REST, HTTP, WebSocket.
  • Azure API Management — облачный сервис от Microsoft, включает портал разработчика, аналитику, политики безопасности, поддержку OpenAPI (Swagger).

Критика

Несмотря на широкое распространение, API-шлюзы имеют ряд недостатков:

  • Единая точка отказа — если шлюз выходит из строя, все внешние запросы блокируются. Для снижения риска требуется резервирование и балансировка.
  • Дополнительная задержка — каждый запрос проходит через шлюз, что добавляет задержку, особенно при большом количестве преобразований.
  • Сложность конфигурации — настройка правил маршрутизации, аутентификации, ограничений и трансформаций может быть трудоёмкой, особенно в крупных системах.
  • Риск излишней централизации — если шлюз берёт на себя слишком много функций (агрегация, бизнес-логика), он может стать узким местом и усложнить развитие системы.
  • Стоимость — облачные шлюзы взимают плату за количество запросов, объём переданных данных и дополнительные функции (аналитика, WAF). Self-hosted требуют затрат на инфраструктуру и администрирование.

Источники

  • Amazon Web Services. «What is an API Gateway?» — AWS Documentation.
  • Kong Inc. «API Gateway: What is it and why do you need one?» — Kong Blog.
  • Microsoft. «What is Azure API Management?» — Microsoft Docs.
  • Google Cloud. «API Gateway overview» — Google Cloud Documentation.
  • Yandex Cloud. «Yandex API Gateway» — Yandex Cloud Documentation.
  • Fielding, R. T. (2000). «Architectural Styles and the Design of Network-based Software Architectures» — диссертация, описывающая REST.
  • Newman, S. (2015). «Building Microservices: Designing Fine-Grained Systems» — O'Reilly Media.
  • Richardson, C. (2018). «Microservices Patterns» — Manning Publications.

BFOmetr — база данных и аналитика по компаниям России.

На главную BFOmetr →

Похожие материалы