Сетевой шлюз
API Gateway действует как единая точка входа для клиентов, обращающихся к нескольким серверным микросервисам, обрабатывая запросы, направляя их к соответствующи...
[API Gateway](/ru/terms/api-gateway) — это сервер, который действует как точка входа для всех клиентских запросов к серверным службам. Он находится между клиентскими приложениями и микросервисами или монолитным бэкендом, абстрагируя базовую архитектуру и упрощая взаимодействие с клиентами. Основные функции API Gateway включают маршрутизацию запросов, преобразование запросов/ответов, аутентификацию и авторизацию, ограничение скорости запросов, кэширование, ведение журналов и мониторинг. Централизуя эти общие проблемы, шлюз предотвращает их дублирование в нескольких серверных службах, что приводит к более чистому и поддерживаемому коду. Маршрутизация запросов направляет входящие вызовы API к соответствующей серверной службе на основе пути запроса, заголовков или других критериев. Преобразование позволяет шлюзу изменять запросы или ответы, например, изменяя форматы данных (например, XML в JSON) или агрегируя данные из нескольких служб. Безопасность является критически важным аспектом; шлюз может обрабатывать аутентификацию (проверку личности клиента) и авторизацию (определение того, имеет ли клиент разрешение на доступ к запрошенному ресурсу), часто путем интеграции с поставщиками удостоверений или службами проверки токенов. Ограничение скорости запросов защищает серверные службы от перегрузки слишком большим количеством запросов, а кэширование может повысить производительность, обслуживая часто запрашиваемые данные непосредственно из шлюза. Этот архитектурный шаблон особенно распространен в архитектурах микросервисов, где он помогает управлять сложностью многочисленных распределенных служб.
graph LR
Center["Сетевой шлюз"]:::main
Rel_load_balancer["load-balancer"]:::related -.-> Center
click Rel_load_balancer "/terms/load-balancer"
Rel_internet_of_things_iot["internet-of-things-iot"]:::related -.-> Center
click Rel_internet_of_things_iot "/terms/internet-of-things-iot"
Rel_grid_computing["grid-computing"]:::related -.-> Center
click Rel_grid_computing "/terms/grid-computing"
classDef main fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:white,font-weight:bold,rx:5,ry:5;
classDef pre fill:#0f172a,stroke:#3b82f6,color:#94a3b8,rx:5,ry:5;
classDef child fill:#0f172a,stroke:#10b981,color:#94a3b8,rx:5,ry:5;
classDef related fill:#0f172a,stroke:#8b5cf6,stroke-dasharray: 5 5,color:#94a3b8,rx:5,ry:5;
linkStyle default stroke:#4b5563,stroke-width:2px;
🧠 Проверка знаний
🧒 Простыми словами
[[API](/ru/terms/api) Gateway](/ru/terms/api-gateway) похож на услужливого администратора большого офисного здания; он направляет посетителей (запросы вашего приложения) в нужный отдел (серверную службу) и следит за тем, чтобы внутрь попадали только авторизованные лица, при этом посетителю не нужно знать внутреннюю планировку.
🤓 Expert Deep Dive
Паттерн [API Gateway](/ru/terms/api-gateway) решает проблемы управления распределенными системами, особенно микросервисами, предоставляя единый унифицированный интерфейс для клиентов. Ключевые архитектурные соображения включают выбор между централизованным шлюзом (единая точка входа) и децентрализованными (шлюзы для каждой службы или домена). Централизованные шлюзы упрощают взаимодействие с клиентами и применяют согласованные политики, но могут стать узким местом и единой точкой отказа. Децентрализованные шлюзы обеспечивают лучшую масштабируемость и изоляцию отказов, но могут привести к дублированию политик. Распространенные паттерны реализации включают паттерн Backend For Frontend (BFF), где специализированные шлюзы удовлетворяют конкретные потребности различных типов клиентов (например, мобильных, веб). Роль шлюза в преобразовании протоколов (например, REST в gRPC) и агрегации запросов имеет решающее значение для отделения клиентов от эволюции серверных служб. Последствия для производительности возникают из-за дополнительного сетевого перехода и накладных расходов на обработку, что требует эффективной маршрутизации, кэширования и, возможно, асинхронной обработки. Применение безопасности на уровне шлюза, такое как проверка JWT или интроспекция токенов OAuth 2.0, является критически важной лучшей практикой безопасности.