☰

Web 服务器与应用服务器通信时使用 HTTP 有哪些优缺点？

tag-icon • tag-icon http reverse-proxy
Web 服务器与应用服务器通信时使用 HTTP 有哪些优缺点？

背景：我想将我们的 Web 服务器/应用服务器功能分离到不同的机器上（逻辑上或物理上）。这意味着，我想将某些资源专用于提供静态内容（静态 HTML、图像、Javascript、CSS、视频等...），并将其他资源专用于生成动态 HTML（我的 Web 应用程序，它恰好是一个 ColdFusion 应用程序，您可以将其视为任何 J2EE 应用程序）。

我熟悉几个 J2EE 供应商用于将其应用服务器与 Web 服务器连接的方法。例如，Adobe 提供 mod_jrun，Tomcat 提供 mod_ajp、mod_proxy_ajp 和 mod_jk，Caucho (Resin) 提供 mod_caucho 等... 这些连接器中有多个允许负载平衡功能。我猜它们正在与可充当群集控制器的应用服务器的一部分进行通信。

我注意到的一件事是，这些连接器是为与 Apache（通常是 Windows 上的 IIS）一起使用而设计的。我们正在考虑从 Apache 转移到更轻量级的 Web 服务器之一，例如 Nginx 或 Cherokee。如果我这样做，似乎我将无法使用上面提到的连接器。这些服务器的文档中一致的建议是仅配置它们的 HTTP 反向代理功能，以便将它们连接到您的应用服务器（通过应用服务器的 HTTP 实现）。

我对您对 HTTP 与其他协议（如我上面提到的）在连接器中使用的性能影响的经验很感兴趣。我假设那些其他连接器将在更低的级别上运行，因此具有更高的性能。它们显然可以带来新的“功能”，例如公开应用服务器的负载平衡功能（如我上面提到的）。

那么你怎么看？HTTP 在 Web 层和应用层之间进行通信的简单性和灵活性是否比更定制的连接器的附加功能更具吸引力？在规划这样的多层架构时，是否还有其他我尚未考虑的问题？

答案1

有很多HTTP 示例 反向代理 在大型网站上，所以我认为它在性能、扩展或易于管理方面没有问题。

在您当前服务器前面添加 nginx 或同等软件来进行负载平衡不会有太大变化，并且当 apache+mod_whatever 不再增加价值时，您将能够逐渐替换它。

答案2

在您进一步讨论之前，我必须承认我没有实际数据来回答您的问题。我对 mod_proxy_http 和 mod_proxy_ajp 进行了一些相对较小的测试，但结果尚无定论。

我的理解是 mod_jk 已被弃用，取而代之的是 mod_proxy_ajp；而且 mod_jk（以我的经验来看）更难配置。

mod_proxy_ajp 和 mod_jk 在前端 Web 服务器和应用服务器之间通信的方式本质上是 HTTP 的二进制形式，理想情况下，Web 服务器和应用服务器的发送和接收速度都会更快。对于负载平衡，mod_proxy 系列使用 mod_proxy_balancer，它与 mod_proxy_http 或 mod_proxy_ajp 配合使用。最重要的是，两者之间没有功能差异。

相关内容