我敢肯定，这是一个很长的问题，需要权衡取舍。这个area中的文档：
没有足以让我自信地回答上述问题。
所以，他们说： “Azure 应用程序网关 (AG) 尝试再次解析服务地址并在无法访问服务时重试请求”。
我知道 Service Fabric 反向代理 (RP) 如何通过封装解析循环来做到这一点。 AG也有这个能力吗？总而言之，AG 也是一个反向代理。
因此，对于进入 SF 集群的外部流量至关重要，我为什么要使用一个而不是另一个（我知道 RP 也允许集群内通信，这是一个很好的选择）。
【问题讨论】：
标签： azure reverse-proxy azure-service-fabric azure-application-gateway
嗯，对于进入集群的外部流量，您将获得开箱即用的 Azure 负载均衡器/反向代理组合。但是否足够是另一个问题。我们做出了同样的决定，我们最终使用了应用程序网关。
this 文档中概述了 Azure 负载均衡器和应用程序网关之间的区别。
一些要点：
- Azure 负载均衡器在传输层（OSI 网络参考堆栈中的第 4 层）工作。它提供跨在同一 Azure 数据中心中运行的应用程序实例的网络级流量分布。
- 应用程序网关工作在应用程序层（OSI 网络参考堆栈中的第 7 层）。它充当反向代理服务，终止客户端连接并将请求转发到后端端点。
因此，应用程序网关还支持 SSL termination、SSL end to end 和 URL-based routing，这使其成为具有外部客户端的 Service Fabric 应用程序的理想选择。
【讨论】：
鉴于一条已被广泛践行的道路，只有在我亲眼目睹它的实施时，额外的权衡才对我来说变得显而易见和真实。
如果您不使用反向代理，那么在集群中添加其他服务并能够区分对它们的请求将变得非常昂贵。
考虑添加新 PIP（Azure 中的永久 IP）、负载平衡器的 NAT 规则、防火墙规则（如果使用 NVA）和其中包含的 NAT 规则以提供进入 API 的路由的成本。如果所有这些都设置为允许访问您的 RP，那么在您的 RP 后面添加服务/API 应该是一项相对简单的任务
换句话说，如果没有 RP，我是说您实际上最终会在外部 IP 地址和节点上的服务之间建立一对一的关系，这通过硬编码从点到点的路由来体现。
使用像 traefik 这样的反向代理，您可以使用服务发现来部署和创建活动服务，而配置要少得多。显着节省时间、精力和金钱。在实施 RP 时，我将再次更新答案。
【讨论】：
我可以告诉你为什么你可能不想使用反向代理。
当您在负载均衡器中配置反向代理的端口时，集群中所有暴露 HTTP 端点的微服务都可以从集群外部寻址。
如果您有任何服务不想暴露给外界，那么您可能不想使用反向代理。
【讨论】：