What Is an API Gateway, and Why Is It Essential?

Введение в API

Что такое API (Application Programming Interface)? API — это стандартный способ обмена данными между различными приложениями и системами. Многие команды разработчиков используют подход API-first, где итерации сосредоточены на API, начиная с проектирования, реализации, тестирования, обеспечения безопасности, развертывания, устранения неполадок и анализа API, что представляет собой полный жизненный цикл управления API (APIM).

До появления API не существовало стандартного способа обмена данными. Компьютерные программы общались друг с другом с использованием различных протоколов, таких как FTP, FTPS, SFTP, HTTPS и т.д. Отсутствие стандартов создавало высокие затраты на разработку и скрытые риски безопасности во многих аспектах: управление правами доступа, управление данными, ограничение скорости, аудит и т.д. Это "Вавилонская башня" в мире компьютеров. Чтобы создать достаточно сложный продукт, мы должны решить проблемы, вызванные системами, разработанными на разных языках и с использованием различных схем хранения данных.

Появление API успешно решило проблему "Вавилонской башни". Разработчикам теперь нужно сосредоточиться только на API, предоставляемых другими системами, и нет необходимости понимать детали их внутренней реализации.

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

Зачем использовать API Gateway?

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

Когда в начале количество API невелико, API Gateway обычно представляет собой виртуальный компонент, объединяющий веб-сервер и вышестоящие сервисы. Простые функции, такие как маршрутизация, пересылка, обратный прокси и балансировка нагрузки, выполняются Apache, NGINX и другими компонентами; другие функции, такие как аутентификация и ограничение скорости, зависят от вышестоящих сервисов.

Зачем вам нужен API Gateway?

Однако, по мере увеличения количества API, "ленивые" разработчики обнаружили серьезную проблему. В разных частях вышестоящих сервисов один и тот же код для аутентификации, ограничения скорости, логирования и других функций повторяется. Это не только расточительство ресурсов, но и кошмар управления кодом. Когда одна часть кода изменяется или обновляется, код в других местах также нуждается в обновлении. Как решить эту проблему? Умные разработчики быстро нашли решение: абстрагировать (вынести) общие функции и поместить их в отдельный компонент. Мы выносим код, не связанный с бизнес-логикой, из вышестоящих сервисов и улучшаем компоненты Apache и NGINX. Так появилось первое поколение API Gateway.

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

Роль API Gateway

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

• Плагины функций. По мере того как все больше функций внедряется в API Gateway, как отделить каждую функцию, чтобы упростить разработку? Механизм плагинов, подобный Lego, станет идеальным решением. Основные API Gateway используют плагины. В Apache APISIX они называются "плагинами". В Envoy они называются "фильтрами". Плагины освобождают разработчиков шлюзов от деталей реализации, и для реализации новых функций требуется меньше ресурсов разработки.
• Разделение плоскости данных и плоскости управления. В первом поколении API Gateway плоскость данных и плоскость управления реализованы в одном компьютерном процессе. Это упрощает развертывание и использование для пользователей, но создает значительные риски безопасности. Плоскость данных предоставляет услуги напрямую внешнему миру. Если хакеры взломают плоскость данных извне, они могут получить права управления и данные плоскости управления (например, SSL-сертификаты), что может привести к более разрушительным последствиям. Поэтому большинство открытых API Gateway теперь развертывают DP и CP отдельно и используют реляционные базы данных или etcd для управления и синхронизации конфигураций.

На примере Apache APISIX следующая архитектурная диаграмма иллюстрирует вышеупомянутые инновации:

Вызовы облачных технологий

Самым значительным технологическим изменением в IT за последнее десятилетие стало появление облачных технологий. Docker, появившийся в 2013 году, открыл занавес облачных технологий. С тех пор физические серверы и виртуальные машины были заменены контейнерами, а монолитные архитектуры — микросервисами. Однако облачные технологии — это не просто технологическая революция. Движущей силой за ней стоит быстрое развитие и жесткая конкуренция интернет-продуктов. Технологии, связанные с облачными технологиями, появились в нужное время и быстро стали популярными, заменив многие предыдущие архитектуры и решения. В частности, вызовы для API Gateway в облачных технологиях в основном связаны с двумя аспектами:

От монолита к микросервисам

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

Однако развитие микросервисов также принесло некоторые побочные эффекты, такие как:

• Количество API и микросервисов выросло с десятков до тысяч или даже десятков тысяч.
• Как быстро определить, какой API вызвал ошибку?
• Как обеспечить безопасность API?
• Как реализовать разрыв цепи и понижение уровня сервиса?

API Gateway не может самостоятельно решить проблемы безопасности, наблюдаемости и канареечных выпусков. Ему необходимо сотрудничать с множеством других открытых проектов и SaaS-сервисов, таких как Prometheus, Zipkin, Skywalking, Datadog, Okta и т.д., чтобы предоставить предприятиям лучшие решения.

Динамика и управление кластерами

Первый вызов исходит от экосистемы, а второй — от технологии.

Динамика

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

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

С эластичным масштабированием контейнеров также связаны технические вызовы:

• Частое изменение IP-адресов и портов вышестоящих сервисов.
• Частые обновления белых и черных списков IP.
• Обнаружение и обработка исключений состояния здоровья сервисов.
• Регулярные выпуски API.
• Своевременность регистрации и обнаружения сервисов.
• Горячее обновление и автоматическая ротация SSL-сертификатов.

В основе решения этих технических вызовов лежит динамика.

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

Управление кластерами

Вторая техническая проблема — это управление кластерами.

WPS, китайская компания, предоставляющая SaaS-офисное программное обеспечение, подобное Microsoft Office 365. У них сотни физических машин, работающих на Apache APISIX, почти 10 000 ядер процессоров, обрабатывающих запросы API от клиентов, и ежедневно обрабатывающих десятки миллиардов API.

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

API Gateway следующего поколения

Вышеупомянутые вызовы и проблемы постепенно породили новое поколение API Gateway.

Особенности API Gateway следующего поколения

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

• Возможность быстрее собирать потребности и проблемы разработчиков и пользователей.
• Попытка решить эти проблемы в открытых проектах.
• Открытые проекты становятся проще в использовании, привлекая больше разработчиков.

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

API Gateway поддерживает вторичную разработку с меньшими затратами

В то же время, возможность для разработчиков выполнять кастомную разработку с меньшими затратами также стала изюминкой API Gateway следующего поколения. Интеграция — одна из важнейших функций API Gateway. Для нижестоящих систем это разрешение и преобразование протоколов, включая GraphQL, gRPC, Dubbo и т.д.; для вышестоящих систем это интеграция с Okta, Keycloak, Datadog и Prometheus для услуг аутентификации и наблюдаемости, а также внутренних сервисов компании, таких как сертификация, логирование, аудит и другие.

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

Разные API Gateway предоставляют разные языки программирования и методы разработки для кастомной разработки. Например, и Apache APISIX, и Kong могут использовать Lua для написания нативных плагинов, в то время как Envoy использует C++ для написания нативных плагинов. В то же время Apache APISIX также может использовать Go, Python, Node.js, Java и Wasm для разработки плагинов. Почти все разработчики используют один из этих основных языков программирования.

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

Пример: API Gateway для трафика Black Friday

Далее давайте объясним, что делает API Gateway, на конкретном примере.

В Black Friday компании электронной коммерции проводят множество акций, и объем запросов API в этот период в десятки раз выше, чем обычно. Сначала давайте посмотрим, как будет выглядеть техническая архитектура, если бы не было API Gateway:

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

Следующая диаграмма — это архитектура после добавления API Gateway:

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

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

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

Итог

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

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

Свяжитесь с нами, чтобы узнать больше о продуктах Apache APISIX, API7 Enterprise Edition и API7 Cloud.