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

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

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

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

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

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

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

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

Я считаю, что 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/

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

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

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

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

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