IWantToRunWhenBusStartsAndStops не для производства?

Question

Новое в NServiceBus (4.7.5) и только что реализовало хостинг-сервер NSB host.exe (реализующий IWantToRunWhenBusStartsAndStops), который обнаруживает изменения в таблицах базы данных и уведомляет подписные веб-приложения, публикуя события, например. "CustomerDataWasUpdatedEvent". В будущем мы будем выполнять фактическое обновление с помощью обработчиков сообщений, получающих команды, очевидно, но на данный момент эта служба публикации просто опросает базу данных и т. Д.

Все работает хорошо, однако, приближаясь к производству, я заметил, что Дэвид Бойке в своем в последнем выпуске «Learning NServiceBus» говорится, что классы, реализующие IWantToRunWhenBusStartsAndStops, в основном предназначены для разработки и редко используются в производстве. Я установил обнаружение изменений базы данных в методе «Пуск», и он работает хорошо, кто-нибудь знает, почему это не рекомендуется?

Вот комментарий в реальной книге:

https://books.google.se/books?id=rvpzBgAAQBAJ&pg=PA110&lpg=PA110&dq=nservicebus+iwanttorunwhenbusstartsandstops+in+production+david+boike&source=bl&ots=U6sNII0nm3&sig=qIXffOVFhcy-_3qDnSExRpwRlD4&hl=sv&sa=X&ei=lHWRVc2_BKrWywPB65fIBw&ved=0CBsQ6AEwAA#v=onepage&q=nservicebus%20iwanttorunwhenbusstartsandstops%20in%20production%20david%20boike&f=false

Answer 1

я скопирую ответ, который я дал в Particular Software Google Group ...

---

Я процитирую себя прямо здесь:

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

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

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

Позвольте мне рассказать вам, как я это испортил в своей первой в истории системе NServiceBus. Система (все еще используемая сегодня, из того, что я слышу) несет ответственность за глотание более 3000 RSS-каналов (вероятно, намного больше, чем сейчас) в CMS. Поэтому обрабатывайте каждый канал, разбивая его на элементы, изменяя размер изображений, кодируя прикрепленное видео для мобильных устройств ... все эти вещи обрабатывались обработчиками сообщений NServiceBus, которые были масштабированы на несколько серверов, и это было фантастически.

Проблема заключалась в планировщике. Я реализовал это как IWantToRunWhenBusStartsAndStops (ну, на самом деле IWantToRunAtStartup в то время), и он быстро превратился в беспорядок. Я сохранил всю информацию о количестве фишек в памяти, чтобы я мог рассчитать, когда следует отменить следующую команду ProcessFeed. Я использовал класс .NET Timer и IIRC, мне в конечном итоге пришлось использовать примитивы с потоками, такие как ManualResetEvent, чтобы координировать действия. И поскольку я использовал .NET Timer, если планировщик выбрал исключение, эта конечная точка не удалась и должна была перезапуститься. Много странных краевых случаев, и это всегда было трясиной ошибок. Кроме того, это было теперь однопользовательское «приложение-командир», поэтому, когда процессоры feed/item можно было масштабировать, планировщик не смог.

Как я получил больше опыта с NServiceBus, я понял, что каждый фид должен был быть сагой, начиная с события FeedCreated, управляемого командами PauseProcessing и ResumeProcessing, используя таймауты для управления следующим временем обработки и, наконец, (возможно) закончился через событие FeedRemoved. Это было бы намного проще, и все было бы выполнено внутри обработчиков сообщений, управляемых транзакциями.

Этот опыт заставил меня быть немного недоверчивым/скептически относиться к IWantToRunWhenBusStartsAndStops. Не сказать, что это плохо, просто что-то, о чем нужно знать. Всегда будьте готовы к тому, чтобы сделать то, что вы пытаетесь сделать, не может быть лучше достигнуто по-другому.

Answer 2

Фактическая цитата:

... это не распространено иметь широкое применение в производственной системе ,

Uncommon - это не то же самое, что и обескураженный.

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

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

Хорошо, может быть, это как раз такой сценарий у нас есть, что немного необычно

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

Кроме того, сам Давид часто травит тэг nservicebus, возможно, он предоставит более окончательный ответ, чем мой.