2

Я понимаю, что Webjob является фоновым заданием, и Webapp может вызывать его через очередь Azure. Вопрос: если Webjob завершается, как Webapp может узнать, что Webjob завершен, и как Webapp может получить результаты, созданные Webjob?Как Azure Webjob возвращает результаты webapp?

Есть ли какой-либо метод asyn, который может работать в этом сценарии? Другие методы также приветствуются.

Благодаря

Дерек

---------------- ------------------- Обновление -----

Может ли метод «ListQueuesSegmentedAsync» работать? Но я понятия не имею, как его использовать.

+0

ListQueuesSegmentedAsync: http://stackoverflow.com/q/31788798/4148708, но я не понимаю, зачем вам это нужно. Зачем вам нужно открытие, если вы сами создаете имена очередей? Посмотрите на Table Storage или Redis, чтобы сохранить состояние, если оно становится слишком сложным, хотя это, вероятно, не будет вести себя так же элегантно, как система очередей. – evilSnobu

+0

Redis теперь может делать pub/sub, стоит посмотреть - http://redis.io/topics/pubsub – evilSnobu

ответ

1

Вы уже знаете ответ! Очередь сообщений!

Если вам нужно больше, чем несколько килобайт для сообщения (возможно, вы хотите передать файл JPEG), отбросьте это в хранилище Blob и сообщите веб-приложению/WebJob с сообщением о очереди, указывающим полный путь к недавно полученному blob ,

Более подробной информации о реализации очередей ориентированного рабочего процесса, см моего другого ответа здесь:
https://stackoverflow.com/a/38036911/4148708

Иногда, если хранение состояния не является вашим первым беспокойством, что может быть проще реализовать систему, где WebJob вызывает аутентифицированную конечную точку REST в данных WebApp для GET/POST.

Нет серебряной пули. Каждый сценарий имеет тенденцию немного отличаться и может выиграть от простоты, а не от долговечности (REST vs durable message queue).

О, и так как ты специально просить асинхронном, вот один из способов сделать это для REST (Очереди асинхронной по своей природе):

  • Вызовите REST конечной точки из вашего WebJob
  • Return 202 Accepted (как в я вам, но отчет TPS еще не готов)
  • Возвращение Location: https://webapp/{a-chunk-of-sha1-representing-a-unique-id} (точка этого заголовка, чтобы сообщить WebJob Установите этот флажок URL время от времени, чтобы захватить готовый отчет TPS)
  • У вас есть аккаунт, 417 Expectation Failed. На самом деле HTTP 417 является supposted для использования в ответ на 100 Continue, но вы никогда не использовать, что поэтому я замедляя кампанию для 417 Expectation Failed, чтобы конкурировать с словечками, как упругой и разрушительных. Но я отвлекся.
+1

Ключевой вопрос - как «сигнализировать веб-приложение/веб-приложение с сообщением о очереди»? Webapp помещает сообщение в очередь, которая затем передает Webjobs.Может ли Webjobs поместить сообщение в одну очередь? Спасибо – derek

+0

Конечно, это может быть, но это затруднит отслеживание. Используйте ** Queue # 1 для App -> Job ** и ** Queue # 2 для Job -> App **. Затем вы узнаете, что и что еще важнее, какой компонент отключен (так как больше не потребляет сообщения). В противном случае вам придется отправлять PeekLock каждое сообщение, чтобы проверить «Эй, это для меня или для WebJob?». – evilSnobu

+0

Если у меня работает 10 веб-приложений, и если мы используем вторую очередь, чтобы передать все результаты из Webjob в Webapp, Webjob будет извлекать каждое сообщение, чтобы проверить, соответствует ли он правильному Webjob. Во время процесса проверки сообщения будут удалены из очереди, правильно? – derek

 Смежные вопросы

  • Нет связанных вопросов^_^