Будет ли NServiceBus быть правильным выбором для нашего приложения?

Question

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

Благодаря CQRS я узнал о NServiceBus, но не рассматривал его подробно.

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

Итак, какие преимущества я бы получил от асинхронности, и будет ли NServiceBus подходящей платформой? Как я могу убедить их, что архитектура обмена сообщениями asnyc - это путь, если это в нашем случае? Или я представляю фреймворк, который не нужен?

Answer 1

Ну, старая изречение «Если ничего не сломалось» ... вступает в игру здесь.

Если серьезно, если нет причин «что-то исправлять» (например, проблемы доступности или потери данных), очень сложно создать аргумент для его изменения.

Чтобы немного ответить на ваш вопрос, по моему опыту, одним из основных преимуществ NServiceBus является низкая стоимость владения. Его легко подбирать, изучать, развертывать, а после запуска он не требует больших затрат на управление.

UPDATE

RE: комментарий об отображении результатов звонка пользователям:

Это зависит от того, как вы хотите играть в нее.

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

Однако, если вызов выполняет серьезную обработку, которая может привести к задержке, или если вызов имеет «естественно» высокую вероятность сбоя, вы можете выбрать отображение сообщения «спасибо за ваш запрос» пользователю и затем предупредите их о результате вызова с помощью некоторых автономных средств (таких как электронное письмо со ссылкой на ответ).

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