УПРАВЛЕНИЕ API-ШЛЮЗОМ НА ОСНОВЕ АРХИТЕКТУРЫ МИКРОСЕРВИСА Текст научной статьи по специальности «Компьютерные и информационные науки»

Управление API-шлюзом на основе архитектуры микросервиса

Нуркаев Руставиль

бакалавр, инженер-программист Swedbank,

Пивоваров Виталий Владиславович

бакалавр, инженер-программист, Университет Иннополис,

Микросервисы - это действия, которые выполняются в ваших собственных программах и взаимодействуют с TTP API через облегченные устройства. В рамках архитектуры микросервисов API-шлюз является важным компонентом общей архитектуры. В нем обобщаются общие функции, которые необходимы в микросервисах. Являясь единственным входом для микросервиса, API Gateway инкапсулирует конкретную внутреннюю реализацию и интерфейс системы. На основе анализа и сравнения традиционной структуры и структуры микроуслуг. В этой статье в основном анализируется реализация функций: балансировка нагрузки, автоматическое отключение сервиса и серое освобождение, а также приводится схема реализации ключевой технологии API gateway в рамках архитектуры микросервисов. В статье обсуждается тематическое исследование выбора технологии и архитектуры приложения в рамках микросервиса. И это также обеспечивает новое решение проблем, связанных с управлением API-шлюзом в рамках микросервиса, предоставляя подробный дизайн для аутентификации API-шлюза, функции обратного прокси-сервера и функции управления потоком. С помощью aPi Gateway может быть решена проблема того, как вызывающий абонент может вызвать независимую службу, таким образом, эффективность разработки может быть значительно повышена.

Ключевые слова: микросервис, API Gateway, архитектура, шлюз, масштабируемость приложений

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

API Gateway - это промежуточный слой между клиентами и микросервисами, который управляет входящими и исходящими запросами. Он представляет собой единую точку входа для всех запросов к микросервисам и обеспечивает централизованную управляемость всеми API.

API Gateway может выполнять следующие функции:

1. Аутентификация и авторизация aPi Gateway может обеспечивать безопасность системы, требуя аутентификацию и авторизацию от клиентов, а также контролировать доступ к конкретным сервисам и операциям.

2. Маршрутизация запросов API Gateway может определять, какой микросервис должен обрабатывать конкретный запрос, основываясь на различных критериях, таких как URL, HTTP методы, заголовки запроса и т.д.

3. Преобразование запросов и ответов API Gateway может преобразовывать запросы и ответы между клиентами и микросервисами. Например, он может конвертировать запросы из одного формата в другой или преобразовывать данные для совместимости с конкретным клиентским приложением.

4. Кеширование API Gateway может кэшировать ответы микросервисов, чтобы снизить нагрузку на сервера и ускорить время ответа клиентам.

5. Отслеживание и мониторинг API Gateway может записывать логи запросов и ответов, а также мониторить производительность и доступность микросервисов. Это помогает операторам системы быстро обнаруживать и устранять проблемы.

Преимущества API Gateway:

1. Упрощение клиентского кода: клиентам не нужно знать, какие микросервисы находятся за API Gateway, что значительно упрощает код клиента.

2. Улучшенная безопасность: API Gateway может обеспечить контроль доступа и авторизацию на уровне маршрута, что обеспечивает более высокую безопасность системы в целом.

3. Лучшая масштабируемость: API Gateway может обеспечить балансировку нагрузки и кеширование запросов, что позволяет более эффективно использовать ресурсы системы и обеспечивает ее масштабируемость.

4. Улучшенная надежность: API Gateway может работать как точка отказа и перенаправлять запросы на доступные микросервисы в случае отказа одного из них, что повышает надежность системы.

Недостатки API Gateway:

X X

о го А с.

X

го m

о

2 О

м

CJ

СО CS

0

CS

!Л

01

О Ш

m

X

3

<

m О X X

1. Увеличение задержки: API Gateway может стать узким местом в системе и добавить задержку при обработке запросов.

2. Сложность конфигурации: настройка API Gateway может быть сложной задачей, особенно в больших системах с большим количеством микросервисов.

3. Единственная точка отказа: API Gateway может стать единственной точкой отказа системы, если не обеспечить достаточный уровень отказоустойчивости.

4. Сложность отладки: отладка системы с API Gateway может быть сложной задачей, особенно при обработке сложных маршрутов и запросов.

Таким образом, API Gateway обеспечивает множество преимуществ в микросервисной архитектуре, но может иметь и некоторые недостатки. При проектировании и использовании API Gateway необходимо учитывать эти факторы и балансировать их, чтобы обеспечить наилучшую работу системы.

Многие крупные компании используют API Gateway для управления своими API в микросервисной архитектуре. Некоторые из этих компаний включают в себя:

1. Netflix: использует Zuul в качестве своего API Gateway для маршрутизации запросов и обработки фильтров.

2. Amazon: предоставляет Amazon API Gateway для управления и обеспечения безопасности многих видов API.

3. Microsoft: использует Azure API Management для управления и защиты API.

4. Google: предоставляет Cloud Endpoints для создания, развертывания и управления API на Google Cloud Platform.

5. PayPal: использует Apigee в качестве своего API Gateway для управления API и защиты их от злоумышленников.

6. Uber: использует Envoy в качестве своего API Gateway для балансировки нагрузки и маршрутизации запросов.

7. Airbnb: использует Kong в качестве своего API Gateway для маршрутизации и защиты API.

В Java существует множество фреймворков и библиотек для создания API Gateway в микросервисной архитектуре, таких как Spring Cloud Gateway, Netflix Zuul, Kong, Apigee и другие. Рассмотрим на примере Spring Cloud Gateway, как можно создать API Gateway на Java.

Spring Cloud Gateway - это фреймворк для создания API Gateway в микросервисной архитектуре. Он основан на Spring Boot и предоставляет механизмы маршрутизации запросов, балансировки нагрузки, фильтрации запросов и многое другое. Ниже представлен пример создания маршрутизатора на основе Spring Cloud Gateway:

@Configuration public class GatewayConfig {

@Bean public

RouteLocator customRouteLocator(RouteLocatorBuilder builder) {

return builder.routes()

.route("users_route", r -> r.path("/users")

.urii"http://users-service:8080"))

.route("orders_route", r -> r.path("/orders")

.urii"http://orders-service:8080"))

.build(); }

В этом примере создается бин customRouteLocator, который представляет маршрутизатор для API Gateway. Он определяет два маршрута: /users и /orders, которые направляются на соответствующие микросервисы users-service и ordersservice.

Spring Cloud Gateway также предоставляет возможность создавать фильтры запросов, которые могут быть использованы для реализации функций авторизации, аутентификации

и мониторинга. Например, фильтр для проверки авторизации может быть реализован следующим образом:

public class AuthorizationFilter implements GatewayFilter {

@Override public

Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) { String

authorizationHeader =

exchange.getRequest().getHeaders().getFirst(HttpHeaders.AUTHORI ZATION); ' if

(authorizationHeader == null || !authorizationHeader.startsWith("Bearer ")) {

exchange.getResponse().setStatusCode(HttpStatus.UNAUT HORIZED); return

exchange.getResponse().setCompleteO; }

return chain.filter(exchange); } }

Этот фильтр проверяет, содержит ли запрос заголовок Authorization со значением Bearer. Если заголовок отсутствует или значение не соответствует требуемому, то в ответ возвращается статус 401 Unauthorized. В противном случае, запрос продолжает обрабатываться.

1 Технологическое решение режима микросервисного шлюза

В основном существует пять типов API Gateway WebApp, мобильное приложение, партнерский открытый API, партнерский внешний API, интеллектуальное устройство IoT. Для первых трех категорий или верхних четырех шлюзов API, кроме гарантии обмена данными, также необходимо реализовать аутентификацию личности для клиентов доступа, защиту от воспроизведения сообщений и защиты от несанкционированного доступа к данным, вызовы службы аутентификации службы, десенсибилизацию данных ответа, управление трафиком и параллелизмом, а также учет вызовов или выставление счетов на основе API.

Шлюз API служит входом для запроса фонового микросервиса, и он должен обладать такими функциями, как высокая производительность и расширяемость. Поэтому предпочтительно, чтобы язык lua на основе Ngnix использовался в качестве расширенной технологии шлюза API[2].

Детальный дизайн

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

-Аутентификация шлюза API.B настоящее время в микросервисах API защиты необходимо вызывать только тем клиентам, которые согласились авторизоваться. В настоящее время большинство используемых методов относятся к трем типам: AppKeys, OAuth2 и OAuth2+JWT. Эти методы аутентификации имеют свои особенности и преимущества.

- Ключи приложения. В настоящее время существует множество шлюзов API общедоступного облака и открытых платформ данных, которые используют аутентификацию AppKeys Auth, например шлюзы API Alibaba и данные агрегации. Этот режим аутентификации выдается шлюзом API с ключом или

appkey+appsecret+ каким-то сложным алгоритмом шифрования для генерации AppKey. Вызывающий объект напрямую вызывает API после получения ключа. netПри получении запроса API шлюз API сначала проверяет действительность ключа, в том числе, является ли ключ недействительным, подписан ли текущий вызывающий API и т. д. Если проверка прошла успешно, шлюз API запрашивает вышестоящую службу и возвращает результат. Здесь вышестоящая служба больше не проверяет запрос и возвращает результат напрямую. Режим аутентификации по ключам приложения больше подходит для сценариев Open Service, в которых не требуется информация о пользователе, информация о правах.

ш арр '-ч

шея, API

mm Gateway

V GET

M/lp/ipaddr?ip=192.16B,

Ll&appKey-<key>

G:i

/vl/ipjï |»«(üp-lffil Ш1

Рисунок 1- Процесс аутентификации ключей приложения [1]

or not

4agree

drelura value

5.get

2.1s I here permission

I .Need RoiVs personal informal™

Рисунок 2- Сертификация соглашения OAUTH/ OAuth2 + JWT[3]

- OAuth2 (открытая авторизация). Протокол OAUTH обеспечивает безопасный, открытый и простой стандарт для авторизации пользовательских ресурсов, но авторизация OAUTH не позволяет третьим лицам касаться информации об учетной записи пользователя (например, имя пользователя и пароль). В OAuth2 есть несколько ролей: Владелец ресурса, Клиент, Сервер авторизации и Сервер ресурсов. На рисунке выше показан простой процесс OAUh2, иллюстрирующий взаимосвязь между каждой ролью. В конце концов, приложение получает личную информацию.

- OAuth2+JWT. Процесс OAuth2 + JWT точно такой же, как и OAuth2. В конечном итоге OAuth2 выдаст токен доступа вызывающей стороне. OAuth2+JWT фактически заменяет токен доступа на JWT. Преимущество этого заключается в простом сокращении количества запросов к БД во время проверки то-кена. После добавления шлюза API каждой из наших служб может потребоваться информация о пользователе, чтобы определить, доступен ли текущий интерфейс или функция. текущему пользователю. Мы можем реализовать это, установив единую аутентификацию на шлюзе API. Шлюз API выполняет унифицированный перехват и аутентификацию. В сочетании с методами аутентификации, описанными выше, протокол

OAuth2 может нести характеристики пользовательской информации, поэтому в этом случае используется больше аутентификации OAuth2[4].

- Функция обратного прокси шлюза API. Запрос на обработку шлюза API включает в себя ряд основных процессов, таких как получение запроса API, выполнение проверки параметров, проверка достоверности AccessToken, получение информации о приложении и получение информации API в соответствии с URL-адресом для выполнения проверки управления потоком. инкапсуляция пакетов запросов, перезапись URL-ад-ресов и запрос обратного прокси-сервера, кеш запросов конфигурации, журнал вызовов хранилища и т. д. Конкретный поток процессов описывается следующим образом[5]:

- Проверка AccessToken. Генерация AccessToken основана на протоколе авторизации 0auth2.0. Во-первых, проверяется, соответствует ли формат AccessToken требованиям. AccessToken, соответствующий требованиям формата, может быть разделен на идентификатор приложения, время создания и подпись аутентификации. Если время генерации подтверждения превышает текущее время более чем на полчаса, срок действия AccessToken истекает. Затем он получает информацию о приложении из MongoDB через идентификатор приложения. И он сравнивает подпись аутентификации, используя один и тот же метод шифрования для шифрования AccessKey и безопасности информации о приложении. Если они разные, то AccessToken является недопустимым и не может быть вызван повторно.

-Информационная загрузка. Благодаря проверке AccessToken информация о приложении была загружена, включая информацию о пользователе, связанную с приложением. В соответствии с запрошенным запросом URL-адресом API, соответствующий URL-адресу, загружается из локального кеша Nginx. Если в локальном кеше нет информации об URL, информация API запрашивается из MongoDB. Если это все еще не так, то URL-адрес является незаконным запросом и напрямую отклонен. Если запрашивается информация API, она включает в себя права, необходимые для URL-адреса, контроля частоты, ограничения IP-адресов, перезаписи URL-адреса и адреса экземпляра.

Эта информация кэшируется в локальном кэше Nginx. Кэш Nginx напрямую использует память сервера и читает очень быстро, что может значительно сократить время, затрачиваемое на удаленное чтение данных в ситуациях с высокой степенью параллелизма. Однако проблема в том, что локальный кеш каждой машины в кластере нельзя очистить динамически. Таким образом, конфигурация API должна ждать действительное время 20 минут.

-Управление потоком. После получения информации о приложении и API, в соответствии с требованиями API, оценивается, включает ли приложение право, необходимое для вызова API. Если права нет, возвращается информация о недостаточном праве. Если проверка привилегий проходит успешно, в соответствии с конфигурацией API определяется, ограничен ли вызов по IP-адресу.

Если возвращается список ограничений IP, возвращается сообщение об ошибке недопустимого IP-адреса. После завершения ограничения IP определяется, что API должен выполнять управление трафиком на уровне приложения, на уровне пользователя и на уровне кластера. Управление потоком использует операцию Redis incr, чтобы определить, URL-адреса за одну секунду с превышением порога контроля частоты. Если пороговое значение превышено, возвращается сообщение об ошибке со слишком частыми запросами.

Управление трафиком на уровне приложения использует URL-адреса и идентификаторы приложений в качестве храни-

X X

о го А с.

X

го m

о

ю

2 О M

со

fO CS

о

CS

in

О Ш

m

X

3

<

m О X X

мых ключей Redis, элементы управления на уровне пользователя используют URL-адреса и идентификаторы пользователей в качестве хранимых ключей Redis, а потоки на уровне кластера используют URL-адреса и имена экземпляров кластера в качестве хранимых ключей Redis.

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

-Перезапись URL. Во-первых, перед выполнением обратного прокси экземпляр получается путем опроса на основе информации об экземпляре API. Кроме того, в соответствии с правилами перезаписи URL-адреса исходный URL-адрес преобразуется в URL-адрес фактической внутренней службы, а адрес вызова обратного прокси-сервера генерируется в сочетании с опросом адреса выбранного экземпляра.

- Обратный прокси. Обратный прокси-сервер использует библиотеку Socket TCP Lua для установления TCP-соедине-ния с удаленной службой, инкапсуляции HTTP-пакета в соответствии с HTTP-протоколом и отправки HTTP-пакета через это TCP-соединение. В этом процессе можно контролировать время соединения и время ожидания запроса. В этом TCP-подключении возвращаемый результат снова инкапсулируется в формат JSON и возвращается вызывающему объекту.

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

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

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

- Клиент службы инициирует вызов. После того, как данные сохранены на стороне сервиса, пользователь сначала обрабатывает сервис в соответствии с сервисом, выполняя доступ к данным в своей собственной сервисной системе или проверяя, является ли информация, введенная пользователем, законной. Затем он инкапсулирует параметры запроса и управление запросом микрослужб управления потоком приложений через клиент службы платформы.

- Обработка услуги на сервере. После того как микрослужба управления потоком данных получает вызов запроса, она

сначала проверяет, является ли запрошенный параметр допустимым. Если это недопустимо, возвращается сообщение об ошибке. Затем микросервис выполняет бизнес-обработку. Для операции настройки значения QPS сначала проверяется, существует ли приложение. Если приложение не существует, то настройка не может быть выполнена. Если приложение существует, оно определяет, существует ли конфигурация QPS. Если конфигурация QPS существует, она выполнит обновление данных. Если он не существует, конфигурация приложения QPS создается заново.

-Межкластерная синхронизация данных. Для конфигурации управления потоком приложений шлюза API данные хранятся в кластере базы данных Mysql, но, поскольку шлюз API запрашивает подсистему прокси и считывает данные конфигурации API непосредственно из MongoDB, необходимо значение изменения в базе данных Mysql. для обновления до трех кластеров баз данных MongoDB в Пекине, Нанкине и Шанхае. Основная причина использования этих трех кластеров MongoDB заключается в том, что подсистема API Gateway Request Broker представляет собой кластер из трех разных регионов. Чтобы уменьшить межрегиональный доступ к данным, настроены три кластера MongoDB. После обновления данных API в трех кластерах четко разберитесь с конфигурацией QPS API в Redis. Если во время этого процесса происходит сбой обновления, все операции с этой базой данных откатываются.

Выводы

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

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

С помощью метода аутентификации в микросервисной архитектуре анализируются и обобщаются преимущества и недостатки микросервисной архитектуры, а также проблемы, возникающие при реализации микросервисной архитектуры.

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

Используя платформу OpenResty, проверку прав, управление потоком, перезапись URL-адресов, обратный прокси-сервер и другие функции, основанные на языках Ngnix и Lua, можно удовлетворить требования высокой производительности шлюза API. Тем не менее, все еще есть некоторые проблемы, которые необходимо постоянно обновлять, чтобы удовлетворить потребности в постоянном обновлении. Непрерыв-

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

Литература

1. Micro Service API Gateway [DB/OL]. https://blog.csdn.net/zdp072/article/details/76473383, 2022.

2. Newman S. Building Microservices[M]. O'Reilly Media,Inc , 2021

3. Tan Yiming. Design and Implementation of Platform Service Framework Based on Microservice Architecture [D]. Beijing Jiaotong University , 2022

4. Angular. Tutorial: TourofHeroes [Электронный ресурс]. -2018. - Режим доступа : https://angular.io/tutorial

5. Vue.js - Прогрессивный JavaScript-фреймворк [Электронный ресурс]. - 2018. - Режим доступа : https://ru.vuejs.org

API Gateway Management Based on Microservice Architecture Nurkaev R., Pivovarov V.V.

Swedbank, Innopolis University

JEL classification: C10, C50, C60, C61, C80, C87, C90

Microservices are actions that run in your own programs and interact with the TTP API through lightweight devices. Within a microservices architecture, the API gateway is an important component of the overall architecture. It summarizes the common features that are needed in microservices. As the only entry to a microservice, the API Gateway encapsulates a specific internal implementation and system interface. Based on the analysis and comparison of the traditional structure and the structure of microservices. This article mainly analyzes the implementation of the functions: load balancing, automatic service shutdown and gray release, and also provides a diagram of the implementation of the key API gateway technology within the microservices architecture. The article discusses a case study of technology choice and application architecture within a microservice. And it also provides a new solution to the problems associated with API Gateway management within a microservice by providing a detailed design for API Gateway authentication, reverse proxy functionality, and flow control functionality. With API Gateway, the problem of how a caller can call an independent service can be solved, thus the development efficiency can be greatly improved.

Keywords: microservice, API Gateway, architecture, gateway, application scalability

References

1. Micro Service API Gateway [DB/OL]. https://blog.csdn.net/zdp072/article/details/76473383, 2022.

2. Newman S. Building Microservices[M]. O'Reilly Media Inc 2021

3. Tan Yiming. Design and Implementation of Platform Service Framework Based on

Microservice Architecture [D]. Beijing Jiaotong University, 2022

4. Angular. Tutorial: TourofHeroes [Electronic resource]. - 2018. - Access Mode :

https://angular.io/tutorial

5. Vue.js - Progressive JavaScript framework [Electronic resource]. - 2018. - Access

mode: https://ru.vuejs.org

X X О го А С.

X

го m

о

2 О M

со