WCF Pub / Sub с кэшированием подписчиков

Question

Проблема: как предоставить распределенный, масштабируемый и устойчивый к катастрофам сервис pub / sub с помощью WCF.

Подробные сведения:

Обратите внимание, что этот подход рассматривается в дополнение к решениям обмена сообщениями / промежуточного программного обеспечения, таким как Tibco EMS.

Я изучал WCF, в частности, как его можно использовать для предложения pub / sub.На эту тему эта статья очень хороша: Паблик WCF-sub.

В статье автор пытается решить проблему наличия нескольких издателей (как это было бы с уровнем сервиса, масштабируемым по нескольким блокам).Проблема в том, что если клиент A регистрируется у Издателя A, но Издатель B желает опубликовать событие, то издатель B не будет знать о клиенте A.т. е.никто не сказал издателю B, что клиент A хочет получать уведомления о событиях.Автор предлагает в качестве решения сервис pub / sub.Служба pub / sub будет централизованно хранить подписки.Однако, если бы я хотел сделать службу pub / sub устойчивой к сбоям, используя вторичную / двойную службу pub / sub, то у меня возникла бы та же исходная проблема.

Итак, я думаю, что есть пара решений этой проблемы:

1. Храните сведения о подписчике в распределенном кэше (см. Вопросы: q1 и q2).
2. Храните сведения о подписчике в базе данных / центральной файловой системе.

Кто-нибудь может придумать какие-либо другие решения (т.е.Я не пропустил какую-нибудь фантастическую волшебную функцию WCF?) Любые комментарии приветствуются.

Answer 1

У меня была такая же проблема, и я провел много исследований по этому вопросу.Проблема на самом деле проста.Вы хотите сохранить какое-то централизованное состояние, но распределенным способом.Я обнаружил, что лучший способ достичь этого - использовать распределенный кэш.Посмотрите, например, на скорость.Насколько я знаю, не существует собственного решения WCF, которое могло бы решить проблему управления состоянием.Я даже изучил долговременные сервисы, где управление состоянием осуществляется WCF, однако оно не подходит для службы pub / sub, потому что состояние должно быть централизовано для всех клиентских подключений.Хранение данных в базе данных также является вариантом, но стоимость связана с необходимостью наличия базы данных, и даже при наличии базы данных у вас может быть единая точка отказа, если база данных не кластеризована на нескольких компьютерах.

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

Answer 2

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