Проектирование архитектуры и обмен ролями с Azure в приложении с привязкой к файлам

Я рассматриваю возможность переноса своего веб-приложения в Windows Azure в целях масштабируемости, но мне интересно, как лучше разделить мое приложение.

Я ожидаю, что мой сценарий типичен и выглядит следующим образом: мое приложение позволяет пользователям загружать необработанные данные, они обрабатываются и создается отчет. Затем пользователь может просмотреть свои необработанные данные и просмотреть свой отчет.

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

Мне трудно представить связь между ролями, и я обеспокоен накладными расходами, вызванными связью между этим разделением, поэтому буду рад любому вкладу здесь.


azure azure-storage-blobs azure-storage azure-worker-roles
person Mister Cook    schedule 20.03.2011    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Хранилище BLOB-объектов — это самое простое место для хранения файлов, к которым затем может получить доступ множество ролей и экземпляров ролей, причем ни одному из них не требуется специальный доступ.

Предлагаемый нормальный шаблон выглядит следующим образом:

  • разрешить загрузку необработанных файлов с использованием экземпляров веб-роли
  • эти экземпляры веб-ролей возвращают HTTP-вызов без обработки — они сохраняют необработанные файлы в хранилище BLOB-объектов и добавляют в очередь сообщение «выполнить эту работу».
  • экземпляры рабочей роли берут сообщение из очереди, читают необработанный большой двоичный объект, выполняют работу, сохраняют результат отчета, а затем удаляют сообщение из очереди.
  • все веб-роли могут затем получить доступ к отчету, когда пользователь запрашивает его.

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

Конечно, на практике вам может понадобиться использовать этот шаблон в зависимости от размера и типа обрабатываемых данных.

person Stuart    schedule 20.03.2011

arrow_upward
2
arrow_downward

Добавление к отличному ответу Стюарта: BLOB-объекты могут хранить все, что угодно, размером до 200 ГБ. Если вам нужно/хотелось сохранить всю долговременную структуру каталогов, вы можете смонтировать виртуальный жесткий диск, написав всего несколько строк кода. Это том NTFS, с которым ваше приложение может взаимодействовать, как и с любым другим диском.

В вашем случае виртуальный жесткий диск не подходит, потому что вашему веб-приложению придется монтировать виртуальный жесткий диск и быть единственным автором для него. И если у вас есть более одного экземпляра веб-роли (что было бы, если бы вы хотели SLA и хотели масштабироваться), у вас мог быть только один писатель. В этом случае отдельные капли подходят НАМНОГО лучше.

Как сказал Стюарт, это вполне нормальная и распространенная модель. И снова, с помощью всего нескольких строк кода, вы можете вызвать хранилище SDK для копирования файла из хранилища BLOB-объектов на локальный диск вашего экземпляра. Затем вы можете обработать файл, используя обычные операции файлового ввода-вывода. Когда ваш отчет будет готов, еще несколько строк кода позволят вам скопировать отчет в новый большой двоичный объект (скорее всего, в хорошо известный контейнер, который веб-роль знает, где искать).

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

person David Makogon    schedule 20.03.2011
comment
Пока мы основываемся на комментариях друг друга, я бы также сказал, что, хотя хранилище BLOB-объектов превосходно, а хранилище очередей — хорошо, стоит тщательно подумать, хотите ли вы использовать хранилище таблиц или вместо этого хотите использовать SQL Server. До сих пор во всем, что я создавал, SQL Server оказался гораздо более удобным и полезным — если вам нужно делать такие вещи, как отчеты, то хранилище таблиц по-прежнему довольно сложно использовать. Это все мое мнение - я думаю, что я все еще частично застрял в реляционном мышлении! - person Stuart; 20.03.2011
comment
В этом случае использование таблицы или SQL Azure является личным выбором, но поиск показался очень простым (что очень хорошо подходит для хранилища таблиц, когда вам нужно только одно поле для индексации). Хранилище таблиц стоит 0,15 долл. США за ГБ, а стоимость SQL Azure — 10,00 долл. США за ГБ. А благодаря Table Storage вы будете измерять объем используемого вами хранилища. С SQL Azure минимальная стоимость составляет 10 долларов, даже если вы храните 1 КБ. Однако, если вам нужно несколько индексов для больших таблиц, с точки зрения производительности лучше всего подойдет SQL Azure. - person David Makogon; 20.03.2011
comment
да - извините - вероятно, больше запутал, чем помог ... как я пытался сказать, это стоит тщательно обдумать - и, как вы говорите, здесь тоже участвует личный выбор :) - person Stuart; 21.03.2011