我打算使用单个 VPS 将多个低流量 CherryPy 应用程序部署为子目录；例如：example.com/app1、、example.com/app2等等。
在研究了 WSGI 部署之后，似乎部署应用程序的首选方法是使用 WSGI 服务器（Gunicorn、uWSGI 等）和 NGinx 进行反向代理设置。同时使用两个 Web 服务器似乎有点过头了——尤其是因为我的 CherryPy 应用程序本身就是一个 Web 服务器——但我不想否定这个想法到处。我当然不是专家所以我想讨论一下。
我看到三种选择：
- 自行部署CherryPy。
- 在 Gunicorn 或其他 WSGI 服务器下部署。
- 部署在 WSGI 服务器之下并反向代理到 NGinx，这似乎是每个人的解决方案。
我的问题：
- 我到处都看到这种模式的主要原因是什么？NGinx 只是那好的？
- 对于低流量应用程序，原生 CherryPy 服务器是否足够好，或者我甚至不应该尝试？
谢谢您提出的所有建议，谢谢。
答案1
为什么人们把 Nginx 放在最前面？
- Nginx 是一个异步 Web 服务器。这意味着它不会为每个连接分配一个线程或进程。相反，它使用操作系统首选的套接字轮询库，因此能够处理数十万个连接。作为应用程序开发人员，您为什么要关心这个问题？因为 Nginx 会缓冲连接，并且只有在请求完全读取后才将请求传递给您的 CherryPy 上游实例。响应也是如此。这样，您的 CherryPy 应用程序（一个线程服务器，在很多方面落后于 Nginx）就变成了异步的。具体来说，您可以对缓慢的客户端问题和缓慢的 loris DOS 攻击挥挥手。
- Nginx 具有开箱即用的连接速率限制。比如说，我不希望来自同一 IP 的同时连接超过 8 个。
- CherryPy 具有SSL 问题. Nginx 没有。
- Python 可以像 C 一样很好地来回发送字节。Python
zlib只是 C 库的一个包装器。但由于 Nginx 可以有效地处理连接，因此最好让您的 CherryPy 工作线程不再在生产中提供静态内容，而只专注于动态内容。 - 在同一端口、域、路径等上多路复用多个 CherryPy 实例。通常是另一个配置级别的额外灵活性。
单独使用 CherryPy 安全吗？
根据其中一位原作者的说法，是的. 大多数与网络相关的操作都可以用 CherryPy 单独完成。
CherryPy 有应用程序的概念，你可以服务于多个应用程序一个 CherryPy 实例。CherryPy 还可以为其他WSGI 应用程序。
部署 CherryPy
在传统的 *nix 风格部署中，您需要编写初始化脚本、守护进程、删除其权限、写入其 PID 等。如果您有几个 CherryPy 实例，那么这不是什么大问题。如果您有几十个实例，那么这就会变得很繁琐，将进程管理移交给 Gunicorn 或 uWGSI 并将 CherryPy 实例从 HTTP 切换到 WSGI 是明智之举。
我写了一个教程/项目框架，cherrypy-webapp-skeleton，其目标是填补 Web 开发人员在 Debian 上部署（传统的）真实 CherryPy 应用程序的空白。
包起来
- 流量低，无特殊要求→
CherryPy * 1 ⇐ HTTP ⇒ Client。 - 高流量、特殊要求→
CherryPy * n ⇐ HTTP ⇒ Nginx ⇐ HTTP ⇒ Client。 - 同一服务器上有数十个独立的 CherryPy 实例，渴望过度杀伤每个人的解决方案→
CherryPy * n ⇐ WSGI ⇒ Gunicorn ⇐ HTTP ⇒ Nginx ⇐ HTTP ⇒ Client。
答案2
每个人都将 nginx（或其他服务器，如 Apache）放在其应用服务器前面的原因是每个人都有静态内容，如图像、CSS 和 JavaScript，以及其应用程序独有的奇怪要求。
你的应用服务器（CherryPy、gunicorn 等）已针对运行你的应用和提供其输出进行了优化。而应用服务器能也提供静态内容，但它们几乎从未针对此任务进行过很好的优化，因为它是应用服务器的主要目的的次要部分。（一些应用服务器还会通过最小化和压缩 CSS 和 JS 来提供帮助，以便前端的 Web 服务器可以更快地提供这些资源。）
此外，实际的 Web 服务器可以做的远不止提供高性能内容服务。缓存、标头操作、URL 重写、地理定位等功能以及许多其他功能只会让应用服务器变得臃肿而毫无用处。
通常，只有在开发应用程序时，当您是唯一的用户并且性能不是问题时，您才会单独运行应用服务器。即使您的网站流量较低，您也希望它更快，对吗？速度慢的低流量网站通常不会发展成为高流量网站...