[Перевод] Шаблоны: API Gateway и BFF

API
[Перевод] Шаблоны: API Gateway и BFF

место действия

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

  • на основеHTML5/JavaScriptПользовательский интерфейс для настольных и мобильных браузеров — HTML, созданный веб-приложением на стороне сервера.
  • местныйAndroidа такжеiPhoneКлиенты - Эти клиенты проходят черезREST APIsвзаимодействовать с сервером

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

Страница информации о продукте отображает много информации о продукте. НапримерAmzon.comначальствоPOJOs in ActionИнформационная страница книги показывает:

  • Основная информация о книге, такая как название, автор, цена и т. д.
  • Ваша история платежей за эту книгу
  • Есть ли в наличии (в наличии)
  • варианты покупки
  • Книги, которые часто покупают вместе с этой книгой
  • Какие еще книги купили другие покупатели, купившие эту книгу?
  • Отзывы покупателей
  • Рейтинг продавца
  • ...

Поскольку в этом торговом центре используется шаблон архитектуры микросервисов, конкретная информация о продукте распределяется по нескольким микросервисам. Например:

  • Служба информации о продукте — основная информация о продукте, например, название, автор.
  • Ценовая служба - ценообразование продукции
  • Служба заказов - История платежей за продукты
  • Inventory Service - доступен ли продукт для покупки
  • Служба отзывов - отзывы покупателей

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

вопрос

Как клиент приложения на основе микрослужб получает доступ к отдельным службам?

Болевые точки

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

решить

Внедрите шлюз API в качестве единственной точки входа для доступа всех клиентов к серверу. Шлюз API обычно обрабатывает запросы двумя способами: некоторые запросы просто передаются через прокси или перенаправляются в соответствующую службу, в то время как для других служб шлюз может распределять их между несколькими службами одновременно (fan out to multiple services).

Use an API gateway

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

Шлюз API также может реализовывать меры безопасности, такие как проверка того, что клиент авторизован для выполнения запроса.

Вариант: Бэкенды для фронтендов (Backends for frontends — BFF)

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

Variation: Backends for frontends

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

В заключение

Использование шлюза API имеет следующие преимущества:

  • Клиент будет полностью изолирован от того, как серверная часть приложения разделяет микросервисы.
  • Клиенты будут полностью изолированы от проблемы определения местоположения экземпляров сервиса.
  • Предоставлять лучший API для каждого типа клиентов
  • Сократите много запросов и туда и обратно. Например, шлюзы API позволяют клиентам получать данные из нескольких служб за один цикл. Меньшее количество запросов также означает меньшие затраты ресурсов и лучший пользовательский опыт. API Gateway необходим для мобильных приложений
  • Упрощенный клиент. Изменена логика работы клиента, клиенту больше не нужно вызывать несколько сервисов, а вся работа перенесена на API-шлюз
  • Он может преобразовывать стандартные общедоступные веб-дружественные API-протоколы в произвольные протоколы, используемые внутри компании.

API Gateway также имеет свои недостатки:

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

проблема

  • Как реализовать шлюз API? Если шлюз должен масштабироваться для обработки высоких нагрузок, лучше всего использовать управляемый событиями или реактивный подход. существуетJVM, или какNetty,Spring Reactorтакой на основеNIOБиблиотека работает отлично.NodeJSтоже вариант.

связанные узоры

известно, что используется

Пример приложения

См. шаблон микросервисов вПример приложенияРаздел шлюза API файла . Он реализован с использованием Spring Cloud Gateway.

Категории