Тайм-аут балансировки нагрузки Service Fabric

Question

У меня есть два основных веб-приложения .net (appA и appB), докеризованных, работающих в трех узлах сервисной фабрики (узел1, узел2 и узел3).Служебная структура работает в Azure с балансировщиком нагрузки.

Когда у меня есть запрос извне, он работает хорошо.

Когда у меня есть внутренний запрос от appA к appB, через узел 1 к узлу 2тоже хорошо работает.

Но, похоже, когда балансировщик нагрузки решает направить запрос от appA к appB в том же узле, я получил тайм-аут.Например:

Запрос извне к appA внутри node1, поэтому appA запрашивает балансировщик нагрузки для доступа к appB.Балансировщик нагрузки направляет запрос на узел 1 (тот же исходный узел).Затем я получил тайм-аут.

«Проблемный» поток:

Запрос от web -> балансировщик нагрузки -> node1 -> appA (на данный момент приложению потребуется информация из службы olther) -> балансировщик нагрузки (и здесь, кажется, у меня есть тайм-аут) -> node1 -> appB .

Кто-то сталкивается с такой же проблемой или что-то в этом роде?

Answer 1

Это связано с тем, что Azure LoadBalancer, как следует из названия, распределяет входящую нагрузку между узлами (ВМ) за ним, в вашем случае у вас есть 3 узла (ВМ) за балансировщиком нагрузки, и каждое соединение с балансировщиком нагрузки будетпереадресация на один узел (ВМ).

Самый простой способ решения этой проблемы - сделать запрос через обратный прокси-сервер Service Fabric, при включении обратный прокси-сервер будет доступен на всех узлах, поэтому каждый запрос поступает.через LB найдете RP (обратный прокси) в узле.Обратный прокси-сервер будет обрабатывать работу по поиску контейнера в вашем кластере, независимо от того, находятся ли они на том же узле или на другом.

В конце внешний клиент отправит запрос на что-то вроде:

http://{sf-cluster-fqdn}:19081/DockerSFAppName/ContainerName/<any-path-inside-your-container>

Пожалуйста, посмотрите в документах здесь

Если вы не хотите указывать имя приложения и контейнера для доступа к вашему контейнеру, у вас есть следующие варианты:

• Используйте другой механизм обратного прокси-сервера, например, предложенный @ 4c74356b41, и вручную настройте его для пересылки в ваши контейнеры или преобразования его в обратный прокси-вызов внутри кластера.Моя рекомендация: traefik
• Создайте свой собственный ReverseProxy с правилами, необходимыми для пересылки запроса
• Разверните один экземпляр каждого контейнера на каждый узел, не идеально, ноопция

Answer 2

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

appA - nginx - load balancer - appb

В качестве альтернативы вы можете использовать шлюз приложений (предложение PaaS)