本地应用程序之间的宁静沟通是一个好主意吗？

Question

我想知道让本地应用程序（在同一台服务器中）完全通过Restful API彼此通信是个好主意吗？

我知道这并不罕见，因为我们已经有像CouchDB这样的应用程序，即使在本地应用程序中，也正在使用HTTP REST进行通信。

但是，我想通过创建像模块一样用于更大应用程序的应用程序来将其提高到更高的级别，这也可能是另一个应用程序的模块，依此类推。换句话说，将有许多本地应用程序/模块与Restful API通信。

这样，这些应用程序/模块可以使用任何语言，并且可以通过服务器之间的电线进行通信。

但是我有一些问题：

• 这是一个好主意吗？
• 它们之间的数据传输会很慢吗？
• 如果我这样做，那么每个应用程序/模块都必须是HTTP服务器吗？因此，如果我的应用程序使用100个应用程序/模块，那么其中每个应用程序都必须是本地HTTP Web服务器，每个Web服务器每个都在其他端口上运行（http：// localhost：81，81， http：// localhost：82, http：// localhost：83 等等）对吧？
• 我应该知道的任何最佳实践/陷阱吗？

Answer 1

• 这是一个好主意吗？

当然，也许。

• 它们之间的数据传输会很慢吗？

是的！但是与什么相比？与本机的内部呼叫相比，绝对是冰川。与其他网络API相比，EH不一定要慢。

• 如果我这样做，那么每个应用程序/模块都必须是HTTP服务器吗？因此，如果我的应用程序使用100个应用程序/模块，我必须让100个本地HTTP Web服务器启动并运行每个端口（http：// localhost：81，81，http：// localhost：82, http：// localhost：83 等等）？

不，没有理由每个模块分配端口。各种方法来做到这一点。

• 我应该知道的任何最佳实践/陷阱吗？

成功的唯一方法是，如果您正在谈论的服务足够粗糙。这些必须是大型的黑色方形服务，以使其称赞它们值得。您将在每笔交易中产生连接成本，数据传输成本和数据编制成本。因此，您希望这些交易尽可能少见，并且希望有效载荷尽可能大，以获得最佳利益。

您是在说实际使用REST体系结构还是仅通过HTTP来回发送东西？ （这些是不同的事情）休息会产生自己的成本，包括嵌入式链接，无处不在和常见的数据类型等。

最后，您可能根本不需要这样做。它很可能是“有点酷”，一个“很高兴”，“在白板上看起来不错”，但是如果真的不需要，那就不要这样做。只需遵循隔离内部服务的良好做法！=性能），因此应该有一个充分的理由做到这一点。

可以说，这就是所有人的“最佳实践”。

编辑 - 对评论的回复：

因此，您的意思是我运行了一个处理所有传入请求的Web服务器？但是，这些模块将不会是独立的应用程序，它破坏了整个目的。我希望每个模块能够自行运行。

不，它不会打败目的。

这是交易。

假设您有3个服务。

• http://store.example.com/service1

• http://blog.example.com/service2

• http://forum.example.com/service3

乍一看，可以说这是三个不同的机器上的三种不同的服务，在3个不同的网络服务器中运行。

但事实是，这些都可以在同一台机器，同一Web服务器上运行，甚至可以（将其置于极端）运行完全相同的逻辑。

HTTP允许您映射各种内容。 HTTP本身是抽象的机制。

作为客户，您所关心的就是要使用的URL和要发送的有效载荷。它最终与哪台计算机交谈，或者它执行的实际代码而不是客户端问题。

在架构层面上，您已经达到了一种抽象和模块化的方式。 URL让您组织系统是您想要的任何逻辑布局。物理实现与逻辑视图不同。

这3个服务可以通过单个过程提供的单台计算机运行。另一方面，它们可以代表1000台机器。您认为几台机器回复“ www.google.com”？

您可以轻松地在一台计算机上托管所有3个服务，而无需共享任何保存Web服务器本身的代码。使将服务从原始机器移至其他机器变得容易。

主机名是将服务映射到计算机的最简单方法。任何现代的Web服务器都可以服务任何数量的不同主机。每个“虚拟主机”都可以在该主机的名称空间内服务任何数量的单个服务端点。在“主机”级别上，如果您必须和何时将代码从一台计算机重新定位到另一台计算机。

您应该探索更多现代Web服务器将任意请求引导到服务器上实际逻辑的功能。您会发现它们非常灵活。

Answer 2

这是一个好主意吗？

是的。它一直都在完成。例如，这就是所有数据库服务器的工作方式。 Linux装满了通过TCP/IP通信的客户端/服务器应用程序。

它们之间的数据传输会很慢吗？

否TCP/IP使用 localhost 作为保存实际网络I/O的捷径。

HTTP协议并不是专用连接的最佳选择，但它是简单且得到良好支持的。

如果我这样做，那么每个应用程序/模块都必须是HTTP服务器吗？

不必要。有些模块可以是客户端，而没有服务器。

因此，如果我的应用程序使用100个应用程序/模块，那么其中每个应用程序都必须是本地HTTP Web服务器，每个Web服务器每个都在其他端口上运行（http：// localhost：81，81， http：// localhost：82, http：// localhost：83 等等）对吧？

是的。那就是它的工作方式。

我应该知道的任何最佳实践/陷阱吗？

不要“硬码”端口号。

请勿使用“特权”端口号（根据1024）。

使用WSGI库，您将最快乐地将所有模块放入WSGI应用程序中。然后，您可以使用Trivial 2 Line HTTP服务器包装模块。

读这个。 http://docs.python.org/library/wsgiref.html#examples

Answer 3

在使用RESTFUL解决方案进行应用程序集成时，我相信这是一个好主意，并在另一个问题上自称类似的观点。

• 如何在组织中共享数据

Answer 4

坦率地说，我认为您不需要100台服务器才能用于100个应用程序，也许只需在同一台服务器上使用100个端口即可。

而且，如果您希望有可能扩展到巨大，那么，RESTFULE接口将为您提供扩展服务器的灵活性并实现负载平衡。

Answer 5

不 - 如果您没有充分的理由，那不是一个好主意。最好将应用程序的代码分层，以便在需要的情况下在以后的阶段“休息”。 （或认为有必要的任何性能改进。）“基于服务器层”的部署复杂性增加是不这样做的一个很好的理由。我会建议：

• 编写一个结构良好的应用程序，并具有良好的干净代码。
• 用预期的生产负荷进行测试
• 如果需要 - 重构为服务器的层 - 但是.....

一种更好的方法是加载整个应用程序平衡。如果您在应用程序服务器中没有状态的导轨之类的事情，那么并行运行多个实例应该没有问题。

如果您正在寻找复杂性 - 无视我的答案。 :-)