Лекция 7. Azure Services Platform. Часть 2

Платформа Windows Azure – это модель Платформа как Сервис, которая предполагает запуск приложений на серверах и связанной сетевой инфраструктуре, размещенной в центрах обработки данных Microsoft и имеющей доступ в Интернет. В ходе данной лекции мы рассмотрим основные узлы и компоненты данной платформы.

Цель данной лекции – получить представление об архитектуре Windows Azure

Azure Blob Services

Для работы с Windows Azure Storage пользователь должен создать учетную запись хранилища. Выполняется это через веб-интерфейс портала Windows Azure Portal. При создании учетной записи пользователь получает 256-разрядный секретный ключ, который впоследствии используется для аутентификации запросов этого пользователя к системе хранения. В частности, с помощью этого секретного ключа создается подпись HMAC SHA256 для запроса. Эта подпись передается с каждым запросом данного пользователя для обеспечения аутентификации через проверку достоверности подписи HMAC

Благодаря Windows Azure Blob приложения получают возможность хранения в облаке больших объектов, до 50 ГБ каждый. Он поддерживает высоко масштабируемую систему больших двоичных объектов (blob), в которой наиболее часто используемые blob распределяются среди множества серверов для обслуживания необходимых объемов трафика. Более того, эта система характеризуется высокой надежностью и длительностью хранения. Данные доступны в любой момент времени из любой точки планеты и продублированы, по крайней мере, трижды для повышения надежности. Кроме того, обеспечивается строгая согласованность, что гарантирует немедленную доступность объекта при его добавлении или обновлении: все изменения, внесенные в предыдущей операции записи, немедленно видны при последующем чтении.

Рассмотрим модель данных Azure Blob. На рисунке ниже представлено пространство имен Windows Azure Blob.

• Учетная запись хранилища – Любой доступ к Windows Azure Storage осуществляется через учетную запись хранилища
• Это самый высокий уровень пространства имен для доступа к объектам blob.
• Учетная запись может иметь множество контейнеров Blob

 

 

Рис. 7.1. Общее представление хранилища Blob

• Контейнер Blob – Контейнер обеспечивает группировку набора объектов blob. Область действия имени контейнера ограничена учетной записью.
• Политики совместного использования задаются на уровне контейнера. В настоящее время поддерживаются "Public READ" (Открытое чтение) и "Private" (Закрытый). Если для контейнера определена политика "Public READ", все его содержимое открыто доступно для чтения без необходимости аутентификации. Политика "Private" означает доступ с аутентификацией, т.е. только владелец соответствующей учетной записи имеет доступ к объектам blob этого контейнера.
• С контейнером могут быть ассоциированы метаданные, которые задаются в виде пар <имя, значение>. Максимальный размер метаданных контейнера – 8КБ.
• Существует возможность получения списка всех объектов blob контейнера.
• Blob – Объекты blob хранятся в контейнерах Blob Container и их область действия ограничена этими контейнерами. Каждый blob может быть размером до 50ГБ и имеет уникальное в рамках контейнера строковое имя. С blob могут быть ассоциированы метаданные, которые задаются в виде пар <имя, значение> и могут достигать размера 8КБ для blob. Метаданные blob могут быть получены и заданы отдельно от данных blob.

Для доступа к Windows Azure Blob используется приведенные выше подходы. URI конкретного blob структурирован следующим образом:

http://<учетнаязапись>.blob.core.windows.net/<контейнер>/<имяblob>

Первая часть имени хоста образована именем учетной записи хранилища, за которым следует ключевое слово "blob". Это обеспечивает направление запроса в часть Windows Azure Storage, которая обрабатывает запросы blob. За именем хоста идет имя контейнера, "/" и затем имя blob. Существуют ограничения именования учетных записей и контейнеров (подробнее об этом рассказывается в документе Windows Azure SDK). Например, имя контейнера не может включать символ "/".

Еще несколько замечаний по поводу контейнеров:

• Как говорилось выше, область действия контейнеров ограничена учетной записью, которой они принадлежат. Контейнеры хранятся распределено, что устраняет вероятность возникновения "узких мест" для трафика при работе с ними.
• Возможна задержка при воссоздании контейнера, который был недавно удален, особенно если в этом контейнере находилось большое количество объектов blob. Система должна очистить объекты blob этого контейнера, прежде чем контейнер с таким же именем сможет быть создан вновь. Пока сервер удаляет все объекты blob, попытки создания контейнера с таким же именем будут оканчиваться неудачей с формированием ошибки, указывающей на то, что контейнер находится в процессе удаления.
• Команды на удаление или создание совершенно нового контейнера быстро передаются на сервер, и приложению возвращается подтверждение об их выполнении, даже если операция удаления занимает некоторое время.

Рассмотрим интерфейс REST объектов Blob. Любой доступ к Windows Azure Blob выполняется через стандартные HTTP-команды PUT/GET/DELETE интерфейса REST.

К командам HTTP/REST, поддерживаемым для реализации операций с blob, относятся:

• PUT Blob – Вставить новый или перезаписать существующий blob с заданным именем.
• GET Blob – Получить весь blob или диапазон байтов blob, используя стандартную HTTP-операцию для возвращения диапазона GET.
• DELETE Blob – Удалить существующий blob.

Все эти операции с blob – Put, Get и Delete, – могут быть выполнены с использованием следующего URL:

http://<учетнаязапись>.blob.core.windows.net/<контейнер>/<имяblob>

Один запрос PUT обеспечивает возможность загрузки в облако blob размером до 64 МБ. Для загрузки blob, размер которого превышает 64 МБ, используется технология загрузки блоками, описываемый в следующем разделе.

Полное описание всех API REST можно найти в документе Windows Azure SDK.

Один из целевых сценариев Windows Azure Blob – эффективная загрузка объектов blob, размером десятки гигабайт. Windows Azure Blob обеспечивает это следующим образом:

Загружаемый Blob (например, Movie.avi) разбивается на последовательные блоки. Например, ролик размером 10ГБ может быть разбит на 2500 блоков по 4МБ, при этом первый блок будет представлять диапазон байтов данных от 1 до 4194304, второй блок – от 4194305 до 8388608 и т.д.

• Каждому блоку присваивается уникальный ID/имя. Область действия этого уникального ID ограничена именем загружаемого blob. Например, первый блок может быть назван "Block 0001", второй – "Block 0002" и т.д.
• Каждый блок размещается в облаке. Для этого используется операция PUT с указанием представленного выше URL с запросом, определяющим, что это операция размещения блока, и ID блока. Продолжая пример, при размещении первого блока будет указано имя blob "Movie.avi" и ID блока "Block 0001".
• Когда все блоки размещены в Windows Azure Storage, передается список загруженных блоков, чтобы представить blob, с которым они ассоциированы. Выполняется это с помощью операции PUT с указанием представленного выше URL с запросом, определяющим, что это команда blocklist. После этого HTTP-заголовок включает список блоков, которые должны использоваться в этом blob. В случае успешного завершения этой операции получаем список блоков, представляющий пригодную для чтения версию blob. Теперь blob может быть считан с помощью описанной выше команды GET Blob.

На следующем рисунке представлено место блоков в концепции данных Windows Azure Blob.

 

 

Рис. 7.2. Общее представление хранилища Blob, добавление блоков

Как описывалось ранее, доступ к объектам blob может осуществляться посредством операций PUT и GET с использованием следующего URL:

http://<учетнаязапись>.blob.core.windows.net/<контейнер>/<имяblob>

В примере, представленном на рисунке 7.2, рисунки со следующими URL могут быть размещены одной операцией PUT:

http://sally.blob.core.windows.net/pictures/IMG001.JPG

http://sally.blob.core.windows.net/pictures/IMG002.JPG

Те же URL могут использоваться для возвращения объектов blob. Одна операция PUT может обеспечить размещение в хранилище объектов blob размером до 64МБ. Для сохранения объектов blob размером больше 64МБ и вплоть до 50 ГБ необходимо сначала разместить все блоки посредством соответствующего количества операций PUT и затем, с помощью все той же операции PUT, передать список блоков, чтобы обеспечить пригодную для чтения версию blob. В примере, который иллюстрирует рис. 2, только после размещения всех блоков и подтверждения их принадлежности blob посредством списка блоков blob может быть считан с использованием следующего URL:

http://sally.blob.core.windows.net/pictures/MOV1.AVI

Операции GET всегда выполняются на уровне blob и не предполагают использования блоков.

Рассмотрим абстракции данных блоков. Каждый блок идентифицирует ID блока размером до 64 байт. Область действия ID блока ограничена именем blob, поэтому разные объекты blob могут иметь блоки с одинаковыми ID. Блоки неизменны. Каждый блок может быть размером до 4МБ, и один blob может включать блоки разного размера. Windows Azure Blob обеспечивает следующие операции уровня блока:

• PUT block – загрузить блок blob. Обратите внимание, что успешно загруженный посредством операции PUT block блок не является частью blob до тех пор, пока это не будет подтверждено списком блоков, загружаемым операцией PUT blocklist.
• PUT blocklist – подтвердить blob через предоставление списка ID блоков, его составляющих. Указанные в этой операции блоки должны быть уже успешно загружены через вызовы PUT. Порядок блоков в операции PUT blocklist обеспечит пригодную для чтения версию blob.
• GET blocklist – извлечь список блоков, переданный ранее для blob операцией PUT blocklist. В возвращаемом списке блоков указываются ID и размер каждого блока.

Во всех рассматриваемых далее примерах используется blob "MOV1.avi", располагающийся в контейнере "movies" (ролики) под учетной записью "sally".

Ниже представлен пример REST-запроса для размещения блока размером 4МБ посредством операции PUT block. Обратите внимание, что используется HTTP-команда PUT. "?comp=block" указывает на то, что это операция PUT block. Затем задается BlockID. Параметр Content-MD5 может быть задан для защиты от ошибок передачи по сети и обеспечения целостности. В данном случае, Content-MD5 – это контрольная сумма MD5 данных блока в запросе. Контрольная сумма проверяется на сервере, в случае несовпадения возвращается ошибка. Параметр Content-Length (Длина содержимого) определяет размер содержимого блока. Также в заголовке HTTP-запроса имеется заголовок авторизации, как показано ниже.

PUT http://sally.blob.core.windows.net/movies/MOV1.avi

?comp=block &blockid=BlockId1 &timeout=60

HTTP/1.1 Content-Length: 4194304

Content-MD5: HUXZLQLMuI/KZ5KDcJPcOA==

Authorization: SharedKey sally: F5a+dUDvef+PfMb4T8Rc2jHcwfK58KecSZY+l2naIao=

x-ms-date: Mon, 27 Oct 2008 17:00:25 GMT

……… Block Data Contents ………

Ниже представлен пример REST-запроса для операции PUT blocklist. Обратите внимание, что используется HTTP-команда PUT. "?comp=blocklist" указывает на то, что это операция PUT blocklist. Список блоков задается в теле HTTP-запроса в формате XML, как показано в примере ниже. Обратите внимание, что значение поля Content-Length в заголовке запроса соответствует размеру тела запроса, а не размеру создаваемого blob. Также в заголовке HTTP-запроса имеется заголовок авторизации, как показано ниже.

PUT http://sally.blob.core.windows.net/movies/MOV1.avi

?comp=blocklist &timeout=120

HTTP/1.1 Content-Length: 161213

Authorization: SharedKey sally: QrmowAF72IsFEs0GaNCtRU143JpkflIgRTcOdKZaYxw=

x-ms-date: Mon, 27 Oct 2008 17:00:25 GMT

<?xml version="1.0" encoding="utf-8"?>

<BlockList>

<Block>BlockId1</Block>

<Block>BlockId2</Block>

………………

</BlockList>

Ниже представлен пример REST-запроса для операции GET blob. В данном случае используется HTTP-команда GET. Этот запрос обеспечит извлечение всего содержимого заданного blob. Если для контейнера, которому принадлежит blob (в данном примере "movies"), задана политика совместного использования "Private", для получения blob необходимо пройти аутентификацию. Если задана политика совместного использования "Public-Read", аутентификация не требуется, и заголовок аутентификации в заголовке запроса не нужен.

GET http://sally.blob.core.windows.net/movies/MOV1.avi

HTTP/1.1

Authorization: SharedKey sally: RGllHMtzKMi4y/nedSk5Vn74IU6/fRMwiPsL+uYSDjY=

X-ms-date: Mon, 27 Oct 2008 17:00:25 GMT

Как показано в примере ниже, также поддерживается операция GET для извлечения

диапазона байт заданного blob.

GET http://sally.blob.core.windows.net/movies/MOV1.avi

HTTP/1.1

Range: bytes=1024000-2048000

Загрузка blob в виде списка блоков обладает следующими преимуществами:

• Возможность продолжения – для каждого блока в отдельности можно проверить успешность загрузки, в случае сбоя повторить попытку загрузки и продолжить выполнение с этого момента.
• Параллельная загрузка – загрузка блоков может выполняться параллельно, что обеспечивает сокращение времени загрузки очень больших объектов blob.
• Загрузка не по порядку – Блоки могут загружаться в произвольном порядке. Значение имеет лишь порядок блоков в списке операции PUT blocklist. Список блоков в операции PUT blocklist определяет пригодную для чтения версию blob.

 

 

Рис. 7.3. Сценарий загрузки блоков

• Используя представленный на рисунке 7.3 пример, опишем различные сценарии, возможные при использовании блоков для загрузки объектов blob:
• Загрузка блоков с одинаковыми ID блока – когда для одного blob загружаются блоки с одинаковыми ID блока, при формировании окончательно версии blob в операции PUT blocklist из всех блоков с одинаковым ID будет использоваться только загруженный самым последним. В примере выше загружаются два блока с BlockId4, и только второй из них будет использоваться в окончательном списке блоков blob.
• Загрузка блоков в произвольном порядке – блоки могут загружаться в порядке, отличном от указанного в окончательном списке блоков blob. В примере выше в окончательном списке блоки располагаются в порядке BlockId2, BlockId3 и BlockId4, но загружались они в другой последовательности. Упорядочивание данных blob (через операцию GET) в пригодную для чтения версию выполняется соответственно списку, указанному в операции PUT blocklist.
• Неиспользуемые блоки – более того, некоторые блоки могут никогда не войти в окончательный список блоков blob. Эти блоки будут удалены системой в процессе сборки мусора. В рассматриваемом примере такими блоками являются BlockId1 и первый блок с ID BlockId4. Точнее говоря, как только blob создан посредством операции PUT blocklist, все загруженные, но не вошедшие в список блоков операции PUT blocklist блоки будут удалены путем сборки мусора.

Загрузка большого blob может занимать довольно длительное время. При этом загруженные, но не использованные блоки занимают место в хранилище. Многие загруженные блоки могут никогда не войти в список PUT blocklist. В случае отсутствия активности для данного blob в течение длительного периода времени (в настоящее время этот период составляет неделю), эти неиспользованные блоки будут удалены системой в процессе сборки мусора.

Любопытным является сценарий параллельной загрузки блоков для одного blob. В этом случае заслуживают внимания два вопроса:

• ID блоков – если для загрузки блоков в один blob приложение использует множество клиентских модулей записи, во избежание конфликтов ID блоков должны быть уникальными среди всех этих модулей записи, или они должны представлять содержимое записываемого блока (таким образом, если один и тот же блок записывается несколькими клиентами, ID блока во всех клиентах будет одинаковым, поскольку он представляет одни и те же данные). Во избежание ошибок при потенциальной возможности записи одного Blob несколькими модулями записи в качестве ID блока рекомендуется использовать хеш (например, MD5-хеш) содержимого блока. Таким образом, ID блока будет представлять его содержимое.
• Приоритет имеет первая фиксация – в ситуации, когда множество клиентов выполняют загрузку блоков для одного blob параллельно, приоритет имеет первая фиксация blob посредством операции PUT blocklist (или модуль записи, вызвавший PUT blob первым). Все остальные неиспользованные блоки, загруженные другими модулями записи для blob с этим именем, будут удалены в процессе сборки мусора. Следовательно, для эффективного параллельного обновления blob необходима координация всех клиентов, ведущих запись параллельно.

Windows Azure Blob поддерживает условные PUT и GET, которые обеспечивают реализацию эффективной обработки параллелизма и клиентского кэширования.

Условный PUT может использоваться в ситуациях, когда один blob обновляется несколькими пользователями. Например, загрузка blob может выполняться на основании времени последнего изменения; это гарантирует, что версия изменяемого blob аналогична версии, которую изменяет клиент. Так может быть реализован совместный доступ с нежесткой блокировкой. Скажем, два клиента, А и В, обновляют один и тот же blob. Они параллельно выполняют чтение версии blob, вносят в нее какие-то изменения и вновь загружают в хранилище. В этом сценарии каждый из клиентов записывает время последнего изменения извлеченного из хранилища blob (пусть время последнего изменения будет Х). Когда они готовы загрузить обновленную версию blob назад в хранилище, они делают это с помощью условного PUT на основании сохраненного при извлечении blob времени последнего изменени я. В операции должно быть определено, что условием выполнения PUT является "если не изменялся с момента Х". Таким образом, если blob был изменен другим клиентом в промежуток времени с момента Х, операция обновления даст сбой, и клиент получит уведомление об этом.

Условный GET может использоваться для эффективной обработки вопросов соответствия содержимого кэшей. Например, клиент имеет локальный кэш объектов blob, в котором кэшируются чаще всего извлекаемые из хранилища blob. Для каждого кэшированного blob записывается время его последнего изменения. Когда клиентский кэш принимает решение обновить объекты blob из хранилища, он может использовать условный GET на основании времени изменения (с условием "если изменен с момента Х"). Таким образом, из хранилища будут загружаться только те объекты blob, которые были изменены в период времени, прошедший с момента Х, и отличаются от своей кэшированной копии.

Система Blob обеспечивает интерфейс для перечисления объектов blob контейнера. Поддерживается иерархический перечень объектов blob контейнера и механизм продолжения, что позволяет выполнять перечисление большого количества объектов blob.

Интерфейс ListBlobs поддерживает параметры "prefix" (префикс) и "delimiter" (разделитель), которые обеспечивают возможность построения иерархического перечня объектов blob. Например, пусть в учетной записи "sally" имеется контейнер "movies" объектов blob с такими именами:

Action/Rocky1.wmv

Action/Rocky2.wmv

Action/Rocky3.wmv

Action/Rocky4.wmv

Action/Rocky5.wmv

Drama/Crime/GodFather1.wmv

Drama/Crime/GodFather2.wmv

Drama/Memento.wmv

Horror/TheBlob.wmv

Как видите, "/" используется в качестве разделителя для создания подобной каталогу иерархии имен blob. Чтобы получить список всех "папок", задаем в запросе ListBlobs "delimiter=/". И вот как будет выглядеть запрос и часть ответа:

Запрос:

GET http://sally.blob.windows.net/movies?comp=list&delimiter=/

Ответ:

<BlobPrefix>Action</BlobPrefix>

<BlobPrefix>Drama</BlobPrefix>

<BlobPrefix>Horror</BlobPrefix>

Обратите внимание, тег "BlobPrefix" указывает на то, что соответствующая запись является префиксом имени blob, а не полным именем blob. Также следует заметить, что один и тот же префикс возвращается в результате только один раз.

Следующим этапом можно сочетать префикс и разделитель для получения списка содержимого "подпапки". Например, задавая "prefix=Drama/" и "delimiter=/", получаем список всех подпапок и файлов каталога "Drama":

Запрос:

GET http://sally.blob.windows.net/movies?comp=list &prefix=Drama/ &delimiter=/

Ответ:

<BlobPrefix>Drama/Crime</BlobPrefix>

<Blob>Drama/Memento.wmv</Blob>

Обратите внимание, что "Drama/Memento.wmv" – это полное имя blob, следовательно, оно так и обозначено.

Интерфейс ListBlobs обеспечивает возможность задавать "maxresults", т.е. максимальное число результатов, которое должно быть возвращено в этом вызове. Более того, система определяет верхний предел для максимального числа результатов, которые могут быть возвращены одним вызовом (более подробную информацию об этом можно найти в документации по SDK). По достижении меньшего из этих двух предельных значений вызов возвращается с соответствующим количеством результатов и непрозрачным "NextMarker" (маркер следующего). Наличие этого маркера свидетельствует о том, что данный запрос не обеспечил возвращения всех возможных результатов. "NextMarker" может использоваться для продолжения составления списка для следующей страницы результатов.

В предыдущем примере предположим, что требуется составить список всех объектов blob каталога "Action", возвращая каждый раз максимум по 3 результата. В этом случае первый набор результатов был бы таким:

Запрос:

GET http://sally.blob.windows.net/movies?comp=list &prefix=Action &maxresults=3 \

Ответ:

<Blob>Action/Rocky1.wmv</Blob>

<Blob>Action/Rocky2.wmv</Blob>

<Blob>Action/Rocky3.wmv</Blob>

</NextMarker> OpaqueMarker1</NextMarker>

С первым набором объектов blob возвращается и непрозрачный маркер, который может быть передан во второй вызов ListBlobs. Тогда этот вызов обеспечит возвращение следующих результатов:

Запрос:

GET http://sally.blob.windows.net/movies?comp=list &prefix=Action &maxresults=3

&marker=OpaqueMarker1

Ответ:

<Blob>Action/Rocky4.wmv</Blob>

<Blob>Action/Rocky5.wmv</Blob>

</NextMarker></NextMarker>

Как показано выше, возвращены оставшиеся объекты blob каталога; "NextMarker" пуст, это свидетельствует о том, что получены все результаты.

Azure Queue Services

Windows Azure Queue предоставляет надежный механизм доставки сообщений. Она предлагает простой алгоритм диспетчеризации асинхронных заданий, который обеспечивает возможность подключения к разным компонентам приложения в облаке. Очереди Windows Azure Queue характеризуются высокой надежностью, постоянством и производительностью. Текущая реализация гарантирует, по крайней мере, однократную обработку сообщения. Более того, Windows Azure Queue имеет REST-интерфейс, таким образом, приложения могут создаваться на любом языке программирования и выполнять доступ к очереди через веб в любое время из любой точки Интернета.

Рассмотрим создание приложений в облаке с использованием Azure Queue. Windows Azure Queue позволяет разделить разные части приложения в облаке, что делает возможным использование разных технологий для создания этих приложений, и их масштабирование соответственно нуждам трафика.

 

 

Рис. 7.4. Построение приложений для облака с использованием Azure Queue

Приведенный выше рисунок иллюстрирует простой и распространенный сценарий для приложений в облаке. Имеется ряд веб ролей, на которых размещается интерфейсная логика обработки веб-запросов. Также существует ряд рабочих ролей, реализующих бизнес-логику приложения. Веб роли обмениваются информацией с рабочими ролями посредством наборов запросов. Устойчивое состояние приложения может сохраняться в хранилищах Windows Azure Blob и Windows Azure Table.

Рассмотрим в качестве примера приложение онлайн сервиса видеохостинга. Пользователи могут загружать видео в это приложение; после этого приложение может автоматически преобразовывать и сохранять этот видеофайл в различных форматах мультимедиа; кроме того, приложение автоматически индексирует данные описания видео для упрощения поиска (например, по ключевым словам описания, именам актеров, режиссеров, названию и т.д.).

Такое приложение может использовать описанную ранее архитектуру. Веб-роли реализуют уровень представления и обрабатывают веб-запросы пользователей. Пользователи могут загружать видео через веб-интерфейсы. Видео-файлы могут храниться как большие двоичные объекты в хранилище Azure Blob. Приложение может также обслуживать ряд таблиц для учета имеющихся видеофайлов и хранения индексов, используемых для поиска. Рабочие роли выполняют преобразование входящих видеофайлов в разные форматы и сохранение их в хранилище Azure Blob. Рабочие роли также отвечают за обновление таблиц этого приложения в Azure Table. При получении запроса пользователя (например, запроса на загрузку видео) веб-роли создают рабочий элемент и помещают его в очередь запросов. Рабочие роли извлекают эти рабочие элементы из очереди и обрабатывают соответствующим образом. В случае успешной обработки рабочая роль должна удалить рабочий элемент из очереди во избежание повторной его обработки другой рабочей ролью.

Благодаря применению Windows Azure Queue такая архитектура обладает рядом преимуществ:

1. Масштабируемость – Приложение может легче масштабироваться соответственно нуждам трафика. Вот преимущества, связанные с масштабированием: Во-первых, длина очереди напрямую отражает насколько хорошо рабочие роли справляются с общей рабочей нагрузкой. Увеличение очереди свидетельствует о том, что рабочие роли не могут обрабатывать данные с необходимой скоростью. В этом случае приложению может потребоваться увеличить количество рабочих ролей, чтобы обеспечить более быструю обработку. Если длина очереди неизменно остается близкой к нулю, это означает, что серверная часть приложения обладает большими вычислительными мощностями, чем требуется. В этом случае приложение может сократить количество рабочих ролей для обеспечения рационального расходования ресурсов. Отслеживая размеры очереди и настраивая количество внутренних узлов, приложения могут эффективно масштабироваться соответственно объемам трафика. Во-вторых, применение очередей позволяет разделить части приложения и выполнять их масштабирование независимо друг от друга, что намного упрощает эту задачу. В данном примере веб-роли и рабочие роли отделены друг от друга и обмениваются информацией через очереди. Это позволяет настраивать количество веб-ролей и рабочих ролей независимо друг от друга без влияния на логику приложения. Таким образом, приложение может свободно масштабировать критически важные компоненты, добавляя для них больше ресурсов/компьютеров. В-третьих, применение очередей обеспечивает гибкость для эффективного использования ресурсов в приложении, что повышает эффективность масштабирования. То есть для рабочих элементов с разными приоритетами и/или разных размеров могут использоваться разные очереди, которые будут обрабатываться разными пулами рабочих ролей. В этом случае приложение может распределять соответствующие ресурсы (например, с точки зрения количества серверов) для каждого пула, таким образом, обеспечивая эффективное использование доступных ресурсов при разных характеристиках трафика. Например, рабочие элементы, имеющие критически важное значение для всей задачи, могут быть помещены в отдельную очередь. Это обеспечит их обработку независимо от всех остальных задач. Кроме того, отдельная очередь может использоваться для рабочих элементов, обработка которых требует привлечения большого количества ресурсов (например, преобразование видео). Для каждой из этих очередей могут использоваться разные пулы рабочих ролей. Приложение может настраивать размер каждого из пулов независимо, соответственно поступающему трафику.

2. Разделение ролей - Использование очередей позволяет разделить разные части приложения, что обеспечивает существенную гибкость и расширяемость с точки зрения построения приложения. Сообщения в очереди могут быть в стандартном или расширяемом формате, таком как XML, что обеспечивает независимость компонентов на обоих концах очереди друг от друга, поскольку они могут понимать сообщения в очереди. Разные части системы могут быть реализованы с использованием разных технологий и языков программирования. Например, компонент на стороне очереди может быть написан на.NET Framework, а другой компонент – на Python. Более того, изменения, происходящие внутри компонента, не имеют никакого влияния на остальную систему. Например, компонент может быть изменен с применением совершенно другой технологии или языка программирования, при этом система будет продолжать работать точно так же, и для этого не придется изменять другие компоненты, поскольку использование очередей обеспечивает разделение компонентов. Кроме того, использование очередей делает возможным сосуществование в системе разных реализаций одного и того же компонента, т.е. приложение может свободно переходить к новым технологиям. В рассматриваемом выше примере можно постепенно уходить от компонентов, созданных с применением устаревших технологий, и заменять их новыми реализациями. Старая и новая реализации могут выполняться одновременно на разных серверах и обрабатывать рабочие элементы одной очереди. При этом другие компоненты приложения никак не будут затронуты.

3. Всплески трафика - Очереди обеспечивают буферизацию, что компенсирует всплески трафика и сокращает влияние, оказываемое сбоями отдельных компонентов. В рассматриваемом ранее примере возможны случаи поступления большого числа запросов в короткий промежуток времени. Рабочие роли не могут быстро обработать все запросы. В этом случае запросы не отклоняются, а буферизуются в очередь, и рабочие роли получают возможность обрабатывать их в собственном нормальном темпе, постепенно возвращаясь к обычному режиму работы. Это позволяет приложению обрабатывать неравномерный трафик без снижения надежности. Более того, использование очередей также снижает влияние, оказываемое сбоями отдельных компонентов. В рассматриваемом выше примере в случае сбоя нескольких рабочих ролей очередь обеспечит буферизацию всех рабочих элементов, поступивших во время простоя рабочих ролей, таким образом, эти элементы не будут утрачены. Когда рабочие роли вернуться в работу, они смогут продолжить обработку рабочих элементов из очереди и, в конце концов, вернуться к нормальному режиму обработки данных по мере их поступления. Такие сбои не оказывают никакого влияния на другие компоненты. Обратите внимание, что рабочие элементы, обрабатываемые рабочими ролями на момент их сбоя, также не будут утеряны, поскольку возвратятся в очередь по истечении времени ожидания видимости (VisibilityTimeout), что обеспечивает сохранность данных при сбоях компонентов. Таким образом, приложение может переживать сбои без потери надежности.

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

Windows Azure Queue имеет следующую модель данных.

• Учетная запись хранилища – Любой доступ к Windows Azure Storage осуществляется через учетную запись хранилища.
• Это самый высокий уровень пространства имен для доступа к очередям и их сообщениям. Для использования Windows Azure Storage пользователь должен создать учетную запись хранилища. Выполняется это через веб-интерфейс портала Windows Azure Portal. При создании учетной записи пользователь получает 256-разрядный секретный ключ, который впоследствии используется для аутентификации запросов этого пользователя к системе хранения. В частности, с помощью этого секретного ключа создается подпись HMAC SHA256 для запроса.

Эта подпись передается с каждым запросом данного пользователя для обеспечения аутентификации через проверку достоверности подписи HMAC.

• Учетная запись может иметь множество очередей.
• Очередь – Очередь содержит множество сообщений. Область действия имени очереди ограничена учетной записью.

1. Количество сообщений в очереди не ограничено
2. Сообщение хранится максимум неделю. Система удаляет сообщения, поступившие более недели назад, в процессе сборки мусора.
3. С очередями могут быть ассоциированы метаданные. Метаданные представляются в форме пар <имя, значение>, их размер может составлять максимум 8KБ на очередь.
• Сообщения – Сообщения хранятся в очередях. Каждое сообщение может быть размером не более 8КБ. Для хранения данных большего размера используются хранилища Azure Blob или Azure Table, а в сообщении указывается имя большого двоичного объекта/сущности. Обратите внимание, что когда сообщение помещается в хранилище, его данные могут быть двоичными. Но при извлечении сообщений из хранилища ответ формируется в формате XML, и данные сообщения возвращаются base64-кодированными. Сообщения могут возвращаться из очереди в любом порядке, и сообщение может быть возвращено несколько раз. Рассмотрим некоторые параметры, используемые Azure Queue Service:
1. MessageID: Значение GUID, которое идентифицирует сообщение в очереди.
2. VisibilityTimeout: Целое значение, определяющее время ожидания видимости сообщения в секундах. Максимальное значение – 2 часа. Значение по умолчанию – 30 секунд.
3. PopReceipt: Строка, возвращаемая для каждого извлеченного сообщения. Эта строка, вместе с MessageID, необходима для удаления сообщения из очереди (Queue). Данный параметр следует рассматривать как непрозрачный, поскольку в будущем его формат и содержимое могут быть изменены.
4. MessageTTL: Определяет срок жизни (time-to-live, TTL) сообщения в секундах. Максимально допустимый срок жизни – 7 дней. Если этот параметр опущен, срок жизни по умолчанию – 7 дней. Если в течение срока жизни сообщение не будет удалено из очереди, оно будет удалено системой хранения в процессе сборки мусора.

URI конкретной очереди структурировано следующим образом:

http://<учетнаязапись>.queue.core.windows.net/<ИмяОчереди>

Первая часть имени хоста образована именем учетной записи хранилища, за которым следует ключевое слово "queue". Это обеспечивает направление запроса в часть Windows Azure Storage, которая обрабатывает запросы очереди. За именем хоста идет имя очереди. Существуют ограничения именования учетных записей и очередей (подробнее об этом рассказывается в документе Windows Azure SDK). Например, имя очереди не может включать символ "/".

Любой доступ к Windows Azure Queue выполняется через HTTP-интерфейс REST. Поддерживаются как HTTP, так и HTTPS протоколы.

К командам HTTP/REST на уровне учетной записи относятся:

• List Queues – Представить список всех очередей данной учетной записи.

К командам HTTP/REST на уровне очереди относятся:

• Create Queue – Создать очередь под данной учетной записью.
• Delete Queue – Удалить указанную очередь и ее содержимое без возможности восстановления.
• Set Queue Metadata – Задать/обновить определяемые пользователем метаданные очереди. Метаданные ассоциированы с очередью в виде пар имя/значение. Эта команда обеспечит перезапись всех существующих метаданных новыми.
• Get Queue Metadata – Извлечь определяемые пользователем метаданные очереди, а также примерное число сообщений в заданной очереди.

Операции уровня очереди могут выполняться с использованием следующего URL:

http://<учетнаязапись>.queue.core.windows.net/<ИмяОчереди>

К командам HTTP/REST, поддерживаемым для реализации операций на уровне сообщения, относятся:

• PutMessage (QueueName, Message, MessageTTL) – Добавить новое сообщение в конец очереди. MessageTTL определяет срок жизни данного сообщения. Сообщение может храниться в текстовом или двоичном формате, но возвращается base64-кодированным.
• GetMessages (QueueName, NumOfMessages N, VisibilityTimeout T) – Извлечь N сообщений из начала очереди и сделать их невидимыми в течение заданного VisibilityTimeout промежутка времени T. Эта операция возвратит ID сообщения, возвращенного вместе с PopReceipt. Сообщения могут возвращаться из очереди в любом порядке, и сообщение может быть возвращено несколько раз.
• DeleteMessage (QueueName, MessageID, PopReceipt) – Удалить сообщение, ассоциированное с данным PopReceipt, возвращенным ранее вызовом GetMessage. Обратите внимание, что если сообщение не будет удалено, оно повторно появится в очереди по истечении VisibilityTimeout.
• PeekMessage (QueueName, NumOfMessages N) – Извлечь N сообщений из начала очереди, не делая сообщения невидимыми. Эта операци