我正在处理遗留系统的Web应用程序前端，该系统涉及大量CPU绑定后台处理。该应用程序在服务器端也是有状态的，并且当用户通过基于Web的界面对其进行操作时，域对象需要在整个会话中保存在内存中。可以把它想象成像Photoshop的Web UI前端，每个过滤器在服务器端执行需要20-30秒，因此应用程序仍然需要在等待时实时与用户交互。
主要问题是服务器的每个实例一次只能支持每个“工作空间”的大约4-8个实例，我需要同时支持几百个并发用户。我将在Amazon EC2上构建它以利用自动缩放功能。总而言之，该系统是：
我想知道制作像这样分布式系统的最佳方法是什么。
显然，我需要一个Web服务器与浏览器进行交互，然后将来自Web服务器的cpu绑定任务发送到一堆执行后台处理的专用服务器。问题是如何最好地将2层连接起来以满足我的特定需求。
我一直在研究消息队列系统，例如rabbitMQ，但这些似乎是针对一次性任务，任何工作者节点都可以简单地从队列中获取作业，执行它并忘记状态。我的需求有点不同，因为可能有多个“任务”需要“粘滞”，例如，如果在节点1中启动了步骤1，那么同一工作区的步骤2必须转到相同的工作进程。
我看到的另一个问题是，大多数工作队列系统似乎都是针对可以随时处理的后台任务，而不是一个必须提供我正在处理的用户反馈的系统。
我的问题是，是否有现成的解决方案可以让我轻松构建可扩展的系统？很想听听你的想法。
答案 0 :(得分：2)
RabbitMQ有一个RPC tutorial。我没有特别使用这种模式，但我在几个节点上运行RabbitMQ，它可以处理数百个连接和数百万条消息。通过一些监控工作，您可以检测到有更多工作要做，然后您就有了消费者。消息也可以超时，因此队列不会太大。要扩展容量，您可以创建多个RabbitMQ节点/群集。您可以有多轮RPC，以便在第一次响应后包含将第二条消息发送到正确目的地所需的信息。
0MQ将此作为basic pattern，可根据需要进行操作。我只玩过这个，但代码更简单，维护起来也更简单（因为它不需要需要代理，devices可以提供一个代理）。默认情况下这可能无法处理粘性，但应该可以编写自己的路由层来处理它。
不要为此折扣HTTP。当您需要请求/回复，每个后端节点的严格吞吐量以及可扩展的东西时，HTTP都得到了很好的支持。使用AWS，您可以在自动扩展组前轻松使用ELB，以提供从前端到后端的路由。 ELB也支持sticky sessions。
我是RabbitMQ的忠实粉丝，但如果这是整个范围，那么HTTP可以很好地工作，并且AWS中的移动部件比其他解决方案少。