进程间通信：TCP vs Unix套接字，IPC vs NATS

Question

我正在将一个大型应用程序分成几个进程，并希望每个进程之间进行通信。目前它将在同一台服务器上，但以后在同一本地网络上的多个服务器将具有需要彼此通信的多个进程（表示在同一VPC上的另一个服务器上的服务与该服务器上的服务）。因此，我的原始选项是TCP或Unix套接字。我知道Unix套接字只有在您在同一台服务器上时才有用。但我们正在考虑编写自己的实现，使在同一服务器上的进程将在Unix套接字上通信，在服务器之间通信时将使用TCP。值得吗？当然，TCP套接字比Unix套接字慢...因为它不通过网络并且不包含TCP相关数据。问题是它会增加多少开销？我找不到TCP和Unix套接字之间的基准测试证明。如果TCP增加3％-5％的开销，那很好，但它可能更多吗？我想从大型项目的经验中学习...多年来其他人的经验，但没有找到任何相关的东西。

接下来...

我们的项目是一个Node.js项目。

有些人可能会说我可以使用代理来进行消息传递，因此我尝试了使用 nats.io 与 node-ipc (https://www.npmjs.com/package/node-ipc) 进行比较，我发现 node-ipc 的速度快了 4 倍，但 nats 具有很酷的发布-订阅功能... 但性能也很重要。

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

任何关于这个问题的信息都将不胜感激。

- ufk

Answer 1

这个问题实际上太广泛，无法回答，但是对于TCP和Unix域套接字的一个答案是：

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

TCP支持总是很好的，因为它给你一些灵活性。根据我的最后一次测量，开销略高一些（我认为与loopback上的TCP相比增加了30％），但这些都是微基准测试，并且对于大多数应用程序来说并不重要。如果需要使用它们的某些特殊功能，例如跨它们发送文件描述符的能力，则Unix域套接字可能具有优势。

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

- Matthias247