Amazon ec2 CPU受限/有状态分布式系统设计

我正在开发一个遗留系统的web应用程序前端，它涉及大量CPU限制的后台处理。应用程序在服务器端也是有状态的，当用户通过基于web的界面对其进行操作时，需要在整个会话中将域对象保存在内存中。可以将其视为photoshop的web UI前端，每个过滤器在服务器端执行可能需要20-30秒，因此应用程序在用户等待时仍必须与用户实时交互

主要问题是服务器的每个实例一次只能支持每个“工作区”的大约4-8个实例，我需要一次支持数百个并发用户。我将在AmazonEC2上构建它，以利用自动缩放功能。综上所述，该系统是：

• 传统后端系统的web应用程序前端
• 执行的任务受CPU限制
• 有状态的，大多数调用将是某种RPC，用户将执行多个与服务器端内存中的有状态对象交互的操作
• 大多数任务是半实时的，它们必须执行20-30秒，并在同一会话中将结果返回给用户
• 使用amazon aws自动缩放

我想知道什么是使这样一个系统分布式的最好方法

显然，我需要一个web服务器与浏览器交互，然后将cpu绑定的任务从web服务器发送到一组专门的服务器，这些服务器进行后台处理。问题是如何为我的特定需求最好地将两层连接在一起

我一直在研究rabbitMQ之类的消息队列系统，但它们似乎是面向一次性任务的，在一次性任务中，任何工作节点都可以简单地从队列中获取作业，执行它并忘记状态。我的需求有点不同，因为可能有多个“任务”需要“粘性”，例如，如果步骤1在节点1中启动，那么相同工作区的步骤2必须转到相同的工作进程

我看到的另一个问题是，大多数工作队列系统似乎面向可以随时处理的后台任务，而不是必须提供用户反馈的系统

我的问题是，有没有现成的解决方案可以让我轻松构建一个可以扩展的系统？我很想听听你的想法。

• RabbitMQ具有一个。我没有特别使用这种模式，但我在几个节点上运行RabbitMQ，它可以处理数百个连接和数百万条消息。通过一点监控工作，您可以检测到什么时候有更多的工作要做，然后您就有了消费者。消息也可以超时，这样队列就不会备份太多。要扩展容量，可以创建多个RabbitMQ节点/集群。您可以有多轮RPC，以便在第一次响应之后，您可以包含将第二条消息发送到正确目的地所需的信息

• 0MQ将此作为一个可根据需要进行扇形输出的组件。我只玩过这个，但它更容易编码，也可能更容易维护（因为它不需要代理，

  devices

  可以提供代理）。默认情况下，这可能不会处理粘性，但应该可以编写自己的路由层来处理粘性

• 在这方面也不要打折。当您需要请求/应答、每个后端节点的严格吞吐量以及良好的可扩展性时，HTTP得到了很好的支持。使用AWS，您可以在自动缩放组前面轻松使用其ELB，以提供从前端到后端的路由。ELB也支持

我是RabbitMQ的忠实粉丝，但如果这是整个范围，那么HTTP将很好地工作，并且与其他解决方案相比，AWS中的移动部分更少