node.js - 既提供 rest-api 又处理网络套接字的 node.js 应用程序是个好主意吗？

Question

免责声明:我是 node.js 的新手，所以如果这是一个奇怪的问题，我很抱歉 :)

我有一个使用 express.js 来提供 REST-API 服务的 node.js。 REST-API 提供的数据由 node.js 应用程序从 nosql 数据库中获取。所有客户端仅使用 HTTP-GET。但是有一个异常(exception):数据是从主数据库(另一台服务器上的关系数据库)中放置和删除的。这种设置的想法当然是让“node.js/nosql 数据库”服务器成为公共(public)前端，从而保护主数据库免受繁忙流量的影响。

许多不同的客户端应用程序可能会使用 REST-API，但主要由生命周期较长(通常为 0.5 到 2 小时)的客户端应用程序使用。我不想让这个应用程序不断轮询 REST-API 以获取可能的新数据，而是想使用 websockets，以便仅在有任何新数据时才将数据发送到客户端。我将为此使用 node.js 应用程序，可能还会使用 socket.io，这样如果客户端不支持 websockets，它就可以回退到 api-polling。每次主数据库在 nosql 数据库中 PUT 或 DELETE 对象时，都应向客户端发送新数据。

问题是我是应该为 API 和 websockets 使用一个 node.js，还是为 API 和 websockets 使用一个。

需要考虑的事项:- 性能:应用程序将托管在一个服务器集群上，前面有一个负载平衡器和一个 HTTP 加速器。一个应用程序处理所有事情会比两个具有不同任务的应用程序表现更好吗？- 应用程序之间的流量:如果我选择双应用程序解决方案，则从主数据库接收 PUT 和 DELETE 的 api 应用程序每次接收新数据时都必须通知 websocket 应用程序(或者主数据库必须通知两个应用程序)。翻倍的流量可能是性能问题吗？- 代码简洁:我相信两个应用程序会产生更干净和更好的代码，但话又说回来，这两个应用程序肯定会有一些通用代码，这将导致它有两个副本。

至于负载有多大很难说，但可能的峰值可能涉及:50000个客户每个收听最多 5 个不同的 channel 每 5 秒从主机发送一次新数据新数据应该发送给大约 25% 的客户端(对于某些数据，它应该发送给所有客户端，而其他数据可能低于 1% 的客户端)

更新:谢谢你们的回答。更多的思想食物在这里。我决定拥有两个 node.js 应用程序，一个用于 REST-API，一个用于 Web 套接字。原因是我相信扩展它们会更容易。首先，整个系统将托管在三台物理服务器上，每台服务器上的 REST-API 一个 node.js 应用程序应该足够了，但对于 websocket 应用程序，可能需要在每台物理服务器上有多个实例。

Answer 1

这是一个很好的问题。

如果您正在查看遗留系统，并且已经定义了 REST 接口(interface)，那么添加 WebSockets 并没有太多优势。可能将您指向 WebSockets 的事情是:

• 对服务器到客户端或客户端到客户端实时数据的需求
• 需要使用经典的双向协议(protocol)与服务器组件集成(例如，您想用 javascript 编写 FTP 或 sendmail 客户端)。

如果您要开始一个新项目，我会尝试在项目之间进行严格划分:

• 使用 HTTP 提供静态内容(图像、js、css)(这是它的设计目的)和

• 使用 WebSocket 提供动态内容(实时数据)(负载均衡、基于订阅/消息传递、启用自动重新连接以处理网络故障)。

那么，我们为什么要尝试硬分离呢？让我们考虑一下基于 HTTP 的 REST 协议(protocol)的优势。

REST语义使用HTTP协议(protocol)是一项具有一定优势的发明

• 无状态交互:客户端的上下文不会在请求之间存储在服务器端。
• 可缓存:客户端可以缓存响应。
• 分层系统:中介不可检测
• 轻松测试:使用 curl 测试基于 HTTP 的协议(protocol)很容易

另一方面...

在 WebSockets 之上使用消息传递协议(protocol)(例如 AMQP、JMS/STOMP)并不排除任何这些优势。

• WebSocket 可以透明地进行负载平衡，可以缓存消息和状态，可以定义高效的有状态或无状态交互。

• 基本的响应式(Reactive)分析风格可以定义哪些事件触发客户端和服务器之间的哪些消息。

主要的附加优势是:

• WebSocket 旨在成为长期持久连接，可用于通过单个连接实现多种不同的消息传递目的

• WebSocket 连接允许完全双向通信，允许根据网络特性在任一方向发送数据。

• 可以使用连接卸载来使用中介共享对公共(public)主题的订阅。这意味着只需很少的核心消息代理连接，您就可以大规模高效地为数百万连接的用户提供服务。

• 监控和测试可以通过管理界面来实现，以发送/接收消息(随所有消息代理一起提供)。

• 这一切的代价是，当WebSocket掉线后需要重新连接时，需要处理重新建立状态的问题。许多协议(protocol)设计者构建了“同步”消息的概念，以提供从服务器到客户端的上下文。

无论哪种方式，无论您使用 REST 还是 WebSockets，您的模型对象可能都是相同的，但这可能意味着您仍然在请求-响应而不是发布/订阅方面考虑太多。