本地应用程序之间的安全通信是一个好主意?

我想知道让本地应用程序(在同一台服务器上)完全通过Restful API相互通信是否是一个好主意?

我知道这并不罕见,因为我们已经有了使用HTTP REST进行通信的应用程序,例如CouchDB,即使是本地应用程序也是如此。

但是我想通过创build类似于更大应用程序模块的应用程序来实现更高级别的应用程序,也可以将其作为另一个应用程序的模块等等。 换句话说,会有很多本地应用程序/模块正在与Restful API进行通信。

通过这种方式,这些应用程序/模块可以使用任何语言,并且可以通过服务器之间的线路进行通信。

但是我有一些问题:

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

       

网上收集的解决方案 "本地应用程序之间的安全通信是一个好主意?"

  • 这是一个好主意吗?

当然,也许。

  • 他们之间的数据传输会慢吗?

对! 但是比较起来呢? 相比本地,内部呼叫,绝对 – 这将是冰河。 相比其他一些networkingAPI,呃不一定慢。

  • 如果我这样做,那么每个应用程序/模块必须是一个HTTP服务器? 因此,如果我的应用程序使用100个应用程序/模块,我必须有100个本地HTTP Web服务器启动并运行每个不同的端口(http:// localhost:81, http:// localhost:82 , http:// localhost:83和等等)?

那么,没有理由分配每个模块的端口。 各种各样的方式来做到这一点。

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

如果你所说的服务足够粗糙,唯一的办法就是成功。 这些必须是大型的,黑盒子的服务,这使得他们称为值得的费用。 您将在每次交易中产生连接成本,数据传输成本和数据编组成本。 因此,您希望这些交易尽可能less,并且您希望有效载荷尽可能大以获得最佳效益。

你是说使用REST架构,还是通过HTTP来回发送内容? (这些是不同的东西)REST会产生自己的成本,包括embedded式链接,无处不在和常见的数据types等等。

最后,你可能不需要这样做。 这可能是“挺酷的”,“很高兴有”,“在白板上看起来不错”,但如果真的不需要,那就不要这样做。 只需遵循隔离内部服务的良好实践,以便稍后决定如何执行此类操作,就可以插入pipe理通信所必需的粘合层。添加远程分发将增加风险,复杂性和较低的性能(缩放!=表演),所以应该有一个很好的理由去做。

这可以说是所有人的“最佳做法”。

编辑 – 对评论的回应:

所以你的意思是我运行一个Web服务器来处理所有传入的请求? 但是,这些模块不会是独立的应用程序,而是完整的目的。 我希望每个模块都能够自行运行。

不,它并没有达到目的。

这是交易。

假设你有3个服务。

一眼就可以说,这是三种不同的服务,在三个不同的机器上运行,在三个不同的Web服务器上运行。

但事实是,这些都可以运行在相同的机器上,在同一个Web服务器上,甚至可以运行在完全相同的逻辑上。

HTTP允许你映射各种各样的东西。 HTTP本身就是抽象机制。

作为一个客户端,你所关心的是要使用的URL和有效载荷。 什么机器结束了谈话,或者它执行的实际代码不是客户端问题。

在架构层面,您已经实现了抽象和模块化的方式。 url让你组织你的系统是任何你想要的逻辑布局。 物理实现不同于逻辑视图。

这3种服务可以在单个进程中运行的单台机器上运行。 另一方面,他们可以代表1000台机器。 您认为有多less台机器回应“www.google.com”?

您可以轻松地在一台机器上托pipe所有3种服务,无需共享任何代码,保存Web服务器本身。 使服务从原始机器移动到其他机器变得容易。

主机名是将服务映射到机器的最简单的方法。 任何现代Web服务器都可以服务于任何数量的不同的主机 每个“虚拟主机”可以为该主机的名称空间内的任意数量的单个服务端点提供服务。 在“主机”级别,将代码从一台机器重新定位到另一台机器时,如果必须的话,它是微不足道的。

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

这是一个好主意吗?

是。 这是一直做的。 例如,这就是所有数据库服务器的工作原理。 Linux充满了通过TCP / IP进行通信的客户机/服务器应用程序。

他们之间的数据传输会慢吗?

TCP / IP使用localhost作为一个捷径,以节省做实际的networkingI / O。

HTTP协议不是专用连接的最佳select,但它很简单,支持也很好。

如果我这样做,那么每个应用程序/模块必须是一个HTTP服务器?

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

因此,如果我的应用程序使用100个应用程序/模块,那么每个应用程序必须是本地HTTP Web服务器,每个服务器运行在不同的端口上(http:// localhost:81, http:// localhost:82 , http:// localhost :83等等)对不对?

是。 这是它的工作方式。

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

不要“硬编码”端口号。

不要使用“特权”端口号(1024以下)。

使用WSGI库,你会很高兴地把你所有的模块都变成WSGI应用程序。 然后你可以使用一个简单的2行HTTP服务器来包装你的模块。

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

在使用应用程序集成的稳定解决scheme时,我认为这是一个好主意,并在另一个问题上提出了类似的观点。

  • 如何在组织间共享数据

坦白说,我不认为你需要100个服务器100个应用程序,也许只是在同一台服务器上使用100个端口。

而且,RESTful接口将使您能够灵活地扩展服务器并实现负载均衡,如果您想要将其扩展到巨大的潜力。

不,如果你没有很好的理由,这不是一个好主意。 将应用程序的代码分层是一个好主意,以便在需要时可以在稍后的阶段“rest”。 (或者无论性能改善是否被认为是必要的)。“基于服务器的层”的增加的部署复杂性是不这样做的好理由。 我会build议:

  • 用良好,干净的代码编写结构良好的应用程序。
  • 用预期的生产负荷进行testing
  • 如果需要的话 – 重构成服务器层 – 但是…..

更好的方法是负载均衡整个应用程序。 如果您在应用程序服务器中执行类似rails的任何状态,那么并行运行多个实例应该不成问题。

如果你正在寻找复杂性 – 无视我的答案。 🙂