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