使用 Websockets（彗星、服务器推送等）来解决长时间运行的 HTTP 请求的问题是个好主意吗？想象一下，您有一个应用程序，构建在全栈 Web 应用程序框架上，例如 Django 或 Rails。你想以性能的名义做一些后台处理。从程序员的角度来看，这很容易做到，但问题出现在 UI 中。
用户要求立即响应。所以我的想法是使用 Socket.IO + node.js + AMQP 消息传递，在后台任务完成后将通知推送回浏览器。我喜欢这个想法，但它仍然感觉像很多工程，只是因为我们不想在我们的主应用程序中长时间运行请求。竞争的想法可能是使用另一个更强大的 Web 服务器，它可以处理许多长时间运行的 HTTP 请求。
你觉得哪个更好？
【问题讨论】：
标签： http node.js backgroundworker websocket
使用 Websockets 是个好主意吗？ 解决长时间运行的 HTTP 请求的问题？
是的。与其他技术（例如连续或长轮询）相比，您可以节省大量数据。试试看this article，即Step 3部分。
我喜欢这个想法，但它仍然感觉像很多工程，只是 因为我们不想在我们的主应用程序中长时间运行请求。 竞争的想法可能是使用另一个更强大的 Web 服务器， 可以处理许多长时间运行的 HTTP 请求。
Socket.io 为您抽象传输层和后备解决方案（如果没有 websockets）。如果您只想将 socket.io/node.js/AMPQ 堆栈用于消息传递和通知，那么它不应该是一个复杂或耗时的开发过程，但它可能取决于周围的各种东西。
通过将消息传递/通知委托给 node.js，您可能会在很大程度上减轻您的主应用程序的负担，这要归功于它的非阻塞架构，尽管您会引入对另一种技术的依赖。
另一方面，选择性能更高的 Web 服务器可能会在一段时间内解决您的性能问题，但您最终可能会扩展您的系统（向上或向外）。
【讨论】：
WebSockets 本身在这里提供的很少，例如XHR 或 jsonp 长轮询。从用户的角度来看，通过任何一种传输方式发送消息的感觉都是一样的。从服务器的角度来看，打开的 WebSocket 连接或打开的长轮询并没有剧烈不同。
无论底层技术如何，您真正在做并且应该做的是将您的应用程序构建为异步的 - 事件驱动的。
【讨论】：