Azure Service Fabric 上的 Signalr 问题：WebSocket 握手期间出错答案

【问题标题】：Signalr Issue on Azure Service Fabric: Error during WebSocket handshakeAzure Service Fabric 上的 Signalr 问题：WebSocket 握手期间出错
【发布时间】：2019-05-30 03:26:43
【问题描述】：

我们使用 Service Fabric 来托管我们的消息传递服务 ASP.NET Core Web API（利用信号器）和作为客户端的 React Web 应用程序。一切都在本地机器上按预期工作，但在 Azure 上却不行。我们已经为跨域处理配置了 CORS 策略，因为服务和 Web 应用程序托管在不同的服务器上。在负载均衡器中配置粘性会话。此 CORS 策略适用于本地计算机，服务和客户端托管在不同的端口上。

在 Azure 上托管应用程序后，我在浏览器控制台中收到错误

WebSocket 握手期间出错：意外响应代码：500

【问题讨论】：

您获得 HTTP 500 的事实意味着您的代码中可能在服务器级别发生了未处理的异常。如果您有任何日志或只是在调试中运行该应用程序，请检查日志并尝试查看发生了什么

标签： azure signalr azure-service-fabric

【解决方案1】：

这个问题很可能是因为 CORS 而发生的。

查看您提供的屏幕截图，可以看到 CORS 异常，并且您知道，调用 SignalR 服务的前端应用程序托管在不同的位置（域相同但端口不同）。

您应用的 CORS 设置可能不起作用。

您有两种解决方案：

在 ASP.NET CORE 中配置 CORS，以便 SignalR 可以接受来自其他域的调用。
在同一域 + 端口上托管以避免 CORS

【讨论】：

我已经配置了 CORS 以启用来自其他域的调用；问题仍然存在。我尝试发布与 appservice 相同的服务，它有效。但是，问题在于基于服务结构的托管。目前不能在同一个域+端口上托管服务和客户端。
可能是因为它在反向代理后面运行，然后尝试直接公开 SignalR 服务，就像你为 FE 所做的那样。
进一步尝试其他选项 - 它在托管为应用程序服务和单节点服务结构集群时工作，使用自定义端口并为该端口配置负载均衡器，并具有客户端 IP 会话持久性。有用。但是，问题在于使用相同配置的多节点服务结构集群（用于工作单节点设置）。
鉴于它直接暴露时工作，我们可以确认问题是反向代理，它适用于单个节点，因为负载均衡器只知道一个节点，在多个节点上，负载均衡器将流量发送到每个节点循环方法中该节点类型的节点，在这种情况下，您的应用程序必须在相同节点类型的所有节点上运行才能正常工作。
终于成功了，在清单中添加了placement-constraint和nodetypename，感谢@Diego Mendes的帮助。