部署 CherryPy 应用程序：独立、WSGI 服务器还是 NGinx？

Question

我打算使用单个 VPS 将多个低流量 CherryPy 应用程序部署为子目录；如：example.com/app1，example.com/app2等等。

在研究了 WSGI 部署之后，看起来部署应用程序的首选方法是在反向代理设置中使用 WSGI 服务器（Gunicorn、uWSGI 等）和 NGinx。串联使用两个网络服务器似乎有点矫枉过正——尤其是因为我的 CherryPy 应用程序本身就是一个网络服务器——但我不想因为它无处不在而忽视这个想法。我当然不是专家，所以我想讨论一下。

我看到三个选项：

• 自行部署 CherryPy。
• 部署在 Gunicorn 或其他 WSGI 服务器下。
• 部署在 WSGI 服务器下并反向代理到 NGinx，这似乎是每个人的解决方案。

我的问题：

• 我到处都看到这种模式的主要原因是什么？Nginx 有那么好吗？
• 对于低流量应用程序，原生 CherryPy 服务器是否足够好，或者我什至不应该尝试？

任何和所有的建议表示赞赏，谢谢。

Answer 1

为什么人们把 Nginx 放在前面？

1. Nginx 是一个异步网络服务器。这意味着它不会为每个连接指定一个线程或进程。相反，它使用操作系统的首选套接字轮询库，因此能够处理数十万个连接。作为应用程序开发人员，您为什么要关心？因为 Nginx 会缓冲连接，并且只有在请求被完全读取时才会将请求传递给您的 CherryPy 上游实例。响应也是一样。这样你的 CherryPy 应用程序，它是一个线程服务器，在很多意义上都落后于 Nginx，变得异步。具体来说，您对缓慢的客户端问题和缓慢的 loris DOS 攻击挥手致意。
2. Nginx 具有开箱即用的连接速率限制。说，我不希望来自同一个 IP 的同时连接超过 8 个。
3. CherryPy 有SSL 问题。Nginx 没有。
4. Python 可以几乎和 C 一样好地来回发送字节。Pythonzlib只是 C 库的包装器。但是因为 Nginx 可以有效地处理连接，所以最好让您的 CherryPy 工作线程免于在生产中提供静态内容，而只专注于动态内容。
5. 在同一端口、域、路径等上复用多个 CherryPy 实例。通常是另一个配置级别的额外灵活性。

单独使用 CherryPy 安全吗？

据原作者之一说，是的。您可以使用 CherryPy 自己完成大多数与网络相关的事情。

CherryPy 具有应用程序的概念，您可以使用一个 CherryPy 实例为多个应用程序提供服务。CherryPy 还可以为其他WSGI 应用程序提供服务。

部署 CherryPy

在传统的 *nix 风格的部署中，您编写 init 脚本、守护进程、删除其特权、编写其 PID 等。当您有几个 CherryPy 实例时，这没什么大不了的。当你有几十个时，它会变得乏味，将进程管理交给 Gunicorn 或 uWGSI 并将你的 CherryPy 实例从 HTTP 切换到 WSGI 是有意义的。

我编写了一个教程/项目框架，cherrypy-webapp-skeleton，其目标是填补在 Debian 上为 Web 开发人员部署（传统）真实世界 CherryPy 应用程序的空白。

包起来

1. 低流量，无特殊要求 ? CherryPy * 1 ? HTTP ? Client.
2. 高流量，特殊要求 ? CherryPy * n ? HTTP ? Nginx ? HTTP ? Client.
3. 同一台服务器上有数十个独立的 CherryPy 实例，渴望对每个人的解决方案进行过度杀伤？CherryPy * n ? WSGI ? Gunicorn ? HTTP ? Nginx ? HTTP ? Client.

Answer 2

每个人都将 nginx（或其他服务器，如 Apache）放在他们的应用程序服务器前面的原因是每个人都有静态内容，如图像、CSS 和 JavaScript，以及他们应用程序独有的奇怪需求。

您的应用服务器（CherryPy、gunicorn 等）经过优化，可以运行您的应用并提供其输出。虽然应用服务器也可以提供静态内容，但它们几乎从未针对此任务进行过优化，因为它次于应用服务器的主要目的。（一些应用服务器也会通过缩小和压缩你的 CSS 和 JS 来提供帮助，这样前面的 Web 服务器可以更快地为这些资源提供服务。）

此外，实际的 Web 服务器可以做的不仅仅是高性能的内容服务。诸如缓存、标头操作、URL 重写、地理定位以及许多其他只会使应用程序服务器膨胀而无济于事的功能。

通常，您只会在开发应用程序时单独运行应用程序服务器，当您是唯一的用户并且性能不是问题时。即使您的网站流量较低，您也希望它更快，对吗？缓慢的低流量网站通常不会成长为高流量网站......