it-swarm.com.ru

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

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

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

Поэтому на основании этого есть несколько вопросов:

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

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

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

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

59
Justin Talbott

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

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

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

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

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

22
Andrey Chausenko