MSMQ между службами WCF в среде с балансировкой нагрузки - PullRequest
Новая
       51

MSMQ между службами WCF в среде с балансировкой нагрузки

2 голосов
/ 04 мая 2011

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

В основном я планирую, чтобы служба WCF для фасада называлась через http.Фасадная служба должна только записывать все входящие сообщения в очередь, чтобы дать быстрый ответ вызывающей системе.Сообщения в очереди должны затем обрабатываться другим компонентом, либо службой WCF, либо службой Windows, в зависимости от выбора очереди.

Продукт работает в среде с балансировкой нагрузки от 2 до n веб-серверов.

Варианты, которые я рассматриваю, и вопросы, которые я получил:

  1. Чтобы позволить фасадному WCF записывать в MSMQ, а затем иметь другое чтение службы WCF из этой очереди, чтобы выполнитьобработка сообщений.Что я не чувствую уверенности в этой альтернативе из того, что я прочитал, так это как она будет работать в среде с балансировкой нагрузки.

1А.Где должны быть размещены MSMQ?Один на каждом веб-сервере?Один на отдельном сервере?Несколько на отдельном сервере?(без учета необходимости избыточности и того, что в редких случаях данные могут быть потеряны и отправлены повторно)

1B.Как это повлияло на дизайн, если я хочу, чтобы система была избыточной?Я хотел бы иметь возможность потерять сервер (он больше никогда не подключится к сети), содержащий MSMQ, без потери данных в этой очереди.Из того, что я читал о MSMQ, я оставляю единственную возможность размещения MSMQ в кластере Windows.Это верно?(Я бы хотел избежать использования кластера Windows для этого).

  1. Вторая альтернатива проекта - позволить службе WCF фасада записывать очередь в базу данных.Затем подготовьте две или более служб Windows для обработки очереди.У меня нет вопросов по этой альтернативе.Если вы удивляетесь, почему я не выбрал этот вариант, так как он кажется мне более простым, то это потому, что я хотел бы создать его, не вводя никаких оконных сервисов в решение, поэтому я считаю, что MSMQ получил функциональность, которую я не хочусам кодирую, и мне также любопытно использовать MSMQ, поскольку я никогда не использовал его раньше.

С наилучшими пожеланиями Håkan

Ответы [ 2 ]

2 голосов
/ 04 мая 2011

ОК, поэтому вы не используете WCF с интеграцией MSMQ, вы используете WCF для создания сообщений MSMQ в качестве конечного продукта.Это упрощает вопрос о том, «как мне сбалансировать нагрузку MSMQ?»

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

Вам не нужно кластеризовать MSMQ, чтобы сделать его устойчивым.Вместо этого вы можете повысить устойчивость своего кода, чтобы он справлялся с потерянными сообщениями, используя очереди недоставленных сообщений, очереди транзакций, ведение журнала и т. Д.Аппаратная кластеризация является простой опцией: -)

0 голосов
/ 10 мая 2011

Прочитав еще несколько статей на тему, я решил не использовать MSMQ. Кажется, у меня действительно нет причин идти по этому пути. Мне нужно, чтобы это было не транзакционным, и, насколько я понимаю, ни один из методов ведения журнала или мертвой буквы не поможет мне с моим требованием к избыточности.

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

MSQM только усложнит захватывающее решение, другую технику и, возможно, другой сервер для отслеживания.

Чтобы получить полную избыточность для предотвращения потери данных в MSMQ, мне понадобится кластер Windows или реализация отправки / получения в несколько одинаковых очередей. Я не хочу делать ни того, ни другого.

Все это привело меня к тому, что мое приложение-получатель с фасадом WCF, принимающим вызовы http, записывал в очередь базы данных. Эта база данных уже защищена от потери данных. Очередь будет опрошена несколькими активными экземплярами службы Windows, содержащей всю сложную бизнес-логику. При низком приоритете процесса эти службы могут быть размещены на уже существующих узлах, используемых веб-приложением с балансировкой нагрузки. Если у меня есть время использовать MSMQ или мне это нужно по другой причине в моем заявлении, я могу изменить свое решение.

...