Опыт работы с основами обмена сообщениями на основе сообщений (Java / Python / .Net) - PullRequest
1 голос
/ 17 февраля 2011

Я занимаюсь проектированием распределенной системы мастер-работник, которая, начиная с 10 000 футов, состоит из:

  • Веб-интерфейс пользователя
  • главного компонента, отвечающего за генерацию заданий в соответствии снастраиваемый набор алгоритмов
  • набор работников, работающих на обычных компьютерах, кластере HPC или даже в облаке
  • цифровое хранилище
  • промежуточное ПО на основе сообщений
  • различные категории задач, со временем выполнения от <1 с до ~ 6 часов.Задачи требуют больших вычислений, а не данных / ввода-вывода.Объем заданий не ожидается большим (насколько я вижу сейчас).Вероятно, максимальная скорость составляет около 100 / мин. </li>

Строго говоря, нет необходимости выходить за пределы экосистемы Windows, но мне было бы удобнее с кроссплатформенным решением, чтобы держать опции открытыми (nb. Некоторые задачитолько винда).

Я в значительной степени остановился на RabbitMQ в качестве слоя обмена сообщениями, а Fedora-commons представляется наиболее зрелым из имеющихся репозиториев.Что касается логики мастер / рабочий, я оцениваю:

Я просматривал различные контейнеры IoC / DI, но сомневаюсь, что онидействительно лучше всего подходят для контейнера выполнения задач и добавляют дополнительные слои / сложность.Но, возможно, я ошибаюсь.

В настоящее время я склоняюсь к решению на python (пусть оно будет легким), но мне было бы интересно узнать о любом опыте / предложениях, которыми люди могут поделиться, особенно со стеком .net.Функции с открытым исходным кодом / масштабируемость / устойчивость - это плюсы.

PS: более сложным будущим требованием будет возможность подключения пользователя непосредственно к запущенной задаче (с помощью веб-интерфейса) и влияние на ее поведение (реальное).время руля).Для этого потребуется прямой канал связи (выполнение этого через AMQP не кажется хорошей идеей).

1 Ответ

0 голосов
/ 18 февраля 2011

Dirk

Относительно логики мастер / работник и опции Java.

Проворный (см. http://www.paremus.com/products/products_nimble.html) с его стеком OSGi Remote Services, возможно, предоставит интересный / гибкий AgG чистый подход. Вам все еще нужно определиться с определенным механизмом распределения. Но, учитывая, что USe Case требует больших вычислительных ресурсов и данных -lite, использование транспорта Essence RMI, который поставляется с Nimble RSA с простой функцией балансировки нагрузки внешнего интерфейса, может работать очень хорошо.

Хороший подход к «прямому каналу связи» - это использование DDS - этот стандарт обмена сообщениями между публикациями и подписками с малой задержкой - используется в распределенных средах типа команд / элементов управления. Я думаю, что где-то есть проект OSS, но мы (Paremus) работаем с RTI в этой области.

Надеюсь, вышесказанное представляет интерес для фона.

...