Рекомендации по созданию и масштабированию очередей Azure
Я изучаю архитектуру для высокопроизводительного веб-приложения (, теоретического на данный момент )в Windows Azure, и хотел порассуждать о «очередях Windows Azure (, а не SB )» и о том, как лучше всего масштабировать/создавать их.
В основном я рассматриваю MVC front -end (Web Role ), Windows Azure Queues (развязку асинхронных сообщений ), Worker Role и затемненную базу данных SQL.
Насколько я понимаю, мы получаем сообщение в веб-роли, а затем передаем его в очередь,рабочая роль будет опрашивать очереди {делать работу… например, операция SQL DB CRUD} и отправлять обратно сообщение о завершении.
Каков наилучший способ обработки создания очереди Windows Azure для масштабирования, а также передачи сообщений туда и обратно через веб-роль и рабочую роль? Лучше ли иметь одну очередь для отправки работы, например. заказы, а затем еще одна очередь для уведомления, например. сообщение о состоянии
Я видел много сообщений о том, что вы должны создавать свои очереди вне кода вашего приложения, это имеет смысл, но как вы масштабируете это с текущим ограничением очереди «Цель масштабируемости для одной очереди Windows Azure «ограничена» на уровне 500 транзакций/ сек”?
В MSDN есть отличные ресурсы по масштабированию с помощью очередей.
• Масштабирование экземпляра роли относится к добавлению и удалению дополнительных экземпляров веб-роли или рабочей роли для обработки точки -в -временной рабочей нагрузке. Это часто включает изменение количества экземпляров в конфигурации службы. Увеличение количества экземпляров приведет к тому, что среда выполнения Windows Azure запустит новые экземпляры, тогда как уменьшение количества экземпляров, в свою очередь, приведет к закрытию запущенных экземпляров.
• Масштабирование процесса (потока )относится к поддержанию достаточной мощности с точки зрения обработки потоков в данном экземпляре роли путем увеличения или уменьшения числа потоков в зависимости от текущей рабочей нагрузки.
Короче говоря, я ищу ответы на следующие вопросы:
- Лучшая практика создания очереди?
- Как веб-роль (Приложение MVC )отслеживает сообщения, т. е. опрашивает ли оно очередь «уведомлений» после передачи сообщения, как лучше всего обрабатывать корреляцию сообщений в веб-роли для отправки обратно клиенту (веб-потребителю )?
- Являются ли параметры масштабирования выше лучшим подходом, или мне следует рассмотреть динамическое масштабирование очередей на лету (, если да, то как?,Я думаю, что в этом случае SB Queues может быть лучше )создание новых очередей, чтобы обойти ограничение в 500 транзакций в секунду?
Как уже говорилось, мои вопросы носят более теоретический характер в данный момент времени, я хочу спроектировать и проверить на будущее любое решение в будущем.
Спасибо