Лучшие практики для (по) использованию очередей Azure
Я нахожусь в ранних фазах разработки основанного на Azure приложения. Одной из вещей, которая притягивает меня к Azure, является масштабируемость, учитывая изменчивость спроса, который я, вероятно, буду ожидать. Как таковой я пытаюсь сохранить вещи слабо связанными, таким образом, я могу добавить экземпляры, когда я должен.
Рекомендации я видел проектирование приложения для Azure, включают сводящую к минимуму веб-ролевую логику, и делающий обрабатывающий в ролях рабочего, с помощью очередей для передачи и своего рода хранилище бэкенда как Azure SQL или Azure Таблицы. Это походит на хорошую идею мне, поскольку я могу увеличиться или или обе части приложения без любой проблемы. Однако мне любопытно, если существуют какие-либо лучшие практики (или если у кого-либо есть какие-либо события) для того, когда лучше просто иметь веб-ролевой разговор непосредственно хранилищу данных по сравнению с передающими данными очередью?
Я думаю о случае, где у меня есть простая вставка, чтобы сделать от веб-роли - в то время как я мог настроить это как сообщение, отправьте его на очереди и имейте роль рабочего, берут его и делают вставку, это походит на большую двойную обработку. Однако я также ценю, что может иметь место, что это лучше в конечном счете, в случае, если веб-роль становится разбитой, или более сложная логика заканчивает тем, что требовалась для вставки.
Я понимаю, что это могло бы быть случаем, где ответ, "он зависит полностью от ситуации, проверьте свои метрики перфекта" - но если бы у кого-либо есть какие-либо мысли, я был бы очень благодарен!
3 ответа
Я бы сказал, что что-то вроде вставки не требует рабочей роли. У вас все равно будет вставка в очередь, поэтому вы ничего не сохраните в веб-роли. Лучше всего было бы изолировать ваши вставки (и весь доступ к данным) в отдельный класс (или классы) в вашей веб-роли. Это позволит вам отделить остальной код вашей веб-роли от конкретной системы хранения данных, которую вы используете. Это значительно упрощает последующее изменение хранилища данных.Если ваши вставки потребуют дополнительной обработки, вы можете добавить очередь и рабочую роль, когда это необходимо, но я бы все равно сказал, что вы хотите выполнить вставку напрямую в хранилище таблиц, а затем переложить вычисления или другую бизнес-логику на рабочая роль. Затем эта рабочая роль может обрабатывать сообщения из очереди или просто запрашивать в хранилище таблицы новые (необработанные) записи.
Я считаю, что использование очереди для связи с рабочей ролью становится наиболее эффективным, когда есть вычисления или другая обработка, которая должна быть выполнена с данными. Тот, который я использовал чаще всего, на самом деле является одним из примеров в Azure SDK, который показывает, как создавать миниатюрные изображения. Моя веб-роль вставляет загруженное изображение в хранилище BLOB-объектов Azure, а соответствующее описание и другие поля - в хранилище таблиц Azure. Он также помещает в очередь сообщение, которое позволяет рабочей роли узнать, что есть новое изображение, для которого необходимо сгенерировать эскизы. Я фактически создаю несколько разных размеров каждого изображения для использования в разных частях сайта. Рабочая роль просто генерирует эти эскизы, и ей не нужно отправлять какие-либо уведомления обратно веб-роли. Любое место, где используются изображения, имеет логику для использования исходной загрузки или других заполнителей, когда эскизы еще недоступны.
Этот же процесс может просто использовать запрос к хранилищу BLOB-объектов, чтобы определить, какие изображения все еще требуют обработки, если вы хотите полностью пропустить очередь. Я не определился, предпочитаю ли я использовать очередь или просто опрашивать данные, чтобы найти записи, требующие обработки рабочей роли.Я полагаю, что очередь более эффективна, но она также добавляет дополнительный уровень сложности и дополнительную потенциальную точку отказа.
Изменить в ответ на комментарий: когда я опубликовал этот ответ, я сказал, что просто используйте изображение с полным разрешением в пользовательском интерфейсе, если эскиз недоступен. Сейчас я работаю над сайтом, который просто использует миниатюру по умолчанию, которая говорит «обработка» до тех пор, пока сгенерированная миниатюра не станет доступной. Выбор за вами и действительно зависит от требований пользовательского интерфейса вашего приложения.
Вы можете использовать SignalR или немного AJAX, чтобы уведомить браузер пользователя о доступности нового эскиза, не дожидаясь загрузки новой страницы.
Просмотр миниатюры заполнителя во время обработки изображения в рабочем потоке намного удобнее для пользователя, чем ожидание загрузки страницы во время создания миниатюры.
Вот моя метафора: делайте с ней все, что хотите.
Представьте, что вы входите в ночной клуб, который граничит с опасным местом, но все в порядке, когда вы окажетесь внутри.
Руководство использует несколько больших мясистых вышибал у двери, чтобы разобраться с рифовой тряпкой. Если вы идиот, вы не попадете сюда. Расширяйте метафору, насколько хотите.
Если с тобой все в порядке, то тебя впускают в дверь, и ты присоединяешься, да, Очередь, чтобы заплатить в кассе, чтобы войти в настоящий клуб.
В зависимости от того, идет ли футбол или что-то в этом роде, вам может понадобиться еще несколько вышибал, но это не зависит от кассы. Ночью вы можете открыть еще одно окно, чтобы быстрее получить деньги, но то, что вы, вероятно, не собираетесь делать, заставит вышибал разбираться с наличными деньгами. У них есть другие дела с руками.
Итак:
- Вышибалы - веб-роли. Обработайте входящий трафик , отклоните недопустимые запросы и добавьте действительные запросы в:
- Очередь - Очередь!
- Box Office - рабочие роли, выполняющие роль, отличную от роли веб-роли
Итак, нет причин, по которым ваши веб-роли не могут выполнять роль кассы, но, вероятно, лучше не делать этого в долгосрочной перспективе
это моя метафора
Тоби
Использование распределенных очередей (Azure, Amazon или еще) на удивление тонкое. Я опубликовал запись в блоге , в которой рассказывается о частых тонкостях Azure Queues . Итог: я предлагаю тщательно абстрагироваться от логики вашей инфраструктуры (поддерживающей очередь) от бизнес-логики (содержимого и обработки очереди).