WCF Pub / Sub с кешированием подписчиков
Проблема:, как предоставить распределенную, масштабируемую и устойчивую к сбоям публикацию / подписку с помощью WCF.
Подробности:
Обратите внимание, что этот подход рассматривается в дополнение к решениям для обмена сообщениями / промежуточного программного обеспечения, таким как Tibco EMS.
Я изучал WCF, особенно то, как его можно использовать для предложения pub / sub. По этому поводу очень хороша эта статья: Паб-подписка WCF.
В статье автор пытается решить проблему наличия нескольких издателей (как если бы уровень сервиса был масштабирован на несколько блоков). Проблема в том, что если клиент A регистрируется на издателе A, но издатель B желает опубликовать событие, тогда издатель B не будет знать о клиенте A. т.е. никто не сообщил издателю B, что клиент A хочет получать уведомления о событиях. В качестве решения автор предлагает услугу pub / sub. Служба публикации / подписки будет централизованно хранить подписки. Однако, если я хотел сделать службу публикации / подписки устойчивой к сбоям за счет наличия вторичной / двойной службы публикации / подписки, то у меня возникнет та же исходная проблема.
Итак, я думаю, что есть несколько решений проблемы:
- Храните данные подписчика в распределенном кэше (см. Вопросы: q1 и q2).
- Храните данные подписчика в базе данных / центральной файловой системе.
Может ли кто-нибудь придумать какие-либо другие решения (т.е. я не пропустил какую-то фантастическую волшебную особенность WCF?) Любые комментарии приветствуются.
Ответы 2
У меня была та же проблема, и я провел много исследований по этой проблеме. Проблема на самом деле проста. Вы хотите сохранить какое-то централизованное состояние, но распределенным образом. Я обнаружил, что лучший способ добиться этого - использовать распределенный кеш. Посмотрите, например, на скорость. Я знаю, что не существует собственного решения WCF, которое могло бы решить проблему управления состоянием. Я даже изучал долговечные службы, в которых управление состоянием осуществляется WCF, однако это не подходит для службы публикации / подписки, поскольку состояние должно быть централизованным для всех клиентских подключений. Хранение данных в базе данных также является вариантом, но стоимость - необходимость в базе данных, и даже с базой данных вы можете иметь единую точку отказа, если база данных не кластеризована на нескольких машинах.
В конце концов, я решил, что реализовать что-то с нулевыми точками отказа на самом деле дорого, и если вы все же решите пойти туда, взгляните на Azure, будущее хранилища - в облаке, службы Azure будут полностью масштабируемыми и распределенными. , но мы еще не там.
Я думаю, что WCF просто еще нет. Что вам нужно, так это брокер, который обработает все эти детали за вас, чтобы вы могли просто реализовать свою бизнес-логику. Есть несколько очень хороших, таких как ActiveMQ. Если вам нужна оркестровка, вы, вероятно, захотите использовать автобус, который также может располагаться поверх брокера. Я думаю, что WCF - это замечательно, но пытаться превратить его во что-то не так - плохая идея.