我在EC2实例中运行Django应用程序，它使用RabbitMQ + Celery进行任务排队。从与生产应用程序相同的EC2实例运行我的RabbitMQ节点有什么缺点吗？
答案 0 :(得分：3)
这些问题的答案实际上取决于您的应用程序的上下文。
面对场景时，您应该始终考虑一些事项。
关注点分离 在这里，我们要确保如果其中一个系统不负责其他系统的运行。这包括
如果运行所有任务的ec2实例出现故障，队列中的其余任务是否将继续运行
如果我的RAM已满，所有系统都将保持运行状态
我是否可以扩展应用程序的一部分，而不必重新设计基础架构。
通过将兔子和django（带有某种服务，wsgi，gunicorn，女服务员等）全部放在一个盒子上，您会释放很多资源意外情况。
尽管RAM和CPU可能很丰富，但是IO，磁盘写入，网络写入等都受到限制。这意味着，如果由于某种原因您拥有繁重的写入功能，则所有其他系统都可能因此而遭受损失。如果您对RAM函数的写操作繁重，则同样适用。
因此，从您的问题和我自己的经验中可以看出，将事物保存在一个系统中的确有以下缺点。
多个故障点。如果您的Rabbit实例失败，则队列和任务将停止工作。
如果您的应用开始产生大量流量，其他系统将开始争夺资源。
如果任何组件出现故障，则可能意味着其他服务的其他停机时间。
系统停机意味着所有组件都将完全停机。
当您的应用程序需要更多资源且停机时间最短时，很多头疼的事情。
很多网络流量会减慢任务运行速度
许多任务正在运行会降低网络请求的速度
很多IO会减慢所有速度
我通常遵循的经验法则是使单个故障点彼此远离-这样，您只需要管理那些组件即可。一个很好的用例是对应用程序使用EC2实例，对工人使用另一个实例，对兔子使用另一个实例。这样，您可以根据需要为这些组件应用较小/较大的实例。如果您是用例，甚至可以创建AMI并创建自动伸缩组。
这里有一些文章可供参考
答案 1 :(得分：0)
如果我们从这个问题中删除EC2实例，它将变为：
在与我的生产应用相同的服务器上运行RabbitMQ Node是否有任何缺点？
我会说这取决于各种因素，例如工作负载的种类及其组成，工作负载的复杂性，您期望使用率的增长等。
如果您的工作负荷正常并且服务器足以容纳这两个应用程序+任务q，那么为什么不这样做，因为将只管理一台服务器。确保通过限制它们的系统资源使用量来相互保护这两个进程。
如果流量不正常，则可能需要更多一台服务器。在这种情况下，拥有专用服务器会更好（关注点分离），因为您将不得不管理多个服务器。
现在回到EC2，以上所有内容仍然适用。 EC2使应用程序的水平扩展更加容易，因此，如果将它们放在单独的实例上，则可以单独扩展它们，并且具有成本效益。如果不进行扩展，将会浪费资源。
答案 2 :(得分：0)
TLDR；如果您可以在一个EC2上运行，则应立即进行扩展。
Joshnidhin和Giannis都涉及RAM，IO和CPU方面。
我已经在单个实例中使用容器化运行了生产应用程序，并且安心地睡着了，如果明天突然有很多人想要我构建的东西，我可以通过将这些容器部署在不同的实例而不是一个实例上来快速扩展。
Docker允许您限制每个容器的CPU使用率和内存使用率，因此您还可以确保它们不会相互冲突。