ASP.NET Blazor 在 Azure Container Apps 中的 WebSocket 连接问题解析

问题背景

在将 ASP.NET Blazor 交互式服务器应用部署到 Azure Container Apps (ACA) 时，开发者遇到了一个棘手的连接问题。当用户频繁刷新页面时，应用会随机出现 WebSocket 连接失败的情况，错误信息显示无法在服务器上找到连接端点。

问题现象

具体表现为：

• 部署到 ACA 后，页面刷新时随机出现连接失败
• 错误信息提示 WebSocket 无法连接，可能是端点不存在或代理阻止了 WebSocket
• 本地 Docker 环境中无法复现该问题
• 错误发生时，控制台会显示 SignalR 传输层启动失败

根本原因分析

经过深入排查，发现这个问题与 Azure Container Apps 的负载均衡配置有关。虽然应用只部署了一个副本，但 ACA 的基础架构仍然可能将请求分发到不同的后端实例。在没有启用会话亲和性（Session Affinity）的情况下，连续的 WebSocket 连接请求可能被路由到不同的实例，导致连接失败。

解决方案

通过以下配置调整可以解决此问题：

1. 启用会话亲和性：

   • 在 ACA 的入口设置中，勾选"会话亲和性"选项
   • 这确保了来自同一客户端的后续请求会被路由到同一个后端实例

2. 协议选择：

   • 确保选择了 HTTP/1 协议
   • 虽然 HTTP/2 也支持 WebSocket，但在 ACA 环境中 HTTP/1 表现更稳定

3. 健康检查配置：

   • 按照 Aspire 文档正确配置健康检查端点
   • 这有助于 ACA 正确识别和维护应用实例的健康状态

深入技术细节

Blazor 交互式服务器应用依赖于 SignalR 进行实时通信，而 SignalR 默认会尝试使用 WebSocket 作为首选传输协议。在分布式环境中，SignalR 需要会话亲和性来确保连接状态的一致性。

即使只有一个应用副本，ACA 的基础架构仍然可能包含多个前端代理节点。这些节点在没有会话亲和性的情况下，可能会将连续的 WebSocket 握手请求分发到不同的路径，导致连接失败。

最佳实践建议

对于生产环境部署，建议：

1. 始终启用会话亲和性，即使当前只有一个副本
2. 考虑未来扩展性，设计支持多实例的架构
3. 监控 WebSocket 连接成功率指标
4. 实施适当的连接重试策略客户端

总结

Azure Container Apps 为 Blazor 应用提供了便捷的部署平台，但需要特别注意其网络层特性。通过正确配置会话亲和性和协议选择，可以确保 SignalR 和 WebSocket 连接的稳定性。这个问题也提醒我们，在云原生环境中部署实时应用时，理解底层基础设施的行为至关重要。