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

Question

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

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

В настоящее время у меня есть два варианта:

<Ол>

Напишите довольно простую постоянную очередь сообщений, в которой после сериализации будут храниться сообщения в таблице, а затем используется ThreadPool.QueueUserWorkItem для их обработки обработчиками, настроенными для каждого типа сообщений. Все в System.Transactions.TransactionScope , поэтому они удаляются из постоянной очереди только в случае их успешной обработки.

Используйте NServiceBus (это сервисная шина, с которой мы работали как команда, поэтому MassTransit и т. д. не являются опциями) на клиенте с транспортом Service Broker, который использует локальную базу данных.

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

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

Answer 1

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

Answer 2

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

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

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

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

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

Answer 3

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

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

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

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

<Ол>

Нет развертывания клиента, так как на клиенте это просто библиотека

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

Он работает хорошо, и поскольку это решение без брокера, не существует единого узкого места в производительности

Единственных точек сбоя нет, так как Справочник можно использовать с доступным хранилищем данных, таким как Cassandra

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