API-шлюз против обратного прокси

109

Чтобы иметь дело с архитектурой микросервисов, он часто используется вместе с обратным прокси (например, nginx или apache httpd), а для сквозных проблем используется шаблон шлюза API для реализации . Иногда обратный прокси выполняет работу шлюза API.
Было бы хорошо увидеть четкие различия между этими двумя подходами. Похоже, что потенциальная выгода от использования шлюза API - это вызов нескольких микросервисов и агрегирование результатов. Все остальные функции шлюза API могут быть реализованы с помощью обратного прокси, например:

  • Аутентификация (это можно сделать с помощью скриптов nginx LUA);
  • Транспортная безопасность. Это сама задача обратного прокси;
  • Балансировки нагрузки
  • ....

Исходя из этого, возникает несколько вопросов:

  1. Имеет ли смысл использовать шлюз API и обратный прокси одновременно (например, запрос-> шлюз API-> обратный прокси (nginx) -> конкретный микосервис)? В каких случаях?
  2. Какие еще отличия могут быть реализованы с использованием шлюза API и которые не могут быть реализованы с помощью обратного прокси и наоборот?
nginx reverse-proxy microservices aws-api-gateway tyk user1459144
источник

Ответы:

85

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

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

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

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

Я считаю, что API Gateway - это обратный прокси-сервер, который можно динамически настраивать через API и, возможно, через пользовательский интерфейс, в то время как традиционный обратный прокси (например, Nginx, HAProxy или Apache) настраивается через файл конфигурации и должен быть перезапущен при изменении конфигурации. Таким образом, API Gateway следует использовать при частом изменении правил маршрутизации или другой конфигурации. На ваши вопросы:

  1. Это имеет смысл, если каждый компонент в этой последовательности служит своей цели.
  2. Различия не в списке функций, а в способе применения изменений конфигурации.

Кроме того, API Gateway часто предоставляется в форме SAAS, например Apigee или Tyk. .

Кроме того, вот мой учебник о том, как создать простой API-шлюз с Node.js https://memz.co/api-gateway-microservices-docker-node-js/

Надеюсь, поможет.

Андрей Чаусенко
источник
Спасибо за предложения SAAS
Zenuka
4
есть ли шанс, что вы знаете альтернативное место для информации о том, что было в той ссылке на memz.co? Он мертв.
Новая Александрия,
0

Шлюзы API обычно работают как конструкция L7.

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

  • полное управление жизненным циклом API, включая документацию
  • портал, который можно использовать в качестве источника истины для различных клиентских приложений, и где вы можете обеспечить управление клиентами, ограничение скорости и т. д.
  • маршрутизация на разные версии API, включая canary / beta версии
  • обнаружение шаблонов использования, регистрация приложений, получение учетных данных клиента и т. д.

Однако с появлением таких сервисных сеток, как Istio, Consul, многие функции API-шлюзов перейдут на сетку.

pcodex
источник