使用基于消息的主工作框架(Java/Python/..Net)的经验

Question

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

• 基于Web的用户界面
• 一个主组件，负责根据一组可配置的算法生成作业。
• 运行在普通pc、HPC集群或甚至云上的一组工作人员
• 数字存储库
• 基于消息传递的中间件
• 不同类型的任务，运行时间从< 1s到~6小时不等。任务是计算量，而不是数据/IO量。任务的数量预计不会很大(就我现在所见)。大概在100/分钟左右。

严格地说，不需要迁移到Windows生态系统之外，但我更愿意使用跨平台解决方案来保持选项开放(nb )。某些任务仅适用于Windows )。

我认为RabbitMQ是一个消息层，而软呢帽-公域似乎是最成熟的现成存储库。至于主/工逻辑，我正在评估：

• 基于Java的：砂砾 + Postgres + DOSGi或带动物园管理员的GridGain
• 基于Python的：姜戈 + Postgres + 芹菜
• 基于.NET的：ASP.NET MVC + Server + NServiceBus + Sharepoint或泽实体作为存储库

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

目前，我倾向于使用python解决方案(保持轻量级)，但我会对人们必须共享的任何经验/建议感兴趣，特别是在.net堆栈中。开源/可伸缩性/弹性特性更佳。

PS:更高级的未来需求将是用户能够直接连接到正在运行的任务(使用web )并影响其行为(实时指导)。要做到这一点，需要一个直接的沟通渠道(在AMQP上这样做似乎不是个好主意)。

Answer 1

德克

关于主/工作逻辑和Java选项。

灵活(参见nimble.html)及其OSGi远程服务堆栈可能提供一种有趣的/敏捷的纯OSGi方法。你还得决定一个具体的分配机制。但是，考虑到USe的计算量很大&数据少，使用灵活的RSA附带简单的前端负载均衡器功能的本质RMI传输可能会工作得很好。

实现“直接通信通道”的一个好方法是利用DDS --这是一种低延迟发布/订阅对等消息传递标准--用于分布式命令/控制类型环境。我认为有一个赤裸裸的开放源码软件项目某处，但我们(帕累姆斯)与RTI在这方面的工作。

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