我将一个大型应用程序分成几个进程，我希望每个进程能够相互通信。
现在它将在同一台服务器上，但稍后同一本地网络上的多台服务器将有多个进程需要相互通信。 (表示在一台服务器上提供服务，在同一 vpc 上的其他服务器上提供服务)
所以.. 我的原始选项是 tcp 或 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 具有很酷的发布 - 订阅功能......但性能很重要。
所以我有很多选择，没有具体的决定。
如能提供有关此问题的任何信息，我们将不胜感激。
最佳答案
这个问题实际上太宽泛而无法回答，但 TCP 与 unix 域套接字的一个答案是:
构建您的代码，以便您可以在必要时轻松地在这些代码之间移动。这些的编程模型基本相同(都是双向数据流)，并且操作系统级别和大多数框架中的读/写 API 是相同的。这意味着例如在 Node 中，两者都将继承自 Readable/WriteableStream 接口(interface)。这意味着您需要更改的唯一代码是在服务器端的监听器，您在服务器端调用 TCP 接受 API 而不是 unix 域套接字接受 API，反之亦然。您甚至可以让您的应用程序接受两种类型的连接，然后在内部以相同的方式处理它们。
TCP 支持总是很好，因为它给了你一些灵 active 。在我上次的测量中，开销稍微多了一点(我认为 30% 与 TCP over loopback 相比)，但这些都是微观基准，对大多数应用程序来说都无关紧要。如果需要某些特殊功能，例如 Unix 域套接字，可能会有优势。在它们之间发送文件描述符的能力。
关于 TCP 与 NATS & Co: 如果您在网络编程和协议(protocol)设计方面没有那么丰富的经验，那么使用现成的 IPC 系统是有意义的。这可能是从 HTTP 到 gRPC 再到 Thrift 的任何东西。这些都是点对点系统。 NATS 不同，因为它是消息代理而不是 RPC。它还需要在中间有一个额外的组件。这是否有意义完全取决于应用。
关于node.js - 进程之间的通信 : tcp vs unix sockets, ipc vs nats，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/41447064/