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