1

我正在设计一个从 10,000 英尺高的分布式主从系统，包括：

  • 基于网络的用户界面
  • 一个主组件，负责根据一组可配置的算法生成作业
  • 在普通电脑、HPC 集群甚至云上运行的一组工作人员
  • 一个数字存储库
  • 基于消息的中间件
  • 不同类别的任务，运行时间从 <1s 到 ~6hrs。任务是计算繁重的，而不是数据/IO 繁重的。预计任务量不会很大（据我现在所见）。大概最高100/分钟左右。

严格来说，没有必要移出 Windows 生态系统，但我会更愿意使用跨平台解决方案来保持选项开放（注意，某些任务仅适用于 Windows）。

我几乎已经将RabbitMQ作为消息传递层，Fedora-commons似乎是最成熟的现成存储库。至于我正在评估的主/从逻辑：

我查看了各种 IoC/DI 容器，但怀疑它们是否真的最适合任务执行容器并添加额外的层/复杂性。但也许我错了。

目前我倾向于使用 python 解决方案（保持轻量级），但我会对人们必须分享的任何经验/建议感兴趣，特别是对于 .net 堆栈。开源/可扩展性/弹性功能是加分项。

PS：未来更高级的需求将是用户能够直接连接到正在运行的任务（使用 Web UI）并影响其行为（实时转向）。为此需要一个直接的通信通道（通过 AMQP 执行此操作似乎不是一个好主意）。

4

1 回答 1

0

短剑

关于 master/worker 逻辑和 Java 选项。

Nimble（参见http://www.paremus.com/products/products_nimble.html）及其 OSGi 远程服务堆栈可能会提供一种有趣/敏捷的纯 OSGi 方法。您仍然必须决定特定的分发机制。但鉴于 USe Case 计算量大且数据精简，使用 Nimble RSA 附带的 Essence RMI 传输和简单的前端负载均衡器功能可能会非常有效。

“直接通信通道”的一个好方法是利用 DDS——这是一种低延迟发布/订阅对等消息传递标准——用于分布式命令/控制类型的环境。我认为某处有一个简单的 OSS 项目，但我们（Paremus）在该领域与 RTI 合作。

希望以上内容具有背景意义。

于 2011-02-18T13:14:11.307 回答