Блог

Главная - Вопросы по программированию - Балансировка нагрузки при объединении Docker Swarm с Spring Cloud Eureka / Gateway

Балансировка нагрузки при объединении Docker Swarm с Spring Cloud Eureka / Gateway

#spring #docker #spring-cloud #docker-swarm #netflix-eureka

#spring #docker #spring-cloud #docker-swarm #netflix-eureka

Вопрос:

У меня есть вопрос относительно того, как работает балансировка нагрузки, когда у вас есть рой докеров с одним узлом, объединенный с Spring Eureka с использованием Spring Cloud gateway. Я успешно настроил рой, отличный от Eureka, и могу видеть балансировку нагрузки роя между репликами для службы:

 Cloud Gateway route config    
.route(r -> r.path("/api/**")
                            .uri("http://my-service:8081")
                            .id("my-service"))

Если я затем настрою это на использование Eureka, теперь у меня есть это:

 .route(r -> r.path("/api/**")
                                .uri("lb://MY-SERVICE")
                                .id("my-service"))

Я полагаю, что я прав, предполагая, что шлюз будет знать IP / порты и баланс нагрузки соответственно, однако, когда запрос попадает на IP, он будет роиться, а затем также решит сбалансировать нагрузку между репликами?

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

Я предполагаю, что я мог бы просто использовать http вместо lb того, чтобы остановить балансировку нагрузки шлюза.

Комментарии:

1. Итак, я думаю, что нашел ответ. Я нашел IP-адреса контейнера для своих реплик и обновил шлюз для маршрутизации на один из IP-адресов. Служба swarm обновила службу Gateway, а затем проверила журналы каждой реплицируемой службы. Был поврежден только контейнер с IP-адресом в шлюзе. Поэтому я уверен, что использование Eureka не приведет к многократной балансировке нагрузки.

Ответ №1:

Служба обнаружения eureka предоставит api gateway все доступные адреса для данной службы. Каждая служба, зарегистрированная в eureka, будет иметь уникальный (контейнер) IP и порт, и если шлюз api настроен для балансировки нагрузки запросов, тогда да, будет использоваться каждая реплика службы, swarm не нужно ничего делать для балансировки нагрузки, поскольку вы нацелены на конкретную запущенную службу (задачу), а не на узел, например.

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

Итак, это означает, что балансировщику нагрузки не нужна какая-либо служба обнаружения, такая как Eureka, чтобы сбалансировать запросы к IP-адресам или узлам определенного контейнера, он может просто перебирать все доступные узлы, и все.

Что касается внутренних запросов между службами, имеющими реплики, swarm также обеспечивает возможности балансировки нагрузки.