Service Fabric负载平衡超时

Question

我有两个.net核心webapi应用（appA和appB），在三个服务结构节点（node1，node2和node3）中运行了dockerized。服务结构通过负载平衡器在Azure中运行。

当我有外界的要求时，效果很好。

当我有从appA到appB的内部请求时，从node1到node2的请求也很好。

但是，当负载均衡器决定将请求从appA路由到同一节点中的appB时，出现了超时。例如：

从外部到节点1内部的appA的请求，因此appA要求负载平衡器访问appB。负载平衡器将请求路由到node1（同一原始节点）。然后我超时了。

“有问题的”流程：

来自网络的请求-> 负载均衡器-> node1 -> appA （此时，应用将需要来自其他服务的信息）-> 负载平衡器（这似乎超时了）-> node1 -> appB 。

有人遇到同样的问题或类似的问题吗？

Answer 1

这是因为顾名思义，Azure LoadBalancer会将传入的负载拆分到其后面的节点（VM）之间，在您的情况下，您在负载均衡器后面有3个节点（VM），并且到负载均衡器的每个连接都会被转发到一个节点（VM）。

解决此问题的最简单方法是通过Service Fabric反向代理进行请求，启用后，反向代理将在所有节点上可用，因此通过LB的每个请求都将在其中找到RP（反向代理）。节点。反向代理将处理在群集中查找容器的工作，无论它们在同一节点还是在另一个节点上都是无关紧要的。

最后，外部客户端将发出类似以下内容的请求：

http://{sf-cluster-fqdn}:19081/DockerSFAppName/ContainerName/<any-path-inside-your-container>

请查看文档here

如果您不想提供ApplicationName和Container名称来访问您的容器，则可以使用以下选项：

• 使用另一个反向代理引擎，例如建议的@ 4c74356b41，并手动配置它以转发到您的容器或将其转换为集群内部的反向代理调用。我的建议是traefik
• 使用转发请求所需的规则构建自己的ReverseProxy
• 将每个容器的一个实例部署到每个节点，这不是理想选择，而是一种选择

Answer 2

这是一个已知的限制，节点无法使用负载平衡器与其自身对话。唯一可行的解​​决方法是使用某些代理（如nginx）来处理该问题。这样您的流量就会这样：

appA - nginx - load balancer - appb

或者，您可以使用应用程序网关（PaaS产品）