Паттерн API Шлюз(Gateway) VS Обратный прокси(Reversed proxy) - перевод

1. Обзор

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

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

2. Архитектура

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

3. Обратный прокси

Одна из причин, по которой использование обратного прокси становится полезным, заключается в том, что его можно использовать в качестве посредника между клиентской стороной и одним или несколькими внутренними серверами .
Давайте представим, что у вас есть архитектура микросервисов , и мы наблюдаем, как их количество растет по мере развития проекта. В определенный момент обусловленной сложностью наличия неоднородной поверхностью API, может возникнуть необходимость замаскировать всю эту сложность. Для этого обратный прокси может переписать URL-адреса. Клиент не знает, кто находится за обратным прокси. Обратный прокси-сервер отвечает за пересылку запроса серверной части, которая может его выполнить.

Типичные варианты использования обратного прокси-сервера включают:

Балансировка нагрузки : предлагает возможность распределять входящие запросы между несколькими внутренними серверами. Такая балансировка нагрузки предотвращает перегрузку отдельных систем и компенсирует сбои серверной части. Если бэкенд становится недоступен из-за каких-то ошибок, то его модуль балансировки нагрузки перераспределяет входящие запросы на оставшиеся бэкенды
Защита от атак : предлагает возможность установки систем управления, таких как антивирусные или пакетные фильтры, которые, позиционируя себя между Интернетом и частной сетью, дополнительно защищают серверную часть.
Кэширование : для повторяющихся запросов может отвечать автономно, частично или полностью. Контент часто хранится в кэше прокси. Таким образом, из серверной части извлекается меньше данных, и клиенты получают ответ за меньшее время.
Шифрование SSL : его можно настроить для расшифровки всех входящих запросов и шифрования всех исходящих ответов, освобождая ценные ресурсы на бэкэнде.

На данный момент, если всех этих возможностей недостаточно, нам, вероятно, понадобится шлюз API. Давайте углубимся в то, что дополнительно предоставляет из себя API Шлюз.

4. API Шлюз

Мы можем думать о API Gateway как о надмножестве обратного прокси. Далее мы обсудим дополнительные возможности, которые он может предложить.

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

Еще одна функция, связанная с обработкой запросов/ответов, — это Protocol Translation . Другими словами, шлюз API может выполнять преобразование протокола в протокол (например, XML в JSON, gRPC в JSON) для облегчения интеграции между клиентом и сервером.

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

Начнем с безопасности, он предлагает:

Аутентификация и авторизация : централизация на границе, кто и что может запрашивать
Белый список IP-адресов: он может предоставить возможность использовать API только для определенных IP-адресов.

Переходим к тем, что касаются производительности:

Ограничение скорости , регулирование и квота : мы можем установить ограничение в зависимости от того, сколько запросов/данных могут обработать сервера за определенную единицу времени. Кроме того, если смотреть больше на коммерческий аспект, он предлагает возможность контролировать трафик, который используют потребители API, на основе приобретенного плана.
Политика повторных попыток и прерыватель цепи : они используются для повышения отказоустойчивости и надежности бэкэндов за счет управления их временной недоступностью (например, повторное выполнение запроса от имени клиентов или защита серверов от перегрузки запросами).

В заключение с наблюдаемостью и отслеживаемостью:

Ведение журнала, трассировка, корреляция : собирают все журналы для каждого конкретного запроса, и знают, какие бэкэнды он задействованы, и соответствующие показатели.

5. Отличия

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

6. Выводы

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