有趣的是创建一个新的节点应用程序来处理socket.io？

Question

我想在一个现有的项目上添加一些带有nodeJs和Socket.io的套接字。 我已经有2台服务器了：

• 用于存储和管理我的数据的API RESTful Web服务。
• 用于返回HTML，资源（js，css，images，...）
的公共Web服务

第一次尝试时，我在Public上创建了socket服务器。但我认为如果我创建另一个只处理套接字查询会更好。

你怎么看？这是一个好主意，或者只是一个无用的人会添加更多的问题而不是解决（可能是重复的实习生，...）

另外，我正在使用令牌在Public和API之间进行通信，我是否必须在socket和API之间创建另一个通信？或者我可以使用同一个？

------ [编辑] ------

由于没有人不理解我，我已经用我正在考虑的基础设施创建了一个模式。

1. 这是一个很好的方法吗？
2. 公共服务器和套接字服务器必须相同？或者可以分开？
3. 我是否必须为连接的每个客户端在API和Socket服务器之间创建套接字连接？



谢谢！

Answer 1

感谢您更好地解释。

首先，虽然这看似合理，但这种使用Socket.io的方式并不是最常见的方式。使用Socket.io的最大优点是它可以为双向通信保持一个通道。这样做的主要优点是服务器本身可以向客户端发送消息，而后者不必定期轮询 例如，考虑一下邮件客户端。没有套接字，浏览器必须定期轮询以检查新邮件。相反，只要有新邮件，服务器就会立即通知客户端。

在您的情况下，好处可能是有限的，我不确定Socket.io服务器的额外复杂性（和成本！）真的值得在REST请求上适度的速度改进。但是，最后由你决定。

回答您的观点

1. 见上文
2. 如果未在Node.js中写入“公共服务器”，则它们不能是同一个应用程序。如果它们位于同一台服务器上，则取决于您和您的预算。理想情况下，它们应该是分开的，以适应更大的工作量。

3. 如果您只是希望套接字服务器充当实时代理，那么是的，您必须为每个请求创建套接字连接。这将如何工作：

   1. 客户端向Socket.io服务器请求资源。
   2. Socket.io服务器向API服务器发出正常的HTTP请求（例如，使用request）
   3. 通过套接字连接将响应返回给客户端

＃3中表示的工作流程是您应该只期望中等性能提升的原因。实际上，您将获得更好的延迟，但启动HTTP请求的大部分开销仍然存在！