- tocdepth
2
Концепции
Основные понятия
API Gateway оперирует следующими взаимосвязанными сущностями:
- Шлюз API
Интерфейс взаимодействия, который находится перед API группы микросервисов. Облегчает отправку запросов и доставку данных сервисов.
Назначения шлюза:
Выступать в качестве единой точки входа и стандартизированного процесса взаимодействия между различными сервисами организации в рамках одного сценария использования.
Выполнять функцию прослойки между API и базовой инфраструктурой.
Поддерживать и управлять использование API, включая авторизацию, ограничение числа запросов в единицу времени и другие службы.
Шлюз API является контейнером для правил. Все правила, размещенные в шлюзе, реализуют перенаправление запросов, отправленных на адрес шлюза API, к группе микросервисов. Адрес шлюза генерируется автоматически при создании шлюза и доступен в разделе Информация.
- Правило
Набор свойств, согласно которым обрабатываются запросы клиента к шлюзу API, в котором это правило создано, по заданным правилам соответствия HTTP-метода и URI запроса. Определяет сценарий обработки запросов, поступивших на выбранные URI шлюза API, а совокупность правил определяет всю логику пользовательского взаимодействия со шлюзом API.
К правилу можно привязать плагины, которые обогащают логику обработки запросов.
- URI
URI бэкенда и URI для proxy указываются при создании правила.
URI бэкенда определяет конечную точку пользовательского бэкенда, к которой будут отправляться запросы через шлюз. Пример:
Адрес хоста бэкенда:
https://example.com
URI бэкенда:
/service
Запросы будут отправляться на
https://example.com/service
.Если при создании правила вы выбрали подключение, в настройках которого в качестве протокола указан GRPC/GRPCS, то в поле URI бэкенда укажите путь в следующем формате:
/package.service/rpc
, где:package
— название пакета в proto-файле;service
— название сервиса в proto-файле;rpc
— метод в proto-файле.
Примечание
Подробнее о настройке протокола GRPC и синтаксисе proto-файла — на официальном сайте разработчика.
URI для proxy используется в адресе шлюза при проксировании запросов. Пример:
Адрес шлюза:
https://9cd8da9051.apigw.cloud.ru
URI для proxy:
/service1
Для отправки запросов к бэкенду через шлюз будет использоваться адрес
https://9cd8da9051.apigw.cloud.ru/service1
.В значении URI для proxy и URI бэкенда можно использовать wildcard-символ (*) для обозначения произвольной части пути. Пример для URI для proxy:
при добавлении URI
/foo*
(для обращения по HTTP) правилом будут обработаны запросы на/foo/
,/foo/a
,/foo/b
и так далее;при добавлении URI
/package.service/*
(для обращения по GRPC) правилом будут обработаны запросы на/package.service/SayHello
,/package.service/PostArticle
и так далее.
- Плагин
Плагин — подключаемый модуль, реализующий расширенную логику, которая применяется между отправкой HTTP-запроса и получением ответа. Конфигурация плагина привязывается к правилу.
Плагины могут быть привязаны только к конкретному правилу и модифицируют выполнение только тех запросов, которые соответствуют настройкам правила. К каждому правилу могут быть привязаны все доступные плагины, но только по одному каждого типа.
См.также
Пример взаимосвязи объектов
Пример взаимосвязи сущностей, используемых в сервисе API Gateway, с псевдоданными представлена на схеме ниже.
для Dev & Test