http - 用于后台处理的 Websockets

Question

使用 Websockets(comet、服务器推送等)来克服长时间运行的 HTTP 请求的问题是个好主意吗？想象一下，你有一个应用程序，构建在全栈网络应用程序框架上，比如 Django 或 Rails。您想以性能的名义进行一些后台处理。从程序员的角度来看，这很容易做到，但问题出现在 UI 中。

用户要求立即响应。所以我的想法是使用 Socket.IO + node.js + AMQP 消息，在后台任务完成后将通知推送回浏览器。我喜欢这个想法，但它仍然感觉像很多工程，只是因为我们不想在我们的主应用程序中长时间运行请求。竞争的想法可能是使用另一个更强大的 Web 服务器，它可以处理许多长时间运行的 HTTP 请求。

你觉得哪个更好？

Answer 1

Is it a good idea to use Websockets to overcome a problem with long running HTTP requests?

是的。与其他技术(例如连续或长轮询)相比，您可以节省大量数据。试着看看this article ，即Step 3部分。

I like the idea, but it still feels like lots of engineering, just because we don't want to long running requests in our main app. Competing idea could be to use another, more robust, web server, that can handle many long running HTTP requests.

Socket.io 为您抽象传输层和后备解决方案(在没有 websockets 的情况下)。如果您只想将 socket.io/node.js/AMPQ 堆栈用于消息传递和通知，那么它不应该是一个复杂或耗时的开发过程，但是它可能取决于周围的各种东西。

通过将消息传递/通知委托(delegate)给 node.js，由于其非阻塞架构，您可能会在很大程度上减轻主应用程序的负担，尽管您会引入对其他技术的依赖。

另一方面，选择性能更高的 Web 服务器可能会在一段时间内解决您的性能问题，但您最终可能会扩展系统(向上或向下)。