0

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

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

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

我想知道制作这样一个分布式系统的最佳方法是什么。

显然，我需要一个 Web 服务器来与浏览器交互，然后将 CPU 绑定的任务从 Web 服务器发送到一组执行后台处理的专用服务器。问题是如何根据我的特定需求最好地将 2 层连接在一起。

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

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

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

4

1 回答 1

2

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

  • 0MQ 将此作为基本模式，可根据需要进行扇出工作。我只玩过这个，但它更容易编码并且可能更容易维护（因为它不需要代理，devices但可以提供）。默认情况下这可能无法处理粘性，但应该可以编写自己的路由层来处理它。

  • 也不要为此打折 HTTP。当您想要请求/回复、每个后端节点的严格吞吐量以及可良好扩展的东西时，HTTP 得到了很好的支持。借助 AWS，您可以在自动缩放组前面轻松使用其 ELB，以提供从前端到后端的路由。ELB 也支持粘性会话。

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

于 2013-07-08T01:39:07.653 回答