ServiceStack: заменете уеб услуга с опашка от съобщения

Работя по проект, който предоставя API за получаване на информация за продуктите на нашите партньори.

Всяка заявка за търсене към нашия сайт трябва да направи n други заявки към партньорски сайтове, да събере и обобщи данни за продукти, така че може да отнеме много време.

В момента изпитваме някои проблеми с производителността поради блокиращата услуга REST и търся по-добро решение за организиране на нашата платформа за търсене на продукти.

Както видях, ServiceStack RedisMQ може да осигури асинхронно решение за дългосрочни комуникации. Но имам някои въпроси (защото нямам много опит с MQ):

  1. Как мога да заменя REST услуга с MQ
  2. Как мога да получа информация от MQ на уеб страница (с REST мога да използвам всяка подходяща JS lib като jQuery и да правя ajax заявки)
  3. Как мога да организирам MQ API за моята услуга вместо REST, който може да се използва от нашите клиенти (на техните сайтове).

.net rest message-queue
person shadeglare    schedule 09.06.2013    source източник
comment
Пробвал ли си TPL. Например, Parallel.Invoke(()=>SearchSite1(),()=>SearchSite2());   -  person I4V    schedule 09.06.2013
comment
да но тези искания наистина могат да отнемат много време.   -  person shadeglare    schedule 10.06.2013

Отговори (1)


arrow_upward
1
arrow_downward

Не съм сигурен какъв език използвате, така че ще се опитам да бъда езиков агностик.

Бих предложил да накарате приложението си да "поточно" данните обратно, вместо да чакате блокиращото спокойно повикване да се върне. Всички партньорски „извличания“ трябва да бъдат изпълнени като асинхронно обратно извикване. Когато резултатите пристигнат, можете да пишете обратно в потока.

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

person JVXR    schedule 30.07.2013