CPU约束/有状态分布式系统设计

Question

我正在为一个遗留系统开发一个web应用程序前端，这涉及到大量的CPU绑定后台处理。应用程序在服务器端也是有状态的，域对象需要在整个会话中存储在内存中，因为用户通过基于web的接口对其进行操作。把它想象成一个web前端到photoshop，每个过滤器可以在服务器端执行20-30秒，所以应用程序仍然必须在用户等待的时候与用户进行实时交互。

主要问题是服务器的每个实例只能同时支持每个“工作区”的大约4-8个实例，而我需要同时支持几百个并发用户。我将在亚马逊的EC2上构建它，以利用自动缩放功能。因此，总括而言，这个制度是：

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

我想知道什么是最好的方式来使这样的系统分发。

显然，我需要一个web服务器来与浏览器交互，然后将cpu绑定的任务从web服务器发送到一组专门的服务器，用于后台处理。问题是如何最好地将两层连接在一起，以满足我的具体需求。

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

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

我的问题是，是否有现成的解决方案，使我能够轻松地建立一个可以扩展的系统？很想听听你的想法。

Answer 1

• RabbitMQ有一个RPC教程。我没有特别使用这种模式，但是我在几个节点上运行RabbitMQ，它可以处理数百个连接和数百万条消息。只要在监控方面做一点点工作，就可以检测到什么时候有更多的工作要做，然后才有消费者。消息也可以超时，这样队列就不会备份太多。要扩展容量，可以创建多个RabbitMQ节点/集群。您可以使用多轮RPC，以便在第一个响应之后包含将第二条消息发送到正确目的地所需的信息。
• 0MQ将其作为一个基本模式，它将根据需要展开工作。我只玩过这个游戏，但它的代码更简单，维护也可能更简单(因为它不需要代理，devices可以提供一个代理)。默认情况下，这可能无法处理粘性，但是应该可以编写自己的路由层来处理它。
• 也不要为此而折价HTTP。当您想要请求/回复时，每个后端节点都要有严格的吞吐量，并且需要很好地扩展，HTTP是很受支持的。使用AWS，您可以轻松地在自动标度组前面使用他们的ELB来提供从前端到后端的路由。ELB也支持粘性会话。

我非常喜欢RabbitMQ，但是如果这是整个范围，那么HTTP就会工作得很好，在AWS中的移动部件也比其他解决方案少。