Service Fabric 负载平衡超时
Service Fabric load balance timeout
我有两个 .net 核心 webapi 应用程序（appA 和 appB），dockerized，运行 在三个服务结构节点（node1、node2 和 node3）中。服务结构在带有负载均衡器的 Azure 中 运行。
当我有来自外部的请求时效果很好。
当我有一个从 appA 到 appB 的内部请求时，跨节点 1 到节点 2，效果也很好。
但似乎当负载均衡器决定将请求从 appA 路由到同一节点中的 appB 时，我遇到了超时。例如：
从外部请求到node1内部的appA，所以appA请求负载均衡器访问appB。负载均衡器将请求路由到 node1（同源节点）。然后我超时了。
"problematic" 流程：
来自 web 的请求 -> 负载均衡器 -> node1 -> appA（此时，应用程序将需要来自其他服务的信息）-> 负载均衡器（这里似乎超时了）-> node1 -> appB.
是否有人面临同样的问题或类似问题？
这是一个已知的限制，节点无法使用负载平衡器与自己对话。唯一真正的解决方法是使用像 nginx 这样的代理来处理它。所以你的流量会是这样的：
appA - nginx - load balancer - appb
或者您可以使用应用程序网关（PaaS 产品）
这是因为 Azure LoadBalancer，顾名思义，在它后面的节点 (VM) 之间拆分传入负载，在您的情况下，负载均衡器后面有 3 个节点 (VM)，每个连接到一个负载平衡器将被转发到一个节点（VM）。
解决此问题最简单的方法是通过 Service Fabric 反向代理发出请求，启用后，反向代理将在所有节点上可用，因此通过 LB 的每个请求都会找到一个 RP（反向代理) 在节点中。反向代理将处理在您的集群中查找容器的工作，无论它们是在同一个节点还是另一个节点上。
最后，外部客户端会发出这样的请求：
http://{sf-cluster-fqdn}:19081/DockerSFAppName/ContainerName/<any-path-inside-your-container>
请查看文档here
如果您不想提供应用程序名称和容器名称来访问您的容器，您有以下选择：
- 使用另一个反向代理引擎，如建议的@4c74356b41 并手动配置它以转发到您的容器或将其转换为集群内的反向代理调用。我的建议是 traefik
- 构建您自己的 ReverseProxy，使用转发请求所需的规则
- 将每个容器的一个实例部署到每个节点，不理想，但一个选项
我有两个 .net 核心 webapi 应用程序（appA 和 appB），dockerized，运行 在三个服务结构节点（node1、node2 和 node3）中。服务结构在带有负载均衡器的 Azure 中 运行。
当我有来自外部的请求时效果很好。
当我有一个从 appA 到 appB 的内部请求时，跨节点 1 到节点 2，效果也很好。
但似乎当负载均衡器决定将请求从 appA 路由到同一节点中的 appB 时，我遇到了超时。例如：
从外部请求到node1内部的appA，所以appA请求负载均衡器访问appB。负载均衡器将请求路由到 node1（同源节点）。然后我超时了。
"problematic" 流程：
来自 web 的请求 -> 负载均衡器 -> node1 -> appA（此时，应用程序将需要来自其他服务的信息）-> 负载均衡器（这里似乎超时了）-> node1 -> appB.
是否有人面临同样的问题或类似问题？
这是一个已知的限制，节点无法使用负载平衡器与自己对话。唯一真正的解决方法是使用像 nginx 这样的代理来处理它。所以你的流量会是这样的：
appA - nginx - load balancer - appb
或者您可以使用应用程序网关（PaaS 产品）
这是因为 Azure LoadBalancer，顾名思义，在它后面的节点 (VM) 之间拆分传入负载，在您的情况下，负载均衡器后面有 3 个节点 (VM)，每个连接到一个负载平衡器将被转发到一个节点（VM）。
解决此问题最简单的方法是通过 Service Fabric 反向代理发出请求，启用后，反向代理将在所有节点上可用，因此通过 LB 的每个请求都会找到一个 RP（反向代理) 在节点中。反向代理将处理在您的集群中查找容器的工作，无论它们是在同一个节点还是另一个节点上。
最后，外部客户端会发出这样的请求：
http://{sf-cluster-fqdn}:19081/DockerSFAppName/ContainerName/<any-path-inside-your-container>
请查看文档here
如果您不想提供应用程序名称和容器名称来访问您的容器，您有以下选择：
- 使用另一个反向代理引擎，如建议的@4c74356b41 并手动配置它以转发到您的容器或将其转换为集群内的反向代理调用。我的建议是 traefik
- 构建您自己的 ReverseProxy，使用转发请求所需的规则
- 将每个容器的一个实例部署到每个节点，不理想，但一个选项