为什么我应该使用 Service Fabric 反向代理而不是 Azure App Gateway 来与 SF 集群通信？
Why should I use the Service Fabric Reverse Proxy instead of the Azure App Gateway to talk to SF Cluster?
这是一个很长的问题，并且需要权衡取舍，我敢肯定。此 area 中的文档：
不足以让我自信地回答上述问题。
所以，他们说：
"Azure Application Gateway (AG) attempts to resolve a service address again and retry the request when a service cannot be reached"。
我知道 Service Fabric 反向代理 (RP) 如何通过封装解析循环来实现这一点。 AG也有这个能力吗？从各方面来看，AG 也是一个反向代理。
因此，对于进入 SF 集群的 外部 流量至关重要，为什么我要使用一个而不是另一个（我知道 RP 也允许集群内通信，这是一个很合身）。
好吧，对于进入集群的外部流量，您将获得开箱即用的 Azure 负载均衡器/反向代理组合。但是否足够是另一个问题。我们做出了同样的决定，我们最终使用了应用程序网关。
this 文档中概述了 Azure 负载均衡器和应用程序网关之间的区别。
一些要点：
- Azure Load Balancer works at the transport layer (Layer 4 in the OSI network reference stack). It provides network-level distribution of traffic across instances of an application running in the same Azure data center.
- Application Gateway works at the application layer (Layer 7 in the OSI network reference stack). It acts as a reverse-proxy service, terminating the client connection and forwarding requests to back-end endpoints.
因此，应用程序网关还支持 SSL termination, SSL end to end and URL-based routing，这使其成为具有外部客户端的 Service Fabric 应用程序的理想选择。
我可以告诉你为什么你可能不想使用反向代理。
When you configure the reverse proxy's port in Load Balancer, all microservices in the cluster that expose an HTTP endpoint are addressable from outside the cluster.
如果您有任何不想暴露给外界的服务，那么您可能不想使用反向代理。
考虑到一条经过良好实践的路径，当我实际目睹它实施时，额外的权衡对我来说才变得明显和真实。
如果您不使用反向代理，在您的集群中添加其他服务并能够区分对它们的请求将成为一项非常昂贵的工作。
考虑添加新 PIP（Azure 中的永久 IP）、负载均衡器的 NATting 规则、防火墙规则（如果使用 NVA）和其中包含的 NATting 规则以提供进入 API 的路由的成本。如果所有这些都设置为允许访问您的 RP，那么在您的 RP 后面添加 services/APIs 应该是一个相对简单的任务
换句话说，如果没有 RP，我是说您实际上最终在外部 IP 地址和节点上的服务之间建立了一对一的关系，该节点通过对点到点的路由进行硬编码来体现。
借助像 traefik 这样的反向代理，您可以使用服务发现来部署和创建活动服务，而配置要少得多。显着节省时间、精力和金钱。实施RP时我会再次更新答案。
这是一个很长的问题，并且需要权衡取舍，我敢肯定。此 area 中的文档：
不足以让我自信地回答上述问题。
所以，他们说： "Azure Application Gateway (AG) attempts to resolve a service address again and retry the request when a service cannot be reached"。
我知道 Service Fabric 反向代理 (RP) 如何通过封装解析循环来实现这一点。 AG也有这个能力吗？从各方面来看，AG 也是一个反向代理。
因此，对于进入 SF 集群的 外部 流量至关重要，为什么我要使用一个而不是另一个（我知道 RP 也允许集群内通信，这是一个很合身）。
好吧，对于进入集群的外部流量，您将获得开箱即用的 Azure 负载均衡器/反向代理组合。但是否足够是另一个问题。我们做出了同样的决定，我们最终使用了应用程序网关。
this 文档中概述了 Azure 负载均衡器和应用程序网关之间的区别。
一些要点：
- Azure Load Balancer works at the transport layer (Layer 4 in the OSI network reference stack). It provides network-level distribution of traffic across instances of an application running in the same Azure data center.
- Application Gateway works at the application layer (Layer 7 in the OSI network reference stack). It acts as a reverse-proxy service, terminating the client connection and forwarding requests to back-end endpoints.
因此，应用程序网关还支持 SSL termination, SSL end to end and URL-based routing，这使其成为具有外部客户端的 Service Fabric 应用程序的理想选择。
我可以告诉你为什么你可能不想使用反向代理。
When you configure the reverse proxy's port in Load Balancer, all microservices in the cluster that expose an HTTP endpoint are addressable from outside the cluster.
如果您有任何不想暴露给外界的服务，那么您可能不想使用反向代理。
考虑到一条经过良好实践的路径，当我实际目睹它实施时，额外的权衡对我来说才变得明显和真实。
如果您不使用反向代理，在您的集群中添加其他服务并能够区分对它们的请求将成为一项非常昂贵的工作。
考虑添加新 PIP（Azure 中的永久 IP）、负载均衡器的 NATting 规则、防火墙规则（如果使用 NVA）和其中包含的 NATting 规则以提供进入 API 的路由的成本。如果所有这些都设置为允许访问您的 RP，那么在您的 RP 后面添加 services/APIs 应该是一个相对简单的任务
换句话说，如果没有 RP，我是说您实际上最终在外部 IP 地址和节点上的服务之间建立了一对一的关系，该节点通过对点到点的路由进行硬编码来体现。
借助像 traefik 这样的反向代理，您可以使用服务发现来部署和创建活动服务，而配置要少得多。显着节省时间、精力和金钱。实施RP时我会再次更新答案。