Советы по созданию распределенного приложения? - PullRequest
2 голосов
/ 06 апреля 2010

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

Моя система будет состоять из веб-приложения центрального управления, в котором будут определены задачи, и нескольких исполнителей задач, которые будут установлены на разных компьютерах для обработки этих задач.

Что мне нужно выяснить, это как распределить задачи по клиентам? Должен ли я просто создать очередь задач, и исполнители задач постоянно опрашивают очередь, чтобы узнать, готова ли новая задача? Каков наилучший способ обеспечить выполнение задачи только одним исполнителем? Как я могу также обеспечить равномерное распределение задач между исполнителями задач, чтобы один из них не обрабатывал нагрузки, а другие обрабатывали только ручные операции?

Единственный другой подход, который я могу придумать, заключается в том, что каждый исполнитель задач устанавливает TCP-соединение с сервером и регистрирует свой интерес, а затем, когда новая задача готова, веб-приложение выбирает исполнитель задачи и переводит задачу на это обработчик задач для обработки?

У кого-нибудь есть другие идеи? указатели? или комментарии?

Большое спасибо

Мэтт

Ответы [ 3 ]

4 голосов
/ 06 апреля 2010

Общий подход к этой проблеме:

  • Реализация набора служб WCF, которые предоставляют функциональность «запуск задачи» как операции;

  • Развертывание служб WCF на нескольких хостах / машинах, размещенных как службы Windows (все они должны использовать один и тот же контракт);

  • Настройка служб WCF для использования привязки очереди сообщений Microsoft (netMsmqBinding), использующей одну и ту же очередь в режиме транзакций;

  • Настройка отдельных приложений управления для отправки своих запросов в очередь сообщений, используя те же netMsmqBinding;

  • При желании разверните приложения / службы управления в сети с балансировкой нагрузки, такой как IIS Web Farm (если вам нужна большая масштабируемость на внешнем интерфейсе).

Это, вероятно, самый удобный подход, поскольку вы можете положиться на проверенные инструменты для балансировки нагрузки (IIS / NLB), защиты и сериализации сообщений (WCF), а также для доставки сообщений и управления транзакциями (MSMQ). Большая часть работы уже сделана для вас.

Конечно, есть много оснований для фактического внедрения и развертывания, но это может быть слишком много материала, чтобы охватить его одним вопросом / ответом здесь. Это должно, по крайней мере, указать вам правильное общее направление.

2 голосов
/ 06 апреля 2010

+ 1 для Aaronaught, но я бы также посоветовал взглянуть на что-то вроде NServiceBus , которое может абстрагироваться от подробностей реализации. Вы по-прежнему можете использовать MSMQ и / или WCF для реальной транспортировки, просто упростив настройку издателей и подписчиков.

0 голосов
/ 06 апреля 2010

Некоторое время назад я написал нечто подобное и выбрал то, что мне показалось простым, почти таким же, как вы описали: каждый агент (исполнитель задач) регистрируется на «сервере управления» для целей администратора. Затем он периодически опрашивает сервер на предмет работы. Если в очереди есть что-либо, она берет первое (самое старое) задание. Сервер помечает эту работу как выполняющуюся, поэтому другие агенты не будут ее выполнять. Балансировка нагрузки не была проблемой, потому что каждый агент выполнял только 1 задание за раз. WCF очень хорошо позаботился об организации очереди сообщений, так что не было никакого беспокойства о двух агентах, выполняющих одну и ту же работу. Когда агент заканчивает работу, он сообщает серверу и передает обратно все выходные данные.

Я определил три конечные точки WCF для моего сервера управления: одну для агентов, одну для «консоли», используемой для отправки заданий (приложение winforms), и одну для инструмента администратора. Мой сервер управления был реализован в виде веб-службы, размещенной в службе Windows.

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

...