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

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

我看到三个选择：

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

我的问题：

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

任何和所有建议，不胜感激，谢谢。

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

您的应用服务器（CherryPy，gunicorn等）已经过优化，可以运行您的应用并提供其输出。尽管应用程序服务器还可以提供静态内容，但由于它是应用程序服务器主要目的的第二要务，因此它们几乎从未针对此任务进行过优化。（某些应用服务器还可以通过压缩和压缩CSS和JS来提供帮助，从而使前面的Web服务器可以更快地提供这些资源。）

此外，实际的Web服务器可以做的还不止是高性能的内容服务。诸如缓存，标头处理，URL重写，地理位置以及许多其他功能之类的东西只会使应用程序服务器肿，没有任何用处。

通常，只有在开发应用程序时（只有您是唯一用户）才单独运行应用程序服务器，而性能不是问题。即使您的网站流量很少，您还是希望它更快一些，对吗？低流量的网站通常不会成长为高流量的网站...

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

1. Nginx是一个异步Web服务器。这意味着它不会为每个连接专用一个线程或一个进程。相反，它使用OS首选的套接字轮询库，因此能够处理数十万个连接。作为应用程序开发人员，您为什么要关心？因为Nginx缓冲连接，并且仅在完全读取请求后才将请求传递给CherryPy上游实例。响应也一样。这样，您的CherryPy应用程序（在多方面都位于Nginx后面）是线程服务器，它变得异步。具体来说，您会遇到缓慢的客户端问题和缓慢的loris DOS攻击。
2. Nginx具有开箱即用的连接速率限制。说，我不希望来自同一IP的8个以上同时连接。
3. CherryPy存在SSL问题。Nginx没有。
4. Python可以来回发送几乎与C一样好的字节。Python zlib只是C库的包装器。但是，因为Nginx有效地处理了连接，所以最好减轻CherryPy辅助线程在生产中提供静态内容的工作，而只将动态内容专用。
5. 在同一端口，域，路径等上复用多个CherryPy实例。通常，另一个配置级别具有更高的灵活性。

单独使用CherryPy是否安全？

根据一位原始作者的说法，是的。您可以单独使用CherryPy进行与网络相关的大多数事情。

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

部署CherryPy

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

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

包起来

1. 低流量，无特殊要求→ CherryPy * 1 ⇐ HTTP ⇒ Client。
2. 高流量，特殊要求→ CherryPy * n ⇐ HTTP ⇒ Nginx ⇐ HTTP ⇒ Client。
3. 同一服务器上有数十个单独的CherryPy实例，渴望消除每个人的解决方案 → CherryPy * n ⇐ WSGI ⇒ Gunicorn ⇐ HTTP ⇒ Nginx ⇐ HTTP ⇒ Client。