当然，也许。
是的！但相比于什么？与本地的内部调用相比，绝对是——它会很冰冷。与其他一些网络API相比，嗯，不一定慢。
不，没有理由为每个模块分配一个端口。有各种方法可以做到这一点。
成功的唯一方法是您所谈论的服务足够粗糙。这些必须是大而黑的服务类型，使调用它们的费用值得。您将在每笔交易中产生连接成本、数据传输成本和数据封送成本。因此，您希望这些事务尽可能少见，并且您希望有效负载尽可能大以获得最大收益。
您说的是实际使用 REST 架构还是只是通过 HTTP 来回发送内容？ （这些是不同的东西）REST 会产生自己的成本，包括嵌入式链接、无处不在和常见的数据类型等。
最后，您可能根本不需要这样做。它可能是“有点酷”、“很高兴拥有”、“在白板上看起来不错”，但如果真的不需要它，那就不要这样做。只需遵循隔离内部服务的良好实践，以便以后决定执行此类操作，只需插入管理通信等所需的粘合层即可。添加远程分发将增加风险、复杂性和降低性能，（扩展!= performance) 所以应该有充分的理由去做。
可以说，这是所有方法中的“最佳实践”。
编辑——对评论的回应：
所以你的意思是我运行一个网络服务器
处理所有传入的请求？但是之后
模块不会是独立的
应用程序，它打败了整个
目的。我想要每一个
模块能够自行运行。
不，它不会破坏目的。
这是交易。
假设您有 3 个服务。
乍一看，公平地说，这是三种不同的服务，在 3 台不同的机器上，在 3 台不同的 Web 服务器上运行。
但事实是，这些都可以在同一台机器上、同一台网络服务器上运行，甚至可以（将其发挥到极致）运行完全相同的逻辑。
HTTP 允许您映射各种事物。 HTTP 本身就是一种抽象机制。
作为客户端，您只关心要使用的 URL 和要发送的有效负载。它最终与哪台机器通信，或者它执行的实际代码不是客户端问题。
在架构级别，您已经实现了一种抽象和模块化的方式。 URL 让您组织您的系统是您想要的任何逻辑布局。 PHYSICAL 实现不同于逻辑视图。
这 3 个服务可以在由单个进程提供服务的单个机器上运行。另一方面，它们可以代表 1000 台机器。您认为有多少台机器会响应“www.google.com”？
您可以在一台机器上轻松托管所有 3 项服务，而无需共享任何代码，只需保存 Web 服务器本身。轻松将服务从其原始机器移动到其他机器。
主机名是将服务映射到机器的最简单方法。任何现代 Web 服务器都可以为任意数量的不同主机提供服务。每个“虚拟主机”可以在该主机的名称空间内为任意数量的单独服务端点提供服务。在“主机”级别，如果必须，将代码从一台机器重新定位到另一台机器是微不足道的。
您应该探索更多现代 Web 服务器的功能，以将任意请求定向到服务器上的实际逻辑。您会发现它们非常灵活。