почему я должен использовать обратный прокси-сервер service fabric вместо шлюза приложений azure для связи с кластером sf?

<p>это длинный вопрос, и я уверен, что есть компромиссы. документация в этом <a href="https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reverseproxy">область</a> :</p><p><strong> не дает </strong> мне достаточно, чтобы уверенно ответить на вопрос выше.</p><p>итак, они говорят: "azure application gateway (ag) пытается снова разрешить адрес службы и повторить запрос, когда служба не может быть достигнута".</p><p>я знаю, как обратный прокси-сервер service fabric (rp) делает это путем инкапсуляции цикла разрешения. есть ли у ag эта возможность тоже? ag также является обратным прокси-сервером.</p><p>итак, что крайне важно для <strong> внешнего </strong> трафика в кластер sf, почему я должен использовать один поверх другого (я знаю, что rp также разрешает передачу внутри кластера и это хорошо подходит).</p>

<p>что ж, для внешнего трафика в кластер вы получите готовую комбинацию балансировки нагрузки и обратного прокси azure. но достаточно ли этого - другой вопрос. нам нужно было принять одно и то же решение, и в итоге мы использовали шлюз приложений.</p><p>различия между балансировщиком нагрузки azure и шлюзом приложений описаны в документе <a href="https://docs.microsoft.com/en-us/azure/application-gateway/application-gateway-introduction#load-balancer-differences">этот</a> .</p><p>некоторые выносы:</p><blockquote> <ul> <li>azure load balancer работает на транспортном уровне (уровень 4 в сетевом эталонном стеке osi). он обеспечивает распределение трафика на уровне сети между экземплярами приложения, работающего в том же центре данных azure.</li> <li>шлюз приложений работает на прикладном уровне (уровень 7 в сетевом эталонном стеке osi). он действует как служба обратного прокси-сервера, разрывая клиентское соединение и перенаправляя запросы на конечные точки сервера.</li> </ul> </blockquote><p>таким образом, application gateway дополнительно поддерживает <a href="https://docs.microsoft.com/en-us/azure/application-gateway/application-gateway-ssl-portal">завершение ssl</a> , <a href="https://docs.microsoft.com/en-us/azure/application-gateway/application-gateway-backend-ssl">сквозное ssl</a> и <a href="https://docs.microsoft.com/en-us/azure/application-gateway/application-gateway-create-url-route-portal">маршрутизация на основе url</a> , что делает его хорошим кандидатом для приложений service fabric, которые есть внешние клиенты.</p>

<p>при условии, что путь уже пройден, дополнительные компромиссы стали для меня реальностью только при физической реализации.</p><p>если вы не используете обратный прокси-сервер, то добавление других сервисов в кластер и возможность дифференцировать запросы к ним становится невероятно дорогим упражнением.</p><p>рассмотрите стоимость добавления новых pip, правил наттинга балансировщика нагрузки, правил брандмауэра (если используется nva) и содержащихся в них правил наттинга.</p><p>другими словами, без rp, я говорю, что вы фактически получаете взаимно-однозначное отношение между внешним ip-адресом и службой на узле, что проявляется в жестком кодировании маршрута от точки к точке.</p><p>с помощью обратного прокси-сервера, такого как traefic, вы можете использовать обнаружение служб для развертывания и создания активных служб с гораздо меньшей конфигурацией. значительная экономия времени, сил и денег. при реализации rp я буду обновлять ответ снова.</p>