6

我敢肯定，这是一个很长的问题，并且需要权衡取舍。该领域的文档：

没有给我足够的自信来回答上面的问题。

因此，他们说：“Azure 应用程序网关 (AG) 尝试再次解析服务地址，并在无法访问服务时重试请求”。

我知道 Service Fabric 反向代理 (RP) 如何通过封装解析循环来做到这一点。AG也有这个能力吗？总而言之，AG 也是一个反向代理。

因此，对于进入 SF 集群的外部流量至关重要，我为什么要使用一个而不是另一个（我知道 RP 也允许集群内通信，这是一个很好的选择）。

4

3 回答 3

5

好吧，对于进入集群的外部流量，您将获得开箱即用的 Azure 负载均衡器/反向代理组合。但是否足够是另一个问题。我们做出了同样的决定，我们最终使用了应用程序网关。

本文档概述了 Azure 负载均衡器和应用程序网关之间的区别。

一些要点：

  • Azure 负载均衡器在传输层（OSI 网络参考堆栈中的第 4 层）工作。它提供跨在同一 Azure 数据中心中运行的应用程序实例的网络级流量分布。
  • 应用程序网关工作在应用程序层（OSI 网络参考堆栈中的第 7 层）。它充当反向代理服务，终止客户端连接并将请求转发到后端端点。

因此，应用程序网关还支持SSL 终止、SSL 端到端和基于 URL 的路由，这使其成为具有外部客户端的 Service Fabric 应用程序的理想选择。

于 2017-07-22T11:41:34.970 回答
1

给定一条很好的路径，只有在我亲眼目睹它的实现时，额外的权衡才变得明显和真实。

如果您不使用反向代理，则在集群中添加其他服务并能够区分对它们的请求将成为一项非常昂贵的工作。

考虑添加新 PIP（Azure 中的永久 IP）、负载均衡器的 NAT 规则、防火墙规则（如果使用 NVA）和其中包含的 NAT 规则以提供进入 API 的路由的成本。如果所有这些都设置为允许访问您的 RP，那么在您的 RP 后面添加服务/API 应该是一项相对简单的任务

换句话说，如果没有 RP，我是说您实际上最终在外部 IP 地址和节点上的服务之间建立了一对一的关系，这通过硬编码从点到点的路由来表现出来。

使用像 traefik 这样的反向代理，您可以使用服务发现来部署和创建活动服务，而配置要少得多。显着节省时间、精力和金钱。实施 RP 时，我将再次更新答案。

于 2018-04-10T17:30:29.950 回答
-1

我可以告诉你为什么你可能不想使用反向代理。

当您在负载均衡器中配置反向代理的端口时，集群中所有暴露 HTTP 端点的微服务都可以从集群外部寻址。

如果您有任何不想暴露给外界的服务，那么您可能不想使用反向代理。

于 2017-07-25T15:04:41.797 回答