我有一个通过 wsgi 公开的 Python 应用程序，打算将其部署到世界各地。它不提供任何静态资产。该应用程序将部署到单台机器上。我将使用 uwsgi 为 wsgi 应用程序提供服务，可以想到两个选项：
通过机器上的单个 uwsgi 实例提供服务，（找出并调整要使用的大量工作程序/进程，也许从 2 * # 个核心开始）
在同一台机器上的 nginx 后面运行多个 uwsgi 实例，每个实例都有一个工作进程。
在 nginx 后面运行单个 uwsgi 实例
要记住的一件事是，服务器已经位于负载均衡器后面。
如果有静态资产需要提供，我会考虑尝试 #2 或 #3。因为没有静态文件，所以这似乎有点大材小用。
在这种情况下，在 nginx 后面运行 uwsgi 有什么好处吗？与具有适当数量工作程序的单个 uswgi 服务器相比？
答案1
这个问题的答案很大程度上取决于您的使用情况。
我对 uWSGI 了解不多，但我无法想象在哪个用例中，在同一台机器/虚拟机上运行多个类似的实例是有意义的，因为它显然是为线程设计的。这只是额外的开销。所以 #2 不是一个真正的选择（如果你的应用程序必须经常重启，请修复你的代码而不是使用这样的设置）。
#3 现在听起来有点没用，但事实并非如此。nginx 的开销并不大，与 python 应用程序相比，它的性能和内存占用在这种情况下可能可以忽略不计。它确实会影响延迟，但同样，对于 RTS 游戏服务器以外的任何服务器来说，这都不应该成为问题（而且 http 本来就不是为低延迟而构建的）。真正的问题是额外的配置和另一个故障点。但是，您的应用程序比经过良好测试、使用频繁的 Web 服务器更容易失败，因此它基本上归结为配置。
解决了这个问题之后，下面是一些需要考虑的事情。
- 如果这是一个小型 Web 应用，你预计用户数量不会超过单个服务器可以处理的数量（例如你的个人主页、一所小型学校的主页），那么单个 uWSGI 完全没问题。因为 uWSGI 有自己的自己的负载均衡器，您将有一个后备方案，可以处理小型实例的扩展（但我不确定大型部署是否适用）。
- 如果您确定您的应用程序将保留在当前托管的位置（即 AWS），您仍然可以使用 #1 并使用托管商内置的负载均衡器。这样可以减少您的开销，并且您不必担心额外的配置。但是您应该知道，定价和服务可能会发生变化，小型托管商可能会倒闭（使用 AWS这风险足够小）。
- 如果您认为您的应用程序可能快速扩展出单个 VM，并且您的托管商负载均衡器没有保证，那么您真的应该添加 nginx。正如我上面所说，它不会带来太多开销，如果您突然需要第二台 VM，您会非常感激。它还允许处理应用程序崩溃和过滤请求（例如，如果您在 DOS 下）。如果您要添加 https，nginx 也会为您提供帮助。
总结
如果您确定您的应用程序扩展速度不会快于您扩展代码的速度（或根本不会扩展），您不需要它的附加功能（您的应用程序并不像您想象的那么稳定！）并且您确定您的托管商具有负载平衡能力，请跳过 nginx。如果不是，或者如果您不能 100% 确定上述情况会保持不变，请使用 nginx。它的开销不大，但可以为您省去很多麻烦。