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

Question

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

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

В других местах, когда я гуглил топи c, говорят, что они совершенно разные. Я понял, что API Gateway делает много вещей, таких как завершение SSL, ведение журнала, регулирование, проверка и т. Д. c, но он также выполняет распределение нагрузки. Итак, API Gateway сам по себе является балансировщиком нагрузки, наделенным другими обязанностями?

В топи c я хочу понять, распределяет ли распределитель нагрузки нагрузку между серверами одного кластера или между различными центрами обработки данных или кластерами? А как насчет API Gateway?

Что такое спецификация c для шлюза API, что по умолчанию это выбор для архитектуры микросервиса? Где размещаются шлюзы API? DNS разрешает доменное имя в балансировщик нагрузки или шлюз API?

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

Answer 1

API-шлюз преимущественно выполняет управление API и предоставляет различные другие ключевые функции, такие как IAM (управление идентификацией и доступом), ограничение скорости, автоматические выключатели. Следовательно, это в основном устраняет необходимость реализации API-специфичного c кода для таких функций, как безопасность, кэширование, регулирование и мониторинг для каждого микросервиса. Микросервисы обычно предоставляют API REST для использования во внешних интерфейсах, других микросервисах и сторонних приложениях с помощью API-шлюза.

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

В архитектуре системы на основе Azure существует Azure Application Gateway, который является балансировщиком нагрузки, который работает на уровне 7 и предоставляет больше возможностей, чем традиционный балансировщик нагрузки (уровень 4) с точки зрения трафика маршрутизации c с использованием решений о маршрутизации, основанных на дополнительных атрибутах HTTP-запроса или содержимого траффи c. Это также можно назвать балансировщиком нагрузки приложения. Он должен использоваться совместно с Azure API Management (шлюз API). Azure имеет менеджер Traffi c для работы на уровне DNS, который использует DNS для направления клиентских запросов к наиболее подходящей конечной точке службы на основе метода маршрутизации c и работоспособности конечных точек. Traffi c manager также использует правила, настроенные на уровне DNS, и позволяет распределять нагрузку по нескольким регионам и центрам обработки данных. В каждом регионе или центре обработки данных должны быть шлюзы приложений, соединенные с балансировщиками нагрузки, так что шлюзы приложений должны помогать в определении сервера приложений для получения ответа, а балансировщик нагрузки должен помогать в балансировке нагрузки.

Система обзор на основе Azure:

Вот несколько ссылок:

1. Azure Шлюз приложений - https://docs.microsoft.com/en-us/azure/application-gateway/application-gateway-introduction

2. Azure Балансировщик нагрузки - https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-overview

3. Azure Traffi c Менеджер - https://docs.microsoft.com/en-us/azure/traffic-manager/traffic-manager-overview

4. Архитектура сценария - https://docs.microsoft.com/en-us/azure/traffic-manager/traffic-manager-load-balancing-azure

Answer 2

API Gateway и Load Balancer - это две разные вещи.

Load Balancer -> Это программное обеспечение, которое работает на уровне протокола или сокета (например, tcp, http или port 3306 et c.). работа состоит в том, чтобы сбалансировать входящий трафик c, распределяя его по адресатам с помощью различных логик (например, круговой прием). Я не предлагаю такие функции, как проверка авторизации, аутентификация запросов и т. Д. c.

Принимая во внимание, что

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

О разрешении домена, скорее всего, всегда DNS разрешает балансировщик нагрузки, который интернирует выборку ответа от службы шлюза API.

DNS -> Load Balancer -> API gateway -> Backend service

Надеюсь, я смогу объяснить и устранить вашу путаницу.