NServiceBus & IoT - поместите сообщение от клиента прямо в очередь и обработайте с помощью NServiceBus на стороне сервера

Внешний вид написан на .NET с использованием NServiceBus (версия 5). До сих пор наши клиенты (как клиенты .NET, так и клиенты C ++) отправляли сообщения в службу WCF с NServiceBus, а служба WCF отправляла сообщение NServiceBus нужному исполнителю.

Прямо сейчас мы вносим некоторые изменения в нашу архитектуру и хотели бы, чтобы некоторые клиенты помещали сообщения прямо в очередь и пропускали WCF. У нас много устройств (большинство написано на C ++).

Я знаю, что NServiceBus обертывает сообщения, которые он помещает в очередь, собственным объектом. Мой вопрос: есть ли способ для NServiceBus работать в средах IoT - где устройства помещают сообщения непосредственно в очередь, без адаптера посередине? или на стороне сервера (worker) для обработки «обычных» сообщений, не обернутых объектом NServiceBus?


person developer82    schedule 30.08.2015    source источник
comment
какой транспорт ты используешь?   -  person Simon    schedule 30.08.2015
comment
@Simon, мы сейчас переделываем нашу архитектуру. в настоящее время это msmq, но мы переходим либо на RabbitMQ, либо на Azure ServiceBus.   -  person developer82    schedule 31.08.2015


Ответы (3)


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

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

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

Чтобы ответить на ваш вопрос: для интеграции с NSB из вашего кода C ++ вы можете перевести этот код C # на C ++, и это все, что вам нужно:

public static void SendMessage(string queuePath, string messageBody, List<HeaderInfo> headers)
{
    using (var scope = new TransactionScope())
    {
        using (var queue = new MessageQueue(queuePath))
        using (Message message = new Message())
        {
            message.BodyStream = new MemoryStream(Encoding.UTF8.GetBytes(messageBody));
            message.Extension = CreateHeaders(headers);
            queue.Send(message, MessageQueueTransactionType.Automatic);
        }
        scope.Complete();
    }
}

public static byte[] CreateHeaders(List<HeaderInfo> headerInfos)
{
    XmlSerializer serializer = new XmlSerializer(typeof(List<HeaderInfo>));
    using (var stream = new MemoryStream())
    {
        serializer.Serialize(stream, headerInfos);
        return stream.ToArray();
    }
}

public class HeaderInfo
{
    public string Key { get; set; }
    public string Value { get; set; }
}

На заметку:

  • MSMQ работает с TransactionScope. Я не думаю, что в IoT это вариант, зависящий от используемого вами устройства.
  • Вам все еще нужна библиотека, чтобы поместить сообщение в MSMQ.

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

person Hadi Eskandari    schedule 30.08.2015

Алексей, разве ты не предлагаешь добавить по одному хопу на каждое сообщение. Если это так, почему бы просто не получить HTTP-вызов от IoT-устройства в облако. Обработчик HTTP просто поместит его в очередь, используя клиентскую библиотеку NServiceBus. Используя обработчик HTTP, у меня будет лучший вариант изменить внутреннюю реализацию (следовательно, очередь) в будущем.

person Erez Bar-Tal    schedule 30.08.2015
comment
Это так, но каждый, кто действительно работает с устройствами, сказал бы вам, что когда у вас есть миллионы сообщений в секунду, вы не можете позволить себе иметь килобайты мусора в своем сообщении, а накладные расходы XML считаются ненужным хламом. Надежная консолидация сообщений и передача их в механизм обработки - отдельная задача. Например, для этого используется Azure EventHub. - person Alexey Zimarev; 31.08.2015

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

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

Я использую AQMP для обмена сообщениями между концентратором событий и устройствами. Затем в концентраторе событий я могу делать все, что хочу, в том числе с помощью NServiceBus. Подумайте, что предлагает индустрия для устройств. Вероятно, вам нужен AQMP.

person Alexey Zimarev    schedule 30.08.2015