Постоянный обмен сообщениями / служебная шина - накатить мне или рискнуть?

Question

У нас есть клиентское приложение, которое должно отправлять сообщения на сервер для получения различных уведомлений. Для того, чтобы клиент мог запускать время от времени подключенный, я собираюсь пойти с подходом очереди сообщений. При обработке очереди сообщения удаляются из очереди и вызывают веб-службу, которая помещает их в другую очередь для окончательной обработки. Этот вопрос о клиентской среде; среда сервера уже определена.

Я не хочу использовать MSMQ, потому что у нас нет контроля над всеми клиентскими ПК для правильной установки / настройки и защиты MSMQ, а также потому, что поддержка более сложна из-за качества инструментария для исследования содержимого MSMQ очередей. SQL Server 2005 Express установлен на всех компьютерах и используется для хранения данных для нашего приложения.

У меня сейчас есть два варианта:

1. Напишите довольно простую постоянную очередь сообщений, в которой после сериализации хранятся сообщения в таблице, а затем используется ThreadPool.QueueUserWorkItem для их обработки обработчиками, настроенными для каждого типа сообщений. Все в System.Transactions.TransactionScope, поэтому они удаляются из постоянной очереди только в случае успешной обработки.
2. Используйте NServiceBus (это сервисная шина, с которой мы работали как команда, поэтому MassTransit и т. Д. Не являются опциями) на клиенте с транспортом Service Broker, который использует локальную базу данных.

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

У кого-нибудь есть мысли?

Answer 1

Ну, я не знаю, что я собираюсь предложить MSMQ, но я предположу, что есть много крайних случаев, о которых нужно подумать, чтобы «свернуть свое».

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

Вам также необходимо подумать о сохранности сообщений и о том, как долго они должны существовать, как определить «фатальный» статус недоставки и что делать в этом случае.

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

Почему бы просто не определить приложение, когда оно подключается, и отправить все данные в этот момент?

Answer 2

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

То, будете ли вы кататься самостоятельно, также зависит от навыков, которыми вы владеете, и которые у вас будут в будущем для поддержки решения.

Еще одним соображением является возможный масштаб системы и требования к ее надежности. Будет ли внутреннее решение масштабироваться в достаточной степени?

Наша одноранговая шина сообщений Zebus на основе ZeroMq (транспорт), Cassandra (одноранговое обнаружение и сохранение) и Protobuf (сериализация).

1. Нет развертывания клиента, так как на клиенте это просто библиотека
2. Постоянство сообщений также предоставляется с использованием Cassandra и обрабатывает множество различных крайних случаев (это регулярно проверяется в нашей производственной среде)
3. Работает хорошо, и, поскольку это решение без брокера, нет единого узкого места в производительности
4. Нет единой точки отказа, поскольку Справочник можно использовать с доступным хранилищем данных, таким как Cassandra

Это открытый исходный код и тестирование производства https://github.com/Abc-Arbitrage/Zebus

Answer 3

В конце я написал базовую шину сообщений, сконфигурированную с моим собственным SqlTransport, так что сообщения сериализуются и сохраняются в таблице базы данных SQL Server до того, как будут созданы события, и для обработки сообщений будет подан отдельный поток.