Гранулярность шлюзов API для сервисных балансировщиков

Гранулярность шлюзов API для сервисных балансировщиков
Гранулярность шлюзов API для сервисных балансировщиков - growtika @ Unsplash

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

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

Балансировка нагрузки здесь ничего не меняет. В модели единого шлюза API запросы к службе через шлюз распределяются между всеми внутренними серверами службы. На практике балансировка нагрузки, выполняемая шлюзом, будет выглядеть точно так же, как балансировщик нагрузки на основе циклического перебора DNS, если бы шлюза вообще не существовало. Однако шлюз может обеспечить более интеллектуальную балансировку нагрузки (мониторинг работоспособности сервисного сервера и т. д.), чем простая балансировка нагрузки DNS-RR.


При этом Netflix внутренне запускает экземпляр Zuul для каждой службы. Посмотрите их архитектуру:

Источник: Как мы используем Zuul в Netflix

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

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

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


Надеюсь это поможет! Я потратил много времени на изучение этого, поэтому я уверен в этой информации.

Рекомендую посмотреть эти видео для лучшего погружения в вопрос:

Прикрепленное видео 1 - Обзор IBM Cloud Pak for Integration и IBM Cloud Pak for Applications

Прикрепленное видео 2 - Совместный вебинар Citrix и «С-Терра СиЭсПи», 26.04.2016


LetsCodeIt, 1 января 2023 г., 12:08