NServiceBus: обмен сообщениями DLL

Question

Я недавно изучал NServiceBus, так как думал, что обмен сообщениями будет хорошим способом уменьшить зависимости между системами. Однако одна из первых вещей, которые меня поразили, заключается в том, что издатель сообщений и все подписчики должны совместно использовать DLL определения сообщений. Что будет в этом сценарии?:

Скажем, есть одна центральная система, которая обрабатывает данные клиента. Всякий раз, когда запись клиента изменяется, он публикует сообщение, содержащее имя и адрес. Это имеет десять подписчиков, которые обновляют свою локальную копию данных при получении сообщения.

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

Будут ли все девять других подписчиков оставаться неизменными? Будут ли они работать в обычном режиме со старой библиотекой сообщений или все они должны быть обновлены новой DLL, перекомпилированы и выпущены?

Answer 1

Архитектура NServiceBus разработана таким образом, чтобы она была устойчивой к изменениям структуры сообщений (особенно там, где изменения включают добавление информации, как в вашем сценарии). См. Страницу образца версий на сайте NServiceBus.

Answer 2

Это не тот случай, когда вы можете управлять версиями в NSB, как они описывают в примере управления версиями.

Вы можете сделать это, если внедряете NSB в сценарии отправки / получения. В этом случае, несмотря на то, что контракт является DLL-библиотекой сообщений, нет необходимости делить одну и ту же версию DLL между отправителями и получателями. Это потому, что предоставление XML на проводе чисто десериализовано на приемном конце, все будет хорошо.

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

Когда ваш подписчик запускается, он отправляет сообщение подписки издателю, который затем вводит подписку в хранилище данных подписки. Эта подписка предназначена для сообщений, созданных в конкретной версии сборки.

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

Вы должны знать об этой жесткой зависимости в сценарии pub-sub.

Надеюсь, это поможет.

Редактировать

Начиная с версии 3.x NServiceBus, если основная версия сборки сообщений является общей для издателя и подписчика, pub-sub будет работать в обычном режиме.