Рекомендации по (пере) использованию очередей Azure - PullRequest
5 голосов
/ 12 марта 2010

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

Рекомендации по архитектуре приложения для Azure, которые я видел, включают в себя минимизацию логики веб-ролей и обработку в рабочих ролях, использование очередей для обмена данными и некоторого внутреннего хранилища, такого как SQL Azure или таблицы Azure. , Мне кажется, это хорошая идея, поскольку я могу без проблем масштабировать одну или обе части приложения. Однако мне любопытно, есть ли какие-либо передовые практики (или если у кого-то есть опыт), когда лучше всего, чтобы веб-роль говорила напрямую с хранилищем данных, а не отправляла данные по очереди?

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

Я понимаю, что это может быть тот случай, когда ответ будет "все зависит от ситуации, проверьте ваши метрики перфорирования" - но если у кого-то есть какие-то мысли, я был бы очень признателен!

Ответы [ 3 ]

5 голосов
/ 16 марта 2010

Вот моя метафора, делай с ней что хочешь

Представьте, что вы входите в ночной клуб, который граничит с изворотливой областью, но в порядке, как только вы внутри.

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

Если с вами все в порядке, то вас впустят в дверь, и вы присоединитесь, да, Очередь для оплаты в кассах, чтобы войти в действительный клуб.

В зависимости от того, включен футбол или что-то в этом роде, вам может понадобиться еще несколько вышибал на двери, но это может быть независимо от сотрудников кассовых сборов. Занят ночью, вы можете открыть другое окно, чтобы получить деньги быстрее, но то, что вы, вероятно, не собираетесь делать, заставит вышибалов обращаться с наличными. У них есть другие дела, которые они могут делать своими руками.

Итак:

  • Bouncers - веб-роли. Обрабатывать входящий трафик, отталкивать недействительным запросы и добавьте действительные запросы до:
  • Очередь - Очередь!
  • Касса - рабочие роли, выполняющие роль, отличную от роли в Интернете

Итак, нет никаких причин, по которым ваши веб-роли не могут выполнять роль кассовых сборов, но, вероятно, лучше не в долгосрочной перспективе

это моя метафора

Toby

3 голосов
/ 14 марта 2010

Я бы сказал, что что-то вроде вставки не требует рабочей роли. В любом случае, у вас будет вставка в очередь, поэтому вы ничего не будете сохранять в веб-роли. Лучше всего было бы изолировать ваши вставки (и весь доступ к данным) в отдельный класс (или классы) в вашей веб-роли. Это позволит вам отделить остальную часть кода в вашей веб-роли от конкретной системы хранения данных, которую вы используете. Это значительно упрощает последующее изменение хранилища данных. Если ваши вставки в конечном итоге нуждаются в дополнительной обработке, вы можете добавить очередь и рабочую роль, когда это необходимо, но я все же сказал бы, что вы хотите выполнить вставку непосредственно в хранилище таблиц, а затем передать вычислительную или другую бизнес-логику рабочая роль. Затем эта рабочая роль может обрабатывать сообщения из очереди или просто запрашивать в хранилище таблиц новые (необработанные) записи.

Способ, которым я вижу использование очереди для связи с рабочей ролью, становится наиболее эффективным, когда есть вычисления или другая обработка, которая должна быть выполнена с данными. Тот, который я использовал чаще всего, на самом деле является одним из примеров в Azure SDK, который показывает, как создавать эскизы изображений. Моя веб-роль вставляет загруженное изображение в хранилище BLOB-объектов Azure и связанные описания и другие поля в хранилище таблиц Azure. Он также помещает сообщение в очередь, которое сообщает рабочей роли, что существует новое изображение, для которого необходимо создать миниатюры. Я на самом деле генерирую несколько разных размеров каждого изображения для использования в разных частях сайта. Рабочая роль просто генерирует эти миниатюры и не требует отправки каких-либо уведомлений обратно в веб-роль. Любое место, где используются изображения, имеет логику для использования исходной загрузки или других заполнителей, когда эскизы еще не доступны.

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

Изменить в ответ на комментарий: Когда я отправил этот ответ, я сказал, что просто используйте изображение с полным разрешением в пользовательском интерфейсе, если миниатюра недоступна. Сейчас я работаю над сайтом, который просто использует миниатюру изображения по умолчанию с надписью «обработка», пока созданный эскиз не станет доступен. Выбор за вами и действительно зависит от требований пользовательского интерфейса вашего приложения.

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

Просмотр эскиза заполнителя во время обработки изображения в рабочем потоке намного удобнее, чем ожидание загрузки страницы во время создания эскиза.

1 голос
/ 17 марта 2010

Использование распределенных очередей (Azure, Amazon или других) довольно удивительно тонко. Я разместил запись в блоге , в которой часто встречаются тонкости очередей Azure . Итог: я предлагаю тщательно абстрагировать вашу инфраструктурную логику (поддерживающую очередь) от вашей бизнес-логики (содержимое и обработка очереди).

...