服务器 Gind.cn
  1. 服务器 Gind.cn
  3. 使用uWSGI的内置负载均衡器和nginx
Intereting Posts
PuTTY致命错误：服务器拒绝启动一个shell /命令 采用仅基于IPv4访问的客户端的基于RRAS SSTP VPN的IPv6 Centos安装：Anaconda在收到信号7后死亡 我需要一些MySQL查询表的build议 获取基于Linux的虚拟设备/机器的根目录 服务器在命令和控制模式 在Ubuntu 10.04上将JRE_HOME设置为Sun的Java的最佳方法 微软的课程是值得的吗？ 后端ec2实例可通过ssh和浏览器访问，但负载均衡器运行状况检查失败 有没有什么好的理由不增加upload_max_filesize和post_max_size？ 在远程Linux服务器上查看日志 ZFS池或LVM卷组在使用多个分区时更可靠吗？ 共享服务器的虚拟机的单独authentication代理configuration Windows Server更新服务（WSUS）3.0 SP 2在SBS 2003 SP 2上未成功安装 每个JOB ARRAY的电子邮件通知不是每个作业在PBS扭矩

使用uWSGI的内置负载均衡器和nginx

我有一个通过wsgi公开的python应用程序，并将其部署到世界。 没有从它提供的静态资产。 该应用程序将被部署到一台机器。 我将使用uwsgi来服务wsgi应用程序，并可以考虑两个选项：

  1. 通过机器上的单个uwsgi实例来服务，（弄清楚并用好多的工人/进程来旋转可能会启动2 *＃个内核）

  2. 在同一台机器上运行多个uwsgi实例，每个实例都有一个worker，位于nginx之后。

  3. 在nginx后面运行单个uwsgi实例

有一件事要记住，服务器已经在负载均衡器后面了。

如果我有静态资产，我会考虑试用＃2或＃3。 因为没有静态文件，所以这似乎是矫枉过正。

在这种情况下，在nginx后面运行uwsgi会有什么好处吗？ 反对一个单一的uswgi服务器与适当数量的工人？

这个问题的答案在很大程度上取决于你的用例。

我不太了解uWSGI，但是我无法想象任何使用情况，在同一台机器/虚拟机上运行几个类似的实例是明智的，因为它显然是为线程而devise的。 它只是额外的开销。 所以＃2是不是一个真正的select（如果你的应用程序必须经常重新启动，修复你的代码，而不是使用这样的设置）。

＃3听起来有点无用，但事实并非如此。 nginx并不是很多的开销，与python应用相比，在这种情况下性能和内存占用可能是微不足道的。 它确实会影响延迟，但是对于任何缺lessRTS游戏服务器的应用来说，这也不重要（而且http并不是为低延迟构build的）。 真正的问题是额外的configuration和另一个故障点。 但是，您的应用程序比经过严格testing的Web服务器更有可能失败，因此基本上可以归结为configuration。

有了这个方法，这里有一些事情要考虑。

  • 如果这是一个小型的networking应用程序，你不希望有更多的用户，而不是一个单一的服务器可以处理没有问题（即你的个人主页，一个小学校的主页），一个单一的uWSGI是完全没问题的。 由于uWSGI具有自己的负载均衡器 ，因此您将拥有一个可以处理小型实例缩放的后备（但我不确定大型部署）。
  • 如果您确定您的应用程序将保留在其托pipe的位置（即AWS），则仍然可以使用＃1并使用主机内置的负载平衡器。 这样可以减less开销，而且不必担心其他configuration。 但是，您应该意识到，定价和服务可能会发生变化，小型托pipe商可能会倒闭（使用AWS 这种风险足够小）。
  • 如果您认为您的应用程序可能会从单个虚拟机快速扩展出来，并且您的主机负载平衡器无法保证，那么您应该添加nginx。 正如我上面所说，它不是一个开销，如果你突然需要第二个虚拟机，你将非常感激。 它也允许处理应用程序和filter请求的崩溃（例如，如果你在DOS下）。 如果你添加https，nginx也会帮助你。

TL; DR

如果您确定您的应用程序不会比您可以缩放代码更快（或根本不能扩展），则您不需要其额外的function（您的应用程序不像您想象的那样稳定！），你确定你的主机负载均衡能力，跳过nginx。 如果不是，或者如果你不是100％确定上面将保持真实，使用nginx。 它没有太多的开销，但可以为您节省很多麻烦。