进程之间的通信：tcp vs unix套接字，ipc vs nats

我打破了一个大的应用程序到几个进程，我希望每个进程相互沟通。

现在它将在同一台服务器上，但后来在同一个本地networking上的几台服务器将有几个进程需要互相通信。 （指一台服务器上的服务，在同一个vpc上的服务在其他服务器上）

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

这值得么 ？ 当然，TCP套接字是慢的，然后unix套接字..因为它不通过networking，并没有得到封装与TCP相关的数据。 问题是多less？ 我无法findtcp和unix套接字之间的基准testing的在线certificate。 如果tcp增加了3％-5％的开销，那很酷，但可以更多吗？ 我想多年来从别人的大项目经验中学习，但没有find任何相关的东西。

下一个…

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

有些人可能会说，我可以使用经纪人的消息，所以我尝试使用nats.io相比node-ipc（ https://www.npmjs.com/package/node-ipc ），我发现了node-ipc速度提高了4倍，但是nats有很酷的发布 – 订阅function…但是性能很重要。

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

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

Answer 1

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

构build您的代码，以便在必要时轻松移动这些代码。 它们的编程模型基本相同（都是双向数据stream），操作系统级以及大多数框架中的读/写API是相同的。 这意味着例如在节点中都将从Readable / WriteableStream接口inheritance。 这意味着你需要改变的唯一的代码是在服务器端调用TCP接受API的监听器，而不是unix域套接字接受API，反之亦然。 你甚至可以让你的应用程序接受这两种types的连接，稍后在内部处理它们。

TCP支持总是很好，因为它给你一些灵活性。 通过我的最后一次测量，开销更多一些（我认为30％与TCP over loopback相比），但这些都是微基准testing，对于大多数应用程序来说并不重要。 如果Unix域套接字需要某些特殊function，例如可以跨文件描述符发送，Unix域套接字可能会有优势。

关于TCP vs NATS＆Co：如果您对networking编程和协议devise没有经验，那么使用现成的IPC系统是有意义的。 这可能是从HTTP到gRPC到Thrift的任何事情。 这些都是点对点的系统。 NATS是不同的，因为它是一个消息代理而不是RPC。 它也需要一个额外的组件在中间。 这是否有意义完全取决于应用程序。