Node.js后端+Vue.js客户端下WebSockets与SSE选型咨询

针对你的场景优先选择 Server-Sent Events(SSE)，是投入成本最低、适配性最高的解决方案。

两种技术方案对比 #

SSE适配优势 #

• 功能完全匹配需求：仅需要服务端单向推送创建结果的场景下，SSE天生为服务端单向推送设计，没有冗余能力开销
• 开发成本极低：基于原生HTTP协议实现，无需额外引入专用依赖，前后端都可以用原生API快速开发，现有架构改动量极小
• 代理兼容性更好：走标准HTTPS端口通信，不需要额外配置端口放行，仅需要调整Akamai对应接口的长连接超时阈值即可，比WebSocket的代理适配问题少很多
• 原生自带能力：内置断线自动重连机制，不需要手动实现重连逻辑，网络波动场景下稳定性更高

WebSocket适用场景 #

只有当后续业务除了服务端推送之外，还需要客户端双向实时发送消息（比如实时交互、协同操作类功能）时，才需要考虑WebSocket方案，纯结果推送场景下SSE的性价比远高于WebSocket。

SSE落地实现步骤 #

1. 后端逻辑调整 #

• 客户端提交账号创建请求时，后端直接返回「请求已受理」的响应，同时生成唯一任务ID返回给前端，异步触发第三方API调用，不要同步阻塞等待第三方返回结果
• 新增独立SSE接口，前端携带任务ID调用该接口建立长连接，后端将连接与对应任务ID绑定存储
• 第三方API返回创建结果后，根据任务ID找到对应的SSE连接，推送结果后主动关闭连接即可

2. 前端逻辑调整 #

提交表单拿到任务ID后，初始化SSE连接监听结果即可，示例代码：

// 提交表单拿到taskId后建立SSE连接
const eventSource = new EventSource(`/api/account-create-status?taskId=${返回的任务ID}`)
// 监听服务端推送的消息
eventSource.onmessage = (event) => {
  const createResult = JSON.parse(event.data)
  // 处理创建成功/失败的业务逻辑
  eventSource.close() // 拿到结果后主动关闭连接
}
// 监听连接错误
eventSource.onerror = (err) => {
  // 处理异常场景，比如提示用户或触发轮询兜底
  eventSource.close()
}

3. Akamai配置调整 #

需要在Akamai控制台将对应SSE接口的响应超时时间，从默认的60秒调整为业务允许的最大等待时长（比如120秒），否则长连接还是会被代理主动断开。

额外优化建议 #

• 后端用Redis等存储任务状态，如果SSE连接异常断开，用户刷新页面后可以根据任务ID查询当前创建状态，避免重复提交
• 前端提交表单后直接置灰提交按钮，直到拿到最终结果或超时才放开，从前端层面降低重复提交概率
• 若第三方API最大耗时超过2分钟，可以加前端轮询作为兜底，SSE推送失败时每10秒轮询一次任务状态，最多轮询10次，保证用户能拿到最终结果。

内容的提问来源于stack exchange，提问作者Happy Coder