进程间通信：tcp vs unix sockets，ipc vs nats
communication between processes: tcp vs unix sockets, ipc vs nats
我正在将一个大型应用程序分成几个进程，我希望每个进程能够相互通信。
现在它将在同一台服务器上，但稍后同一本地网络上的多台服务器将有多个进程需要相互通信。 （表示在一台服务器上提供服务，在同一 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 域套接字的一个答案是：
构建您的代码，以便您可以在必要时轻松地在这些代码之间移动。这些的编程模型基本相同（都是双向数据流），OS 级别以及大多数框架中的 read/write API 是相同的。这意味着例如在节点中，两者都将从 Readable/WriteableStream 接口继承。这意味着您需要更改的唯一代码是在服务器端的侦听器，您在服务器端调用 TCP 接受 API 而不是 unix 域套接字接受 API，反之亦然。您甚至可以让您的应用程序接受两种类型的连接，然后在内部以相同的方式处理它们。
TCP 支持总是很好，因为它为您提供了一些灵活性。在我上次的测量中，开销稍微多了一点（我认为 30% 与 TCP over loopback 相比），但这些都是微观基准，对大多数应用程序来说都无关紧要。如果需要某些特殊功能，例如 Unix 域套接字，可能会有优势。在它们之间发送文件描述符的能力。
关于 TCP 与 NATS & Co：
如果您在网络编程和协议设计方面没有那么丰富的经验，那么使用现成的 IPC 系统是有意义的。这可能是从 HTTP 到 gRPC 再到 Thrift 的任何东西。这些都是点对点系统。 NATS 不同，因为它是消息代理而不是 RPC。它还需要在中间有一个额外的组件。这是否有意义完全取决于应用程序。
我正在将一个大型应用程序分成几个进程，我希望每个进程能够相互通信。
现在它将在同一台服务器上，但稍后同一本地网络上的多台服务器将有多个进程需要相互通信。 （表示在一台服务器上提供服务，在同一 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 域套接字的一个答案是：
构建您的代码，以便您可以在必要时轻松地在这些代码之间移动。这些的编程模型基本相同（都是双向数据流），OS 级别以及大多数框架中的 read/write API 是相同的。这意味着例如在节点中，两者都将从 Readable/WriteableStream 接口继承。这意味着您需要更改的唯一代码是在服务器端的侦听器，您在服务器端调用 TCP 接受 API 而不是 unix 域套接字接受 API，反之亦然。您甚至可以让您的应用程序接受两种类型的连接，然后在内部以相同的方式处理它们。
TCP 支持总是很好，因为它为您提供了一些灵活性。在我上次的测量中，开销稍微多了一点（我认为 30% 与 TCP over loopback 相比），但这些都是微观基准，对大多数应用程序来说都无关紧要。如果需要某些特殊功能，例如 Unix 域套接字，可能会有优势。在它们之间发送文件描述符的能力。
关于 TCP 与 NATS & Co： 如果您在网络编程和协议设计方面没有那么丰富的经验，那么使用现成的 IPC 系统是有意义的。这可能是从 HTTP 到 gRPC 再到 Thrift 的任何东西。这些都是点对点系统。 NATS 不同，因为它是消息代理而不是 RPC。它还需要在中间有一个额外的组件。这是否有意义完全取决于应用程序。