1

我正在将一个大型应用程序分解为多个进程，并且我希望每个进程能够相互通信。

现在它将在同一台服务器上，但稍后同一本地网络上的几台服务器将有几个需要相互通信的进程。（表示在一台服务器上提供服务，在同一 vpc 上的另一台服务器上提供服务）

所以..我的原始选项是tcpor unix sockets。我知道只有在同一台服务器上，Unix 套接字才有用。但是我们正在考虑编写自己的实现，在同一服务器上的进程将在 unix 套接字上进行通信，以及在使用 tcp 进行通信的服务器之间进行通信。

这值得么 ？当然 tcp 套接字比 unix 套接字要慢..因为它不通过网络并且不被 tcp 相关数据包裹。问题是多少？我找不到 tcp 和 unix 套接字之间基准测试的在线证明。如果 tcp 增加了 3%-5% 的开销，那很酷，但它可以更多吗？我想从其他人多年来的大项目经验中学习，但没有发现任何相关的东西。

下一个...

我们的项目是一个NodejS项目。

有些人可能会说我可以使用代理来处理消息，所以我尝试使用nats.io与 node-ipc ( https://www.npmjs.com/package/node-ipc ) 相比，我发现 node-ipc 是 4 倍速度更快，但 nats 具有很酷的发布-订阅功能……但性能很重要。

所以我有很多选择，没有具体的决定。

任何有关该问题的信息将不胜感激。

4

1 回答 1

2

这个问题实际上太广泛了，无法回答，但是 TCP 与 unix 域套接字的一个答案：

构建您的代码，以便您可以在必要时轻松地在这些代码之间移动。它们的编程模型基本相同（都是双向数据流），操作系统级别以及大多数框架中的读/写 API 都是相同的。这意味着例如在节点中，两者都将继承自 Readable/WriteableStream 接口。这意味着您需要更改以在它们之间切换的唯一代码是服务器端的侦听器，您在其中调用 TCP 接受 API 而不是 unix 域套接字接受 API，反之亦然。您甚至可以让您的应用程序接受这两种类型的连接，然后在内部以相同的方式处理它们。

TCP 支持总是很好，因为它为您提供了一些灵活性。在我上次的测量中，开销有点多（我认为 30% 与 TCP over loopback 相比），但这些都是微基准，对于大多数应用程序来说并不重要。如果 Unix 域套接字需要它们的一些特殊功能，例如通过它们发送文件描述符的能力，那么它们可能具有优势。

关于 TCP 与 NATS & Co：如果您对网络编程和协议设计没有那么丰富的经验，那么使用现成的 IPC 系统是有意义的。这可能是从 HTTP 到 gRPC 再到 Thrift 的任何东西。这些都是点对点系统。NATS 不同，因为它是消息代理而不是 RPC。它还需要一个额外的中间组件。这是否有意义完全取决于应用程序。

于 2017-01-05T21:34:29.560 回答