Архитектурные шаблоны Pub / Sub Scaling и аварийного восстановления - PullRequest
2 голосов
/ 20 марта 2009

У нас будет исходная система, передающая сообщения через совместимую с JMS инфраструктуру pub / sub. Для большинства опубликованных сообщений подписчики будут приложениями с графическим интерфейсом, обновляющими экран с данными в сообщении.

Однако одним из подписчиков будет услуга перевода. Для определенных опубликованных сообщений служба перевода переведет сообщение в другой формат и опубликует его во вторичной инфраструктуре обмена сообщениями, принадлежащей другой части предприятия.

Как я могу масштабировать свой переводческий сервис и в идеале обеспечить активно-активную отказоустойчивость? Некоторые заметки:

  • Сообщения должны быть опубликованы во вторичной инфраструктуре обмена сообщениями по порядку.
  • Сообщения должны публиковаться только один раз во вторичной инфраструктуре обмена сообщениями.

Как я могу убедиться, что на сообщения отвечает только 1 подписчик службы переводов? Нужно ли переключаться на систему, основанную на очереди (но моему графическому интерфейсу все еще потребуется семантика pub / sub)?

Обратите внимание, что служба перевода поставит на ставку приложение .Net 3.5, размещенное в Windows Server 2003. У нас есть BigIP LTM / GTM сети F5.

Требуются дополнительные сведения, пожалуйста, задавайте / комментируйте.

Заранее спасибо.

Ответы [ 2 ]

0 голосов
/ 12 февраля 2010

Посмотрите на надежный обмен сообщениями в wcf. Возможно, это поможет

0 голосов
/ 20 марта 2009
...