Принципы API-шлюза

Шлюз API - это точка входа для доступа к различным возможностям сложной платформы через четко определенные API. Чтобы проиллюстрировать эту концепцию, допустим, вы создаете веб-сайт для магазина электроники и разрабатываете API / electronics для его домашней страницы. Этот API, размещенный в одной службе, возвращает список электроники в магазине плюс рекомендуемые товары. А теперь представьте, что магазин со временем разрастается, и вы решили создать специальные сервисы для товаров длительного пользования и мобильных телефонов. Кроме того, вы решили создать специальную службу рекомендаций. Таким образом, чтобы отобразить домашнюю страницу, вам теперь необходимо интегрироваться с несколькими микросервисами, увеличивая общее количество обращений к серверной части. Если добавляется новая категория электроники, весь процесс реинтеграции повторяется. API-шлюз может справиться с этой сложностью, подключившись к домашней странице один раз и организовав запросы к такому количеству микросервисов, которое необходимо. Кроме того, вы можете независимо развивать свои микросервисы без изменения интеграции клиента.

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

1. Масштабируемость и производительность

Если ваша платформа обслуживает миллионы / миллиарды запросов в день, имеет смысл инвестировать в правильную технологию, которая может поддерживать высокий трафик без снижения производительности. Фреймворки на основе асинхронного неблокирующего ввода-вывода (NIO) лучше всего подходят для таких случаев. Одним из предпочтительных фреймворков является Netty, и было доказано, что использование его в качестве контейнера HTTP обеспечивает желаемый прирост производительности. Обычно API-шлюз обращается к нескольким внутренним службам для входящего запроса. Если ваши серверные микросервисы обрабатываются долго, ресурсы потоков в вашем шлюзе могут истощиться, что приведет к нехватке ресурсов и, следовательно, повлияет на ATB шлюза (доступность для бизнеса). Таким образом, написание кода API декларативным способом с использованием шаблона реактивного кодирования является правильным выбором для таких приложений. Например, в качестве реактивной абстракции можно использовать CompletableFuture из JAVA 8. В заключение, для приложения с высоким трафиком, такого как API Gateway, лучше всего использовать структуру NIO и модель реактивного программирования для оптимального использования ресурсов, что обеспечивает высокую производительность. На следующем графике сравнивается задержка (в мс) приложения Gateway, использующего Tomcat и Netty в качестве контейнера HTTP.

2. Запросить оркестровку

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

  • Трансляция протокола: API входящего запроса может иметь определенный формат, который может отличаться от ваших последующих сервисов. Например, API-шлюз получает запросы HTTPS RESTful, в то время как некоторые нижестоящие службы могут ожидать Protobuf. Сервер шлюза должен гарантировать, что соответствующие соединители и трансляторы встроены.
  • Последовательные / параллельные шаблоны вызова: API-шлюз должен разрешать вызов нижестоящих служб в последовательном и / или параллельном шаблонах. Наряду с этим должна быть доступна поддержка условной маршрутизации.
  • Настраиваемая маршрутизация: шаблоны маршрутизации не должны требовать нового кода (или минимального кода) для создания нового маршрута к внутренней микросервисе. Другими словами, маршрутизация услуг должна определяться конфигурациями. Это гарантирует, что кодовая база шлюза останется компактной по мере оснащения новых API.

3. Перевод ответа

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

4. Включение резервной копии

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

5. Ограничение скорости и контроль доступа

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

6. Мониторинг и аналитика

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

Шлюз API для платформы управления рисками в PayPal

В заключение скажу, что в мире множества разнообразных микросервисов API Gateway - естественный выбор, позволяющий четко раскрыть возможности. При разработке шлюза API необходимо учитывать различные параметры, в том числе подходящую технологию для масштабируемости, шаблоны проектирования, поддерживающие гибкую оркестровку / консолидацию, резервные службы, ограничители скорости, средства управления доступом к API и широкие возможности мониторинга и аналитики. Наша команда в PayPal построила API-шлюз на этих принципах, который служит единой точкой входа для всех API-интерфейсов управления рисками в PayPal. В настоящее время он обслуживает несколько миллионов вызовов API в день и имеет задержку всего 1,4 мс (в среднем) и 3 мс (99% файлов). Использование ЦП и памяти низкое даже при пиковом трафике, и, следовательно, нам легко обслуживать растущие транзакции без горизонтального увеличения емкости.