我正在将一个大型应用程序分成几个进程，我希望每个进程能够相互通信。
现在它将在同一台服务器上，但后来同一本地网络上的几台服务器将有几个需要相互通信的进程。 （表示在一台服务器上提供服务，在同一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倍但是nat具有很酷的发布 - 订阅功能......但性能很重要。
所以我有很多选择，没有具体的决定。
非常感谢有关该问题的任何信息。
答案 0 :(得分：1)
这个问题实际上过于宽泛而无法回答，但TCP和unix域套接字有一个答案：
构建您的代码，以便您可以在必要时轻松地在这些代码之间移动。这些的编程模型基本相同（都是双向数据流），OS级别以及大多数框架中的读/写API都是相同的。这意味着例如在节点中，两者都将从Readable / WriteableStream接口继承。这意味着您需要更改的唯一代码是服务器端的侦听器，您可以在其中调用TCP接受API而不是unix域套接字接受API，反之亦然。您甚至可以让您的应用程序接受这两种类型的连接，然后在内部处理它们。
TCP支持总是很好，因为它为您提供了一些灵活性。在我的上一次测量中，开销稍微多了一些（我认为30％与TCP相比，环回）但这些都是微基准测试，对大多数应用来说无关紧要。如果需要它们的一些特殊功能，例如Unix域套接字可能具有优势。能够在它们之间发送文件描述符。
关于TCP与NATS＆amp;合作： 如果您不具备网络编程和协议设计经验，那么使用现成的IPC系统是有意义的。这可以是从HTTP到gRPC到Thrift的任何东西。这些都是点对点系统。 NATS是不同的，因为它是一个消息代理而不是RPC。它还需要在中间增加一个组件。这是否有意义完全取决于应用程序。