2

出于性能原因,我不得不重写我们网络基础设施的一部分。

为此,我将关键部分编写为 C++ 中的 Web 应用程序。此 Web 应用程序侦听给定端口,一次只接受一个 TCP 连接,并处理它在当前连接上接收到的所有 HTTP 请求。

你可以这样启动它来监听 8080 端口:

./webapp 8080

尽管它比以前完美无缺且运行速度更快,但它的局限性在于应用程序的一次连接一次的性质。您不能仅通过一个应用程序实例通过多个连接同时提供 HTML 页面、Javascript 和图像。

为了克服这个限制,我想运行一个前端反向代理 HTTP 服务器,它侦听端口 80,并在后台运行的 Web 应用程序的多个实例上均匀地重定向传入的 HTTP 请求。这些实例可以在启动时创建,如下所示:

./webapp 10000
./webapp 10001
./webapp 10002
./webapp 10003
./webapp 10004
./webapp 10005
./webapp 10006
./webapp 10007
./webapp 10008
./webapp 10009 

前端应配置为在启动时与每个 Web 应用程序建立永久HTTP 连接,然后将传入的 HTTP 请求转发到正在运行的 Web 应用程序之一,均匀分布它们。

反向代理还应该支持从客户端到自身的 SSL。支持 SPDY 将是一个加分项,但不是必须的。

我的问题是:在我的场景中,哪些 HTTP 反向代理可以用作前端?如果你知道不止一个,每个的优点和缺点是什么?

4

3 回答 3

0

听起来您不一定需要反向代理,而是需要负载均衡器。我设置了HAProxy,以便每个 webapp 进程都算作一个后端,然后进行循环平衡,以便每个新连接都转到列表中的下一个进程。

Nginx也可以做这些事情,但我不确定它是否带有开箱即用的负载平衡,或者它是否是一个附加模块。Nginx 的好处是可以缓存 CSS 和图片等静态资产。

于 2015-04-22T12:47:39.460 回答
0

您拥有一个仅连接的服务器的动机是什么?对于网络服务器来说,这听起来像是一个糟糕的选择。当您的网站出现时,每个客户端浏览器通常会并行发送数十个请求。

如果你通过 TCP 连接产生一个进程,你最终会表现不佳。真的,您在这里寻找的是多线程服务器而不是多进程基础架构(拥有不同进程的意义何在?)

不过,你可以走几条路:

  • webapp如果您真的想拥有单独的进程,则每次收到请求时都会分叉。这在性能方面不会很好,但它是我能想到的最接近你最初的问题。

  • 您保留单线程webapp,但维护您收听的套接字列表,并将它们与他们的“伙伴套接字”配对,这是他们将流量转发到的那些(请注意,它可以双向工作)。尽管如此,这仍不是最佳性能,因为您可能会受到内核调用的限制。

  • 您为每个请求生成一个新线程,然后仅在此线程中处理此请求,就像您对单线程架构所做的那样。

如果我是你,我会直接转向解决方案 3,因为它是最好的选择。这并没有太大的麻烦,因为它与您的单线程方法(只是一对套接字)很接近,并且它不会对整个地方的分叉进程造成性能影响。

我认为您不会找到适合您需求的网络服务器,因为它不是处理此类情况的标准方法,而且我怀疑是否有人花时间开发它 :)

编辑:

好的,我从您的编辑中了解您的问题。

尽管如此,对我来说,要解决的问题仍然是一样的:您需要一个将流量分派到您的进程的进程。我认为您不会找到开箱即用的这种调度程序,因此您需要使用我提到的三种技术之一来实现它。

如果您考虑一下,您实际上是在尝试实现代理的一侧,而另一侧是转发到您的webapp. 所以你应该使用代理技术恕我直言。

于 2013-03-31T02:57:14.290 回答
0

Nginx 是一个不错的选择

优点:

  • 支持 SSL 终止
  • 支持开箱即用的负载均衡
  • 上游保活连接
  • 有 SPDY 支持(虽然没有服务器推送)。最新版本添加了 http2 支持并删除了 spdy。

缺点:

  • 您必须在 nginx 配置中对上游服务器进行硬编码,如下所示。如果动态更新它们,则没有简单的方法可以通过环境变量读取上游服务器设置。

    http {
        upstream myapp1 {
            server localhost:10000;
            server localhost:10001;
            server localhost:10002;
        }
        server {
            listen 443 ssl spdy;
    
            location / {
                proxy_pass http://myapp1;
            }
        }
    }
    
于 2016-04-19T16:48:58.753 回答