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

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

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

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

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

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

Есть у кого мысли?


.net servicebus message-queue
person Neil Barnwell    schedule 06.05.2009    source источник

Ответы (3)


arrow_upward
2
arrow_downward

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

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

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

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

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

person kyoryu    schedule 23.12.2009

arrow_upward
2
arrow_downward

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

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

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

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

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

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

person Slugart    schedule 13.05.2016

arrow_upward
0
arrow_downward

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

person Neil Barnwell    schedule 13.10.2009