Паттерн 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:

Сделано QuickLaTeX.com

6. Выводы

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