Выбор шлюза API и разработка архитектуры, включая BFF

Введение

На следующем рисунке представлена ​​простая архитектурная схема микросервисной архитектуры, которую я нашел в Интернете.Как видно из рисунка, шлюз API играет связующую роль и является ключевым компонентом.

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

Затем проксируйте запрос NGINX на шлюз API для обработки унифицированного шлюза.

В приведенном выше сценарии шлюз API может включать следующие функции:

• Безопасность
• Ограничение
• тайник
• предохранитель
• Повторить попытку
• нагрузка
• обратная маршрутизация
• аутентификация, аутентификация
• Сбор логов и мониторинг
• разное

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

Две структурные корректировки

На следующем рисунке показана архитектурная схема, которую я разработал на основе облачной микросервисной архитектуры.Внешний трафик проходит через SLB -> NGINX -> API Gateway к определенным службам.

Выбор шлюза API из трех стеков технологий Java

Поскольку серверная часть разработана с использованием весеннего облака Java, согласованность языка более склонна к компонентам, разработанным на языке Java. Как показано на рисунке выше, хотя Spring Cloud Gateway написан на месте API Gateway, также можно использовать такие компоненты, как zuul и zuul2, которые также разработаны на языке java. Для выбора конкретного зуула и весеннего шлюза считается следующим образом:

	spring cloud gateway	zuul
представление	Почти вдвое выше производительность Netflix Zuul	Zuul1 имеет низкую производительность Zuul2 имеет большее улучшение, чем Zuul1
Сообщество и документация	Весеннее сообщество очень активно	в целом
ремонтопригодность	Сильное официальное техобслуживание по весне	Частые отказы, у Spring Cloud пока нет плана интеграции для Zuul 2.0
Особенности	Асинхронная, гибкая конфигурация	Зрелый, простой и низкий порог
недостаточный	Ранние продукты и новые версии выходят на яму	Общая производительность, общая программируемость

В отрасли в основном признано, что производительность Spring Cloud Gateway лучше, чем Zuul. Фактически, Spring Cloud Gateway официально выпустил тест производительности. Вот выдержка из следующих данных:

Spring Cloud Gateway построен на базе Spring 5+ и основан на реактивном неблокирующем API Spring Boot 2.x. В то же время он поддерживает веб-сокеты и тесно интегрирован с фреймворком Spring. С текущей точки зрения, шлюз на замену zuul является тенденцией.Исходя из вышеизложенного, рассмотрите возможность использования Spring Cloud Gateway в архитектуре.

Выбор четырех шлюзов API стека технологий, отличных от Java

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

NGINX — отличное программное обеспечение, но отсутствие динамизма приводит к негибкости.Последнее OpenResty, программное обеспечение tengine, основанное на NGINX и Lua, имеет существенные улучшения в динамизме и гибкости и основано на сценариях Lua и плагинах, которые могут реализовывать так называемыепрограммируемый.

Представленное на рынке прикладное программное обеспечение на базе OpenResty с API Gateway в качестве сценария применения включает в себя:Конг, APISIX, тыкЖдать. Ниже представлен обзор пейзажа CNCFland.

Сравните NGING и KONG

После рассмотрения с точки зрения архитектуры можно заменить NGINX и Spring Cloud Gateway на KONG или другое программное обеспечение на более позднем этапе.

После сравнения самое популярное приложение — Kong, и еще один отечественный тренд APISIX тоже очень силен, и их технологические стеки похожи, поэтому я нашел в подборке сравнение, сделанное автором APISIX:

С точки зрения основных функций шлюза API были рассмотрены оба:

Более подробное сравнение:

В ходе теста производительности видно, что производительность (количество запросов в секунду и задержка) Apache APISIX в два раза выше, чем у Kong без включения подключаемого модуля, но с включенными двумя распространенными подключаемыми модулями производительность в десять раз выше, чем у Kong.

APISIX превосходен с точки зрения производительности, удобства использования и объема программируемого кода. Единственная проблема в настоящее время заключается в том, что в этом раннем проекте не так много практики крупномасштабного применения. Ожидание большей производственной практики в качестве основы.Конечно, если архитектор считает, что риск невелик, и он проверен и исследован, его тоже можно использовать. 😁

Пять итераций построения слоя BFF

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

• отсечение данных API
• расположение интерфейса
• вызов интерфейса

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

На уровне BFF внешний и внутренний интерфейсы будут лучше разделены, интерфейсу больше не нужно вызывать несколько интерфейсов, а затем организовывать данные, а серверу микросервиса нужно заботиться только о вещах внутри. собственные границы обслуживания.

Однако на практике возникают некоторые проблемы:

• Большая часть бизнес-логики сосредоточена на уровне BFF с фронта и бекенда.
• Логика уровня BFF сложна, и объем кода становится больше и сложнее в обслуживании.
• Поддержка версии BFF API сложна
• Обязанности фронтенд-интерфейса неясны, и результат пререканий — поставить его на уровень BFF

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

Следующая картинка представляет собой идеальную архитектуру, которую я нашел в Интернете и которая соответствует моему мнению.

Это легко сказать, но это не так просто сделать.Детали - дьявол.Каждый раз, когда используется новая технология, она проходит через волну монстров и апгрейдов. Однако в целом использование GraphQL теоретически может решить вышеуказанные проблемы. Основное внимание уделяется тому, как интегрировать его в архитектуру вашей системы и использовать его преимущества.Архитектура — это множество компромиссов и вариантов

Обратите внимание на технический обмен маленькой коробкой на официальном аккаунте, чтобы получить больше интересного контента.