Справка по дизайну NServiceBus (инициализация экземпляра сервиса сообщениями)

Question

Я ищу альтернативный дизайн или, возможно, обойти эту проблему, с которой я столкнулся при обмене сообщениями MSMQ.Прямо сейчас я использую NServiceBus (не проблема) для моей сервисной архитектуры.Это работает очень хорошо, и мне это очень нравится.Однако у меня возникли проблемы со службами, которые я хочу инициализировать при запуске перед обработкой сообщений обычной рабочей нагрузки.Позвольте мне объяснить мою ситуацию.

Допустим, у меня есть 2 службы, доступ к данным (DA) и обработчик (PE).

PE выполняет 2 задачи:

1. Загрузка некоторой информации о конфигурации из DA.
2. Обработка входящих клиентских запросов.

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

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

Answer 1

Вы действительно должны рассмотреть возможность загрузки конфигурации в каждой службе, которая в этом нуждается. Что касается обходных путей, вы можете отправить сообщение-запрос другой конечной точке для конфигурации и затем продолжать вызывать Bus.HandleCurrentMessageLater () до тех пор, пока вы не получите обратно коррелированный ответ. Это не будет оптимальным, так как сообщения, не относящиеся к конфигурации, будут накапливаться в очереди до тех пор, пока не произойдет конфигурация.

Answer 2

каждая служба должна отвечать за свои данные. поэтому ваш процессор должен знать точные параметры конфигурации, необходимые для правильной работы. кажется, что вы путаете некоторые вещи, и у вас есть сервис, который использует 2 сервиса Windows, где один сервис зависит от другого сервиса.

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

Я бы порекомендовал пересмотреть вашу архитектуру.

Answer 3

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

Тем не менее, я вообще не понимаю вашу архитектуру. Как служба DA узнает, что PE перезапустился. Это необходимо знать, чтобы отправлять сообщения о конфигурации.

Answer 4

Вы смотрели на дистрибьютора? Также посмотрите на ICustomConfigurationSource, который вы можете использовать для получения конфигурации конечной точки при запуске службы Windows (до того, как она начнет обрабатывать сообщения)