可扩展的 django 应用程序,消息队列应该位于负载均衡器还是应用服务器上?

可扩展的 django 应用程序,消息队列应该位于负载均衡器还是应用服务器上?

我刚刚为 Django 应用程序构建了我的第一个可扩展后端,但是我将消息队列服务 (RabbitMQ) 放在了负载平衡器机器上。我能够用最多 500 个并发用户围攻我的一些 API 路由,而不会造成严重的时间不足,但我想知道将 MQ 服务放在其他地方是否会有更好的性能。

我现在的设置:

应用请求 > 负载均衡器 (nginx、rabbitmq) > 工作者,2 个正在使用 (gunicorn/celery) > db (postgres)

因此,我目前有 4 个 AWS EC2 实例(所有都是 m3.medium)连接到 VPC 中为我完成所有这些工作。在工作节点上执行 rabbit 没什么意义,所以我只是想了解人们在做什么。

我也想知道如何最好地配置 gunicorn,但从我的搜索来看,除了实际工作线程的数量/类型之外,似乎没有太多需要处理的地方。对于我的 AWS EC2 实例 (m3.medium),只有 3/同步(使用异步工作线程时性能较差)。

答案1

理想情况下,您的 MQ 应位于单独的实例上,以便可以独立于您的应用服务器或负载均衡器进行扩展。这也使维护更加容易(例如,您可以更换负载均衡器实例而不必迁移现有队列),并且将它们隔离更有利于安全性(您的 LB 需要公共访问,而您的 MQ 则不需要)。

还值得指出的是,AWS 非常注重将那些可以通过大规模经济高效管理的组件与应用程序独有组件分离,并将他们所谓的“无差别繁重工作”委托给托管 AWS 服务。例如,在 AWS 上,通常在 ElastiCache 上使用 SQS 或基于 Redis 的 MQ,它们都支持开箱即用的 HA 架构(通过多可用区实现 EC)。同样,您可以将 LB 委托给 ELB,从而腾出时间专注于优化应用程序和可能的 DB 服务器(如果 RDS 不能满足您的需求,我不确定 Postgres 的情况如何)服务器。

相关内容