Почему я должен использовать обратный прокси-сервер Service Fabric вместо шлюза приложений Azure для связи с кластером SF?
Это длинный вопрос, и я уверен, что есть компромиссы. Документация в этой области:
Не дает мне достаточно, чтобы ответить на вопрос выше уверенно.
Итак, они говорят: "Azure Application Gateway (AG) пытается снова разрешить адрес службы и повторить запрос, когда служба не может быть достигнута".
Я знаю, как обратный прокси-сервер Service Fabric (RP) делает это путем инкапсуляции цикла разрешения. Есть ли у AG эта возможность тоже? AG также является обратным прокси-сервером.
Итак, что крайне важно для внешнего трафика в кластер SF, почему я должен использовать один поверх другого (я знаю, что RP также допускает обмен данными внутри кластера, и это хорошо подходит).
3 ответа
Что ж, для внешнего трафика в кластер вы получите готовую комбинацию балансировки нагрузки и обратного прокси Azure. Но достаточно ли этого - другой вопрос. Нам нужно было принять одно и то же решение, и в итоге мы использовали шлюз приложений.
Различия между балансировщиком нагрузки Azure и шлюзом приложений описаны в этом документе.
Некоторые выносы:
- Azure Load Balancer работает на транспортном уровне (уровень 4 в сетевом эталонном стеке OSI). Он обеспечивает распределение трафика на уровне сети между экземплярами приложения, работающего в том же центре данных Azure.
- Шлюз приложений работает на прикладном уровне (уровень 7 в сетевом эталонном стеке OSI). Он действует как обратный прокси-сервер, разрывая клиентское соединение и перенаправляя запросы на конечные точки сервера.
Таким образом, Application Gateway дополнительно поддерживает SSL-терминацию, сквозную SSL-связь и маршрутизацию на основе URL-адресов, что делает его хорошим кандидатом для приложений Service Fabric, имеющих внешних клиентов.
При условии, что путь уже пройден, дополнительные компромиссы стали для меня реальностью только при физической реализации.
Если вы не используете обратный прокси-сервер, то добавление других сервисов в кластер и возможность дифференцировать запросы к ним становится невероятно дорогим упражнением.
Рассмотрим стоимость добавления новых PIP, правил наттинга балансировщика нагрузки, правил брандмауэра (если используются NVA) и содержащихся в них правил наттинга.
Другими словами, без RP, я говорю, что вы фактически получаете отношение один к одному между внешним IP-адресом и службой на узле, что проявляется в жестком кодировании маршрута от точки к точке.
С помощью обратного прокси-сервера, такого как traefic, вы можете использовать обнаружение служб для развертывания и создания активных служб с гораздо меньшей конфигурацией. Значительная экономия времени, сил и денег. При реализации RP я буду обновлять ответ снова.
Я могу сказать вам, почему вы не можете использовать обратный прокси.
При настройке порта обратного прокси-сервера в балансировщике нагрузки все микросервисы в кластере, которые предоставляют конечную точку HTTP, могут быть адресованы извне кластера.
Если у вас есть какие-либо службы, которые вы не хотите подвергать воздействию внешнего мира, вы, вероятно, не хотите использовать обратный прокси-сервер.