У меня есть небольшая проблема, чтобы решить, какой путь выбрать при проектировании потока сообщений в нашей системе.
Поскольку изменчивый характер наших бизнес-процессов (т. Е. Вычисление затрат на перевозку) мы используем, чтобывозможность изменять процесс на лету.
Общий процесс должен выглядеть примерно так: 
Интерфейс - это сервис, который подключается к системе клиента через любой интерфейс, предоставляемый клиентом (webservices, tcp).конечные точки, опрос базы данных, файлы, вы называете это).Затем отправляется команда исполнителю, содержащая полученные данные и идентификатор рабочего процесса, который необходимо выполнить.
Первая проблема возникает в том месте, где мы хотим распределить нагрузку на нескольких рабочих.услуги.
Скажем, у нас есть разные процессы, такие как печать посылок, расчет цены, отправка уведомлений.Печать этикеток никогда не должна задерживаться, поскольку выполняется тонна почтовых рабочих процессов.Поэтому мы хотим иметь возможность направлять команды различным работникам в зависимости от выполняемой ими работы.
Поскольку все команды похожи на «выполнить рабочий процесс XY», нам потребуется реализовать нашу собственную маршрутизацию на основе содержимого.NServicebus не поддерживает это из коробки, в большинстве случаев, потому что это анти паттерн.
Есть ли лучший способ сделать это, когда вы не можете использовать разные типы сообщений для маршрутизации ваших сообщений?
Вторая проблема приходит, когда мы хотим добавить мониторинг.Поскольку конечная точка может подписаться только на одну очередь для каждого типа сообщений, мы не можем позволить всем исполнителям просто опубликовать сообщение «Я завершил рабочий процесс».Текущее решение будет Bus.Send сообщение в предварительно настроенную конечную точку аудита.Это похоже на мошенничество;)
Есть ли лучший способ снова объединить опубликованные сообщения нескольких работников в одну очередь?Если бы не было проблемы # 1, я думаю, что все работники могли бы использовать одну и ту же очередь ввода, однако это невозможно в этом сценарии.