Тип ServiceBus — рекомендации по разделению очередей

Допустим, есть экземпляр служебной шины, работающий в одностороннем режиме. Служебная шина генерирует два типа сообщений: Foo и Bar. Оба этих типа сообщений должны быть сохранены в базе данных.

Поэтому я вижу два подхода для этого:

  1. Иметь две очереди (FooQueue, BarQueue) и два экземпляра шины (два процесса) — один для получения из FooQueue и один для получения из BarQueue

  2. Иметь одну очередь и один экземпляр шины с двумя обработчиками для сообщений Foo и Bar.

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

заранее спасибо


nservicebus rebus
person user1121956    schedule 17.09.2014    source источник
comment
Для начала может не иметь значения, чтобы одна конечная точка обрабатывала оба сообщения из одной очереди. Однако должно быть довольно просто установить конечную точку в качестве другого экземпляра и, используя конфигурацию, разделить обработку сообщений между двумя конечными точками/очередями с помощью маршрутизации. Я столкнулся именно с этим сценарием, когда нам потребовалась приоритетная обработка сообщений из внешнего интерфейса и более длинная очередь для внутренней обработки.   -  person Eben Roux    schedule 17.09.2014

Ответы (1)


arrow_upward
1
arrow_downward

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

Фактически, вы можете обойтись одним обработчиком, который реализует IHandleMessages<object>, если вы знаете, что конечная точка получает только те сообщения, которые должны быть сохранены.

person mookid8000    schedule 17.09.2014
comment
Спасибо за ответ. Я так понимаю, универсального шаблона для таких споров не существует, это просто вопрос ситуации? - person user1121956; 17.09.2014
comment
Кто-то может не согласиться, но да, мне нравится думать об этом :) - person mookid8000; 17.09.2014