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

Question

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

Шлюз API имеет более широкий набор функций - особенно вокруг безопасности и мониторинга - чем API прокси. Я бы сказал, что шаблон шлюза API, также называемый Backend for frontend (BFF) , широко используется при разработке микросервисов. Ознакомьтесь со статьей о преимуществах и особенностях шаблона API Gateway в мире микросервисов.

С другой стороны, прокси API - это, по сути, облегченный шлюз API . Он включает в себя некоторые базовые возможности безопасности и мониторинга. Итак, если у вас уже есть API и ваши потребности просты, прокси API будет работать нормально.

Изображение ниже предоставит вам четкое представление о разнице между API Gateway и обратным прокси.

Answer 4

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

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

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

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

Answer 5

Из HTTP: Полное руководство:

Строго говоря, прокси-серверы соединяют два или более приложений, использующих один и тот же протокол, а шлюзы соединяют две или более сторон, использующих разные протоколы. Шлюз действует как «преобразователь протоколов», позволяя клиенту выполнять транзакцию с сервером, даже если клиент и сервер используют разные протоколы.

На практике разница между прокси и шлюзами размыта. Поскольку браузеры и серверы реализуют разные версии HTTP, прокси-серверы часто выполняют некоторое преобразование протокола. А коммерческие прокси-серверы реализуют функции шлюза для поддержки протоколов безопасности SSL, брандмауэров SOCKS, доступа по FTP и веб-приложений.

Answer 6

По поводу ответа Андрея Чаусенко, что

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

Я думаю, что в настоящее время это не так, поскольку современные обратные прокси, такие как Envoy, могут динамически настраиваться плоскостью управления через xDS.

Answer 7

Обратный прокси-сервер, такой как Nginx и Apache, не занимается наблюдаемостью, аутентификацией, авторизацией, оркестровкой сервисов и т. д., а только балансирует нагрузку и перенаправляет трафик вверх по течению.

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

Различное позиционирование приводит к различным техническим аспектам обратного прокси-сервера и API-шлюза. Шлюзы API, такие как Apache APISIX, имеют около 100 подключаемых модулей и поддерживают несколько языков программирования для разработки подключаемых модулей.

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