Насколько я понимаю, из документации с использованием Netflix Zuul & Eureka (возможно, Ribbon тоже) можно построить активный балансировщик нагрузки. Я всегда использовал AWS ELB, ALB (ECS для управления контейнерами) с R53.
Помимо переносимости поставщика, есть ли какое-либо преимущество в использовании подхода Netflix по сравнению с использованием AWS, предоставляемого ALB / ELB? Есть ли какой-либо вариант использования Netflix OSS вместо готовых AWS ELB?
Балансировщик нагрузки не управляет отказоустойчивостью на стороне клиента, например повторными попытками, откатами, реестром служб и маршрутизацией. Netflix OSS предлагает балансировку нагрузки среднего уровня и несколько функций отказоустойчивости. Подобные функции можно найти в AWS AppMesh и AWS Cloud Map. Балансировщик нагрузки - это просто конечная точка, которая может направлять клиентов к функциям, контейнерам или экземплярам. Использование балансировщика нагрузки и сервисных сеток (от Netflis OSS и / или AWS), безусловно, способствует надежности приложений.
Стек Netflix OSS может работать с ALB и ELB и т. Д. Например, вам все еще нужен какой-то API-шлюз (который позволяет реализовать Zuul) для защиты ваших маршрутов даже при работе с ALB или ELB. Лента и Eureka могут использоваться для обнаружения служб в дополнение (или вы можете просто жестко закодировать маршруты к другим вашим микросервисам в конфигурации Zuul и не беспокоиться о том, чтобы запускать сервер Eureka). Таким образом, вы можете использовать Zuul в качестве контейнера, который использует тот же ALB, что и другие ваши микросервисы в ECS, и чтобы все запросы от вашего внешнего интерфейса сначала попадали в маршрут к Zuul, а затем на основе запроса Zuul решал, какой маршрут микросервиса должен проксировать запрос на. Если вы не используете ECS или контейнеры, этот же архитектурный шаблон отлично подойдет и для виртуальных машин EC2.
