Ребус - Множественные транспорты

Можно ли с помощью Rebus настроить более одного транспорта в приложении?

Нашей бизнес-сферой является обработка изображений, из-за потенциально большого размера обрабатываемых изображений я хотел бы использовать транспорт InMemory для связи в рамках одной службы (WebApi 2) для токенизации (Guid) и сохранения изображений для обработки в база данных.

Кроме того, после токенизации изображений мы хотели бы использовать транспорт RabbitMQ для отправки изображений для обработки в ImageProcessingService (консольное приложение - с использованием TopShelf) и ответа вызывающему приложению (WebApi) после завершения обработки.

Кажется, я не могу найти правильный способ обработки сценария, в котором я хотел бы использовать обмен сообщениями в приложении (WebApi) с использованием транспорта InMemory, а также иметь возможность отправки WebApi в ImageProcessingService через транспорт RabbitMQ.


rebus
person user1397197    schedule 17.09.2015    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Очевидно, я не знаю деталей вашей проблемы, но рассматривали ли вы возможность сохранения данных изображения в другом месте (сетевой ресурс, MongoDB GridFS, LOB-объект SQL Server и т. Д.)?

По моему опыту, все оказывается проще, если вы используете сообщения только для координации, а не столько для транспортировки фактического объема данных.

PS: В какой-то момент я экспериментировал с мультимодальным транспортом, который позволил вам сделать что-то вроде этого:

Configure.With(...)
    .Transport(c => c.Multi()
        .Add("amqp", t => t.UseRabbitMq(connStr, "rabbitqueue")
        .Add("inmem", t => t.UseInMemoryTransport(network, "inmemqueue"))
    .Start();

а затем укажите адреса в форме amqp://rabbitqueue и inmem://inmemqueue для адресации настроенной конечной точки через RabbitMQ и транспорты in-mem соответственно.

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

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

person mookid8000    schedule 17.09.2015
comment
разве введение мульти-транспорта не противоречит философии Rebus иметь только одну входную очередь? как это вообще будет работать - будет ли оно принимать одно сообщение из первого транспорта, одно из второго и так далее в цикле? Я мог представить себе такое использование, как .Add (msmq1) .Add (msmq2). Думаю, проще рассуждать о том, чтобы иметь отдельные автобусы для каждой очереди :) - person user1121956; 18.09.2015
comment
это то, что я имел в виду под этим, вызывает кучу вопросов ;-) но да, транспортная оболочка будет просто чередоваться между получением от каждого обернутого транспорта, а адрес возврата будет установлен в виде списка, разделенного точкой с запятой, всех адресов входной очереди, адресов конечной точки можно было найти, + еще кое-что, чтобы связать вещи вместе ... он действительно мог отправлять / получать сообщения, но все равно было бы много вопросов :) - person mookid8000; 18.09.2015