it-swarm.com.ru

Почему я должен использовать обратный прокси-сервер Service Fabric вместо шлюза приложений Azure для связи с кластером SF?

Это длинный вопрос, и я уверен, что есть компромиссы. Документация в этом область :

Не дает мне достаточно, чтобы уверенно ответить на вопрос выше.

Итак, они говорят: "Azure Application Gateway (AG) пытается снова разрешить адрес службы и повторить запрос, когда служба не может быть достигнута".

Я знаю, как обратный прокси-сервер Service Fabric (RP) делает это путем инкапсуляции цикла разрешения. Есть ли у AG эта возможность тоже? AG также является обратным прокси-сервером.

Итак, что крайне важно для внешнего трафика в кластер SF, почему я должен использовать один поверх другого (я знаю, что RP также разрешает передачу внутри кластера и это хорошо подходит).

6
brumScouse

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

Различия между балансировщиком нагрузки Azure и шлюзом приложений описаны в документе этот .

Некоторые выносы:

  • Azure Load Balancer работает на транспортном уровне (уровень 4 в сетевом эталонном стеке OSI). Он обеспечивает распределение трафика на уровне сети между экземплярами приложения, работающего в том же центре данных Azure.
  • Шлюз приложений работает на прикладном уровне (уровень 7 в сетевом эталонном стеке OSI). Он действует как служба обратного прокси-сервера, разрывая клиентское соединение и перенаправляя запросы на конечные точки сервера.

Таким образом, Application Gateway дополнительно поддерживает завершение SSL , сквозное SSL и маршрутизация на основе URL , что делает его хорошим кандидатом для приложений Service Fabric, которые есть внешние клиенты.

4
Peter Bons

При условии, что путь уже пройден, дополнительные компромиссы стали для меня реальностью только при физической реализации.

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

Рассмотрите стоимость добавления новых PIP, правил наттинга балансировщика нагрузки, правил брандмауэра (если используется NVA) и содержащихся в них правил наттинга.

Другими словами, без RP, я говорю, что вы фактически получаете взаимно-однозначное отношение между внешним IP-адресом и службой на узле, что проявляется в жестком кодировании маршрута от точки к точке.

С помощью обратного прокси-сервера, такого как traefic, вы можете использовать обнаружение служб для развертывания и создания активных служб с гораздо меньшей конфигурацией. Значительная экономия времени, сил и денег. При реализации RP я буду обновлять ответ снова.

0
brumScouse