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

Question

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

Детали:

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

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

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

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

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

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

Answer 1

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

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

Answer 2

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