Разработка архитектуры издателя / подписчика - PullRequest
0 голосов
/ 23 января 2012

Мне было интересно, смогу ли я получить некоторые соображения, основанные на следующих требованиях: - Сервис, который опрашивает таблицу журнала в нескольких базах данных на предмет изменений, а затем публикует уведомления для любого количества облегченных клиентов, работающих на различных ПК. - СообщениеОтправленный будет небольшим и будет содержать только данные о, возможно, временной отметке события и характере события.-Я хочу, чтобы установка настольного клиента на ПК была очень простой, поэтому не хочу, чтобы он сильно зависел от сторонних компонентов, кроме .net 4. Framework.

Вот мои собственные мысли на данный момент: у меня естьпоиграл с NServicebus, и это, кажется, соответствует счетам того, что я хочу.Я думал о том, чтобы опросить каждую базу данных для опроса в издателе, используя некие асинхронные методы, а затем создать сообщения, которые затем получат подписчики (клиент).Не слишком ли Nservicebus для этого? На данный момент я не требую, чтобы клиенты ничего не делали, кроме как слушали и получали сообщения, чтобы они на самом деле ничего не отправляли обратно.Я понимаю, что если бы я должен был установить NServicebus, тогда MSMQ и другие биты должны были бы быть установлены на каждом клиенте.Надеюсь, они не жадны до ресурсов.Я немного прочитал и загрузил кусочки кода, чтобы поиграть, но на самом деле у меня нет большого опыта в этой области, поэтому любые советы полезны.

Ответы [ 3 ]

1 голос
/ 23 января 2012

Бесплатная лицензия NServiceBus позволяет использовать только одну машину с 4 или менее ядрами ЦП для производственного использования.Это означает, что вы не можете иметь распределенную модель с этой лицензией *.В зависимости от ваших потребностей, вам может потребоваться приобрести коммерческую лицензию.

NServiceBus - очень самоуверенный фреймворк.Если вы подумываете об этом, я бы посоветовал сделать всплеск, чтобы понять, насколько сложно реализовать нужную вам функциональность.Вы, вероятно, сочтете это либо очень простым (вы делаете это способом NServiceBus), либо очень разочаровывающим.

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

Мне нравится RabbitMQ (у него есть клиент .NET);рассмотрите возможность оценки, чтобы увидеть, соответствует ли он вашим потребностям.Он не делает все, что делает NServiceBus, но вам могут не понадобиться дополнительные функции.

PS Если кто-нибудь предложит Rhino Service Bus, поверните и уходите.Даже автор признает, что документация "... не говоря уже о том, чтобы сказать наименее".

* Отказ от ответственности - я не юрист.

1 голос
/ 23 января 2012

То, что вы описываете, может быть достигнуто с помощью чистой среды .NET ... ИМХО NServiceBus довольно "слишком много" для того, что вы описываете ...

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

Что касается части с БД:

Вы не говорите, что это за БД ... но некоторые БД (например, SQL Server 2008, Oracle и т. Д.) Поставляются с механизмом событий / уведомлений, который делает часть опроса устаревшей ...

0 голосов
/ 23 января 2012

Лично я думаю, что это случай с какой-то ESB. Выгода от использования установленного ESB (такого как MSMQ, который использует NserviceBus) состоит в том, что вы получаете такие вещи, как устойчивость сообщений.

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

...