WWW.BOOK.LIB-I.RU
БЕСПЛАТНАЯ  ИНТЕРНЕТ  БИБЛИОТЕКА - Электронные ресурсы
 
s

Pages:   || 2 | 3 |

«РАЗРАБОТКА МУЛЬТИТЕНАНТНЫХ Patterns & Practices ПРИЛОЖЕНИЙ ДЛЯ ОБЛАКА на платформе Microsoft Windows Azure Доминик Беттс (Dominic Betts) Алекс Хомер (Alex Homer) Алехандро Езерски (Alejandro ...»

-- [ Страница 1 ] --

3-й выпуск

РАЗРАБОТКА

МУЛЬТИТЕНАНТНЫХ

Patterns & Practices

ПРИЛОЖЕНИЙ

ДЛЯ

ОБЛАКА

на платформе

Microsoft Windows Azure

Доминик Беттс (Dominic Betts)

Алекс Хомер (Alex Homer)

Алехандро Езерски (Alejandro Jezierski)

Масаши Нарумото (Masashi Narumoto)

Ганц Чжан (Hanz Zhang)

Разработка

мультитенантных

приложений для облака

3-й выпуск

Доминик Беттс (Dominic Betts)

Алекс Хомер (Alex Homer)

Алехандро Езерски (Alejandro Jezierski)

Масаши Нарумото (Masashi Narumoto) Ганц Чжан (Hanz Zhang) 978-1-62114-023-8 Данный документ предоставляется «как есть». Информация и мнения, содержащиеся в документе, включая URL-адреса и прочие ссылки на веб-сайты в Интернете, могут быть изменены без предварительного уведомления. Риск при использовании этих сведений лежит на вас. Некоторые примеры, описанные в настоящем документе, приведены только для иллюстрации и являются вымышленными. Все совпадения следует рассматривать как случайные.

© Корпорация Майкрософт, 2012 г. Все права защищены.

Microsoft, Microsoft Dynamics, Active Directory, MSDN, SharePoint, SQL Server, Visual C#, Visual C++, Visual Basic, Visual Studio, Windows, Windows Azure, Windows Live, Windows PowerShell, Windows Server и Windows Vista являются торговыми марками группы компаний Майкрософт.

Все другие торговые марки являются собственностью соответствующих владельцев.

Оглавление Предисловие: Билл Хильф (Bill Hilf) xi Введение xiii Для кого предназначено это руководство xiii Почему это руководство вышло именно в это время xiii Структура руководства xiv Системные требования xv Где найти дополнительную информацию xvi Кто есть кто xvi Благодарности xix Благодарности за вклад в подготовку третьего выпуска xxi Сценарий Tailspin 1 Компания Tailspin 1 Стратегия компании Tailspin 1 Приложение Surveys 1 Цели и задачи компании Tailspin 3 Архитектура приложения Surveys 5 Дополнительные сведения 7

–  –  –

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

Кроме широких возможностей служб платформы для создания новых приложений, Windows Azure обеспечивает поддержку модели «инфраструктура как услуга» (Infrastructure as a Service, IaaS) как для Windows Server, так и для Linux, а также предоставляет простые инструменты для автоматизированной интеграции с широким спектром программного обеспечения с открытым исходным кодом, например базами данных, блогами, форумами — все это еще больше повышает гибкость и расширяет функционал Windows Azure. Пакет служб, функций и параметров с высокой степенью интеграции и превосходной управляемостью позволяет создавать практически любые приложения для облака, а также гарантирует максимальную производительность и надежность. Для реализации своих проектов вы можете использовать.NET, node.js, PHP, Python или Java, а мы предоставим вам среду, которая помогает сосредоточиться на разрабатываемых приложениях, не задумываясь об инфраструктуре.





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

Ваши клиенты учитывают целый ряд дополнительных факторов, например безопасность, конфиденциальность, возможность создания корпоративных веб-узлов, соблюдение нормативных требований. Это руководство, подготовленное командой подразделения patterns & practices корпорации Майкрософт, поможет вам узнать о том, как наилучшим образом удовлетворить перечисленные потребности клиентов с помощью Windows Azure. Представленные рекомендации помогут вам извлечь максимальные преимущества из нашей облачной платформы и служб. На примере вымышленной компании Tailspin, которая хочет создать реальное мультитенантное приложение, рассматривается процесс принятия решений, планирования, проектирования и реализации приложения Surveys. Вы узнаете о том, как компания Tailspin тестировала и разворачивала приложение, а также как она осуществляет управление и мониторинг.

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

Вы получите четкие рекомендации, полезные советы, работающие примеры, практические занятия и множество ссылок, которые помогут вам получить более подробную информацию. Да, все это есть в книге, которую вы сейчас читаете! Уверен, вы останетесь довольны.

Билл Хильф, генеральный директор по маркетингу Windows Azure, корпорация Майкрософт xii ПРЕДИСЛОВИЕ: БИЛЛ ХИЛЬФ (BILL HILF) Введение Каким образом компания может создать приложение, которое имеет действительно глобальный охват и может быстро масштабироваться при внезапном увеличении нагрузки? Раньше компаниям приходилось вкладывать средства в создание собственной инфраструктуры для поддержки такого приложения, и, как правило, ресурсы для таких рискованных проектов имелись в наличии только у крупных компаний. Для создания такой инфраструктуры и управления ею потребуется много средств, особенно потому, что вам необходимо учитывать возможные пиковые нагрузки, а это часто приводит к длительным простоям большей части мощностей. Облако изменило правила игры, и теперь вы пользуетесь инфраструктурой по мере необходимости и платите за нее по мере использования, что позволяет создавать масштабируемые глобальные приложения. Эти возможности доступны как крупным, так и небольшим компаниям.

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

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

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

ДЛЯ КОГО ПРЕДНАЗНАЧЕНО ЭТО РУКОВОДСТВО

Это второй том из серии, посвященной платформе Windows Azure. В первом томе «Миграция приложений в облако»

обсуждается модель затрат, варианты размещения и принципы управления жизненным циклом облачных приложений, а также описывается несколько сценариев миграции существующего приложения ASP.NET в облако. В этом руководстве рассматривается процесс создания с нуля мультитенантного приложения, работающего по модели «программное обеспечение как услуга» (Software as a Service, SaaS). Приложение будет работать в облаке с использованием последних версий инструментов и новейших функций платформы Windows Azure.

Руководство предназначено для профессиональных архитекторов систем, разработчиков и специалистов по информационным технологиям, которые занимаются проектированием, созданием или эксплуатацией приложений и служб, работающих в облаке или взаимодействующих с ним. Это руководство адресовано тем, кто работает с системами на основе Windows, хотя приложения, работающие в Windows Azure, не обязательно должны быть основаны на ОС Microsoft Windows или написаны с использованием языка.NET. Требуется знание Microsoft.NET Framework, Microsoft Visual Studio, ASP.NET, ASP.NET MVC и Microsoft Visual C#.

ПОЧЕМУ ЭТО РУКОВОДСТВО ВЫШЛО ИМЕННО В ЭТО ВРЕМЯ

В целом облако стало одной из основных возможностей, делающих ваше приложение доступным для широкого круга клиентов. В частности, сейчас платформа Windows Azure оснащена полным набором инструментов для разработчиков и ИТспециалистов. Разработчики могут использовать инструменты, с которыми они уже знакомы, например Visual Studio, с целью создания приложений для облаков. Кроме того, пакет Windows Azure SDK включает в себя эмулятор хранения ВВЕДЕНИЕ xiv и эмулятор вычислений, которые позволяют локально создавать, тестировать и отлаживать свои приложения перед развертыванием их в облаке. Также разработчикам предоставляются инструменты и интерфейсы API для управления учетными записями Windows Azure. Изучив данное руководство, вы научитесь применять эти инструменты в контексте стандартного сценария — для разработки нового мультитенантного приложения SaaS для Windows Azure.

СТРУКТУРА РУКОВОДСТВА

Это «карта» данного руководства. Структура книги

–  –  –

Глава «Сценарий Tailspin» знакомит читателей с компанией Tailspin и приложением Surveys. Здесь представлены общие сведения об архитектуре приложения Surveys. В следующих главах содержится дополнительная информация о том, как компания Tailspin разрабатывала и внедряла приложение Surveys для облака. Эта глава поможет понять бизнес-модель компании Tailspin, ее стратегию для внедрения облачной платформы и некоторые связанные с этим вопросы. Вы также сможете понять некоторые фундаментальные решения, принятые специалистами Tailspin в ходе разработки приложения.

В главе «Размещение мультитенантного приложения в Windows Azure» рассматриваются основные вопросы, связанные с архитектурой и разработкой мультитенантных приложений для работы в Windows Azure. Здесь описываются преимущества мультитенантной архитектуры и вынужденные компромиссы. В этой главе представлена концептуальная основа, которая поможет вам получить общее представление о вопросах, которые рассматриваются более подробно в последующих главах.

В главе «Выбор мультитенантной архитектуры данных» описываются важные факторы, которые следует учитывать при проектировании модели данных для мультитенантных приложений. Основные вопросы: секционирование данных, планирование расширяемости и масштабируемости, реализация проекта с помощью хранилища и реляционной базы данных Windows Azure. В этой главе описан подход, позволяющий приложению Surveys хранить данные в таблицах и BLOBобъектах Windows Azure, кроме того, вы узнаете, как разработчики компании Tailspin смогли сделать свои классы хранения расширяемыми и тестируемыми. Также описывается роль, которую база данных SQL Windows Azure играет в работе приложения Surveys.

В главе «Секционирование мультитенантных приложений» рассматривается метод секционирования кода приложения для нескольких владельцев. Например, вы научитесь использовать веб-роли и рабочие роли облачных служб, очереди и шаблон Model View Controller для улучшения работы мультитенантного приложения. Также в этой главе рассматриваются вопросы, связанные с кэшированием и управлением состояниями сеансов в разработанном специалистами компании Tailspin приложении.

Глава «Максимизация доступности, масштабируемости и эластичности» посвящена методам, позволяющим обеспечить максимальную производительность и снизить время отклика приложений, в особенности мультитенантных. В этой главе рассматриваются вопросы, связанные, например, с размещением приложения в разных географических регионах, использованием сети доставки контента (CDN) для его кэширования, применением шаблонов для чтения и записи с использованием очередей, технологиями подкачки и отображения данных, а также автоматическим масштабированием экземпляров ролей.

В главе «Обеспечение безопасности мультитенантных приложений» рассматриваются сценарии проверки подлинности и авторизации, которые используются для организации взаимодействия с отдельными подписчиками и пользователями мультитенантных приложений, а также выстраивания отношений доверия. Также вы узнаете, каким образом специалистам Tailspin удалось обеспечить защиту и изолировать важные данные, а также познакомитесь с используемыми ими методами защиты маркеров сеансов.

В главе «Управление и мониторинг мультитенантных приложений» описываются подходы к управлению жизненным циклом мультитенантных приложений. Вы узнаете о том, как компания Tailspin управляет приложением и следит за его работой, а также увидите, каким образом приложение обеспечивает поддержку новых пользователей, настройку и выставление счетов клиентам.

СИСТЕМНЫЕ ТРЕБОВАНИЯ

Для запуска сценариев необходимо выполнение следующих требований:

• Microsoft Windows 7 с пакетом обновления Service Pack 1, Microsoft Windows 8, Microsoft Windows Server 2008 R2 с пакетом обновления Service Pack 1 или Microsoft Windows Server 2012 (32- или 64-битная версия).

• Microsoft.NET Framework версии 4.0.

• Выпуск Microsoft Visual Studio 2010 Ultimate, Premium или Professional с установленным пакетом обновления Service Pack 1 или выпуск Visual Studio 2012 Ultimate, Premium или Professional.

ВВЕДЕНИЕ xvi

• Пакет Windows Azure SDK (включает средства Visual Studio для Windows Azure). Сведения о требовании определенной версии см. в заметках о выпуске.

• Microsoft SQL Server 2012, SQL Server Express 2012, SQL Server 2008 или SQL Server Express 2008. Сведения о требовании определенной версии в зависимости от вашей операционной системы см. в заметках о выпуске.

• ASP.NETMVC 4 Framework.

• Windows Identity Foundation. Требуется для авторизации на основе утверждений.

• Платформа тестирования WebAii. Потребуется только в том случае, если вы планируете функциональное тестирование. Поместите сборку ArtOfTest.WebAii.dll в папку Lib\WebAii в примерах.

Другие необходимые для примеров компоненты и платформы устанавливаются с помощью NuGet при запуске решений.

Инструкции по их установке и настройке см. в заметках о выпуске с примерами.

ГДЕ НАЙТИ ДОПОЛНИТЕЛЬНУЮ ИНФОРМАЦИЮ

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

Страница с библиографическим списком: http://msdn.microsoft.com/library/jj871057.aspx.

КТО ЕСТЬ КТО Эксперты комментируют действия разработчиков компании Tailspin и пример приложения, рассматриваемого в данном руководстве. В состав группы входят специалист по облачным решениям, архитектор программного обеспечения, разработчик программного обеспечения и ИТ-специалист. Работа над приложением рассматривается с точки зрения каждого из этих специалистов. В следующей таблице представлены входящие в состав группы эксперты.

–  –  –

Джана — архитектор программного обеспечения. Она планирует общую структуру приложения.

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

–  –  –

По — ИТ-специалист, эксперт по развертыванию и запуску приложений в облаке. По проявляет большой интерес к практическим решениям, поскольку именно его могут вызвать среди ночи, если возникнет проблема.

«Запуск приложений в облаке, к которому получают доступ тысячи пользователей, включает в себя несколько серьезных задач. Я должен убедиться, что наши облачные приложения работают хорошо, надежно и безопасно. Репутация Tailspin зависит от того, как пользователи воспринимают приложения, размещенные в облаке».

–  –  –

Четвертого марта 2010 года мне пришло электронное письмо от нашего генерального директора Стива Баллмера (Steve Ballmer). Я не так часто получаю от него письма, поэтому очень внимательно прочитал его. В теме письма было написано следующее: «Все в облака», что подчеркивало интерес корпорации Майкрософт к облачным вычислениям. Так я получил еще одно подтверждение того, что корпорация Майкрософт серьезно относится к облачным технологиям.

Мое первое знакомство с платформой, которая теперь носит название Windows Azure, и с ее компонентами произошло несколько лет назад. Я работал в группе Developer & Platform Evangelism (DPE) и занимался анализом программного обеспечения, предоставляемого как услуга. Некоторые из вас, вероятно, помнят одну из первых разработанных мной моделей в конце 2007 года, названную тогда Northwind Hosting. Она демонстрировала многие возможности, предлагаемые платформой Windows Azure сегодня. (Наблюдение за развитием направления, которым я занимался с самого его основания, очень радует меня сейчас.) В феврале 2009 года я ушел из группы DPE и начал работать в группе patterns & practices. Мне доверили руководство «облачной программой» — группой проектов по изучению задач проектирования, связанных с разработкой приложений для облака. Когда было объявлено про выход платформы Windows Azure, резко возрос спрос на консультации касательно ее работы.

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

В декабре 2009 года мы издали первый выпуск «Руководства по управлению доступом и удостоверениями на основе утверждений». Это было первым результатом работы подразделения patterns & practices и важным этапом реализации нашей облачной программы. Затем вышло в свет руководство «Миграция приложений в облако». Оно стало первым из трех руководств по разработке приложений для Windows Azure. Оба руководства регулярно обновляются по мере развития платформы Windows Azure.

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

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

Я хочу начать с благодарности следующим профильным специалистам и соавторам этого руководства: Доминик Беттс (Dominic Betts) из Content Master Ltd, Скотт Денсмор (Scott Densmore) из Microsoft Corporation, Райан Данн (Ryan Dunn), Стив Маркс (Steve Marx) и Матиас Волоски (Matias Woloski). Доминик обладает необычными способностями разбираться в чем-либо до мельчайших деталей и находить способ объяснения этих деталей всем нам, то есть находить точные, полные и при этом простые слова, понятные всем. Скотт поделился с нами знаниями о том, как создавать масштабируемые приложения Windows Azure, так как он занимался именно этим до того, как начал работать в нашей группе. Он также поделился своим многолетним опытом создания платформ и инструментов для разработчиков. Я имел честь работать с Райаном на предыдущих проектах и всегда выигрывал от его проницательности, наблюдательности и большого опыта.

БЛАГОДАРНОСТИ

xx Как эксперт по Windows он мог продемонстрировать нам, что нужно клиентам с реальными требованиями. Стив — специалист по технической стратегии Windows Azure. Он сыграл очень важную роль в создании этого руководства.

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

И, наконец, не меньшую роль сыграл Матиас, который работал на многих проектах вместе со мной. Он был вовлечен в разработку платформы Windows Azure с первого дня, и его участие в создании этого руководства нельзя недооценить.

Как и в наших предыдущих руководствах, в большинстве глав приводятся примеры кода. Они демонстрируют то, о чем идет речь в руководстве. Выражаю особую благодарность командам разработчиков и специалистов по тестированию за предоставление хорошо сбалансированного, технически целесообразного, специализированного и понятного кода: Масаши Нарумото (Masashi Narumoto) из корпорации Майкрософт, Скотт Денсмор (Scott Densmore) из корпорации Майкрософт, Федерико Берр (Federico Boerr) из Southworks, Адриан Менегатти (Adrian Menegatti) из Southworks, Ганц Чжан (Hanz Zhang) из корпорации Майкрософт, Равиндра Махендраварман (Ravindra Mahendravarman) из Infosys Ltd. и Рати Велусами (Rathi Velusamy) из Infosys Ltd.

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

Эта задача непростая, и я хочу поблагодарить Доминик Беттс (Dominic Betts) из Content Master Ltd, Роэнна Корбисиера (RoAnn Corbisier) из корпорации Майкрософт, Алекса Гомера (Alex Homer) из корпорации Майкрософт и Тину Бурден (Tina Burden) из группы технических писателей и редакторов за неоценимую помощь.

Концепция визуального оформления данного руководства была первоначально разработана Робертой Лейбовиц (Roberta Leibovitz) и Колином Кэмпбеллом (Colin Campbell) (Modeled Computation LLC) для «Руководства по идентификации на основе утверждений и управлению доступом». Мы получили отличные отзывы и решили использовать эту концепцию и для этой книги. Над дизайном руководства работал Джон Хаббард (John Hubbard) из компании eson. Мультипликационные лица были нарисованы выдающимся карикатуристом из Сиэтла Эллен Форни (Ellen Forney). Технические иллюстрации были адаптированы Робом Нэнсом (Rob Nance) и Кэти Нимер (Katie Niemer) из моих макетов, созданных на планшете.

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

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

Я также хочу поблагодарить всех тех людей, которые не пожалели времени и знаний при разработке начального проекта руководства. Я хотел бы отметить исключительно важный вклад Дэвида Айкена (David Aiken) из корпорации Майкрософт, Грэхема Астора (Graham Astor) из Avanade, Эдварда Баккера (Edward Bakker) из Inter Access, Вивека Бхатнагара (Vivek Bhatnagar) из корпорации Майкрософт, Патрика Батлера Монтерде (Patrick Butler Monterde) из корпорации Майкрософт, Шая Коэна (Shy Cohen), Джеймса Конарда (James Conard) из корпорации Майкрософт, Брайана Дэвиса (Brian Davis) из Longscale, Ашиша Дхэмхера (Aashish Dhamdhere), специалиста по Windows Azure из корпорации Майкрософт, Андреаса Эрбена (Andreas Erben) из DAENET, Гайла Фрита (Giles Frith), Эрика Л.

Голпа (Eric L. Golpe) из корпорации Майкрософт, Джонни Халифа (Johnny Halife) из Southworks, Саймона Инка (Simon Ince) из корпорации Майкрософт, Джоши Джозефа (Joshy Joseph) из корпорации Майкрософт, Эндрю Кимбэла (Andrew Kimball), Милинду Котлавеле (Milinda Kotelawele) из Longscale, Марка Коттке (Mark Kottke) из корпорации Майкрософт, Криса Лаундса (Chris Lowndes) из Avanade, Диану О'Брайен (Dianne O'Brien), специалиста по Windows Azure из корпорации Майкрософт, Штеффена Ворейна (Steffen Vorein) из Avanade и Майкла Вуда (Michael Wood) из Strategic Data Systems.

Надеюсь, это руководство будет для вас полезным!

Юдженио Пейс (Eugenio Pace) Старший менеджер проектов группы patterns & practices Корпорация Майкрософт БЛАГОДАРНОСТИ xxi

БЛАГОДАРНОСТИ ЗА ВКЛАД В ПОДГОТОВКУ ТРЕТЬЕГО ВЫПУСКА

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

По мере увеличения объема работ мы также расширили наше сообщество и привлекли новых отраслевых экспертов, которые внесли значительный вклад в разработку этого выпуска руководства. Я хочу выразить признательность за неоценимую помощь следующим специалистам: Доминик Беттс (Dominic Betts) из Content Master, Алекс Гомер (Alex Homer) из корпорации Майкрософт, Алехандро Езерски (Alejandro Jezierski) из Southworks, Мауро Крикориан (Mauro Krikorian) из Southworks, Хорхе Ровес из (Jorge Rowies) из Southworks, Маркос Кастани (Marcos Castany) из Southworks, Ганц Чжан (Hanz Zhang) из корпорации Майкрософт, Рати Велусами (Rathi Velusamy) из Infosys, Роэнн Корбисиер (RoAnn Corbisier) из корпорации Майкрософт, Нелли Делгадо (Nelly Delgado) из корпорации Майкрософт, Юдженио Пейс (Eugenio Pace) из корпорации Майкрософт, Карлос Фарре (Carlos Farre) из корпорации Майкрософт, Трент Свансон (Trent Swanson) из Full Scale 180 Inc., Эрсенк Керестеси (Ercenk Keresteci) из Full Scale 180 Inc., Джейн Синягина (Jane Sinyagina) из корпорации Майкрософт, Хатай Туна (Hatay Tuna) из корпорации Майкрософт, Патрик Батлер Монтерде (Patrick Butler Monterde) из корпорации Майкрософт и Майкл Вуд (Michael Wood). Я также хочу поблагодарить всех, кто участвовал в поддержке сайта нашего сообщества CodePlex.

Масаши Нарумото Старший менеджер проектов группы patterns & practices Корпорация Майкрософт Редмонд, октябрь 2012 г.

БЛАГОДАРНОСТИ

xxii Сценарий Tailspin В этой главе мы познакомимся с вымышленной компанией Tailspin. Здесь рассматриваются планы компании, связанные с запуском новой онлайн-службы под названием Surveys, которая позволит другим организациям и отдельным пользователям проводить собственные онлайн-опросы. Вы также поймете, почему специалисты Tailspin планируют разместить приложение на платформе Windows Azure. В любой компании, рассматривающей этот процесс, возникает множество вопросов и проблем, требующих решения, особенно в связи с тем, что компания Tailspin использует облачные технологии впервые. В следующих главах описывается разработка архитектуры и создание компанией Tailspin приложения для организации опросов, которое должно работать в Windows Azure.

КОМПАНИЯ TAILSPIN

Tailspin — это недавно образованная компания из 20 сотрудников, которая является независимым поставщиком программного обеспечения и специализируется на разработке решений с использованием технологий Microsoft. Разработчики Tailspin хорошо знакомы с различными продуктами и технологиями Microsoft, включая.NET Framework, ASP.NET MVC, SQL Server и Visual Studio. Разработчики знакомы с Windows Azure, но еще ни разу не создавали законченных решений для этой платформы.

Приложение Surveys является первой из нескольких инновационных онлайн-служб, которые компания Tailspin планирует вывести на рынок. Поскольку это начинающая компания, Tailspin хочет разработать и запустить эти службы с минимальными инвестициями в оборудование и ИТ-персонал. Компания Tailspin надеется, что некоторые из этих служб будут достаточно быстро развиваться, поэтому хочет предусмотреть возможность быстро реагировать на растущий спрос.

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

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

Приложение Surveys Приложение Surveys позволяет клиентам компании Tailspin создавать опросы, публиковать их и получать результаты с целью последующего анализа. Опрос представляет собой список из вопросов нескольких типов: множественный выбор, числовой диапазон или произвольный текст. Клиенты начинают работу с создания подписки на службу Surveys, которую они используют для управления своими опросами и брендинга с помощью стилей и логотипов.

Также предоставляется возможность выбрать географический регион для учетной записи, чтобы клиенты могли размещать свои опросы как можно ближе к целевой аудитории. Кроме того, подписка на расширенный пакет позволяет клиентам Tailspin добавлять собственные поля в опросы с целью организации взаимодействия с собственными системами.

ГЛАВА 1 Приложение Surveys можно бесплатно опробовать, а также подписаться на один из нескольких различных пакетов, чтобы получить различные наборы услуг за ежемесячную плату.

На рисунке 1 показано приложение Surveys и выделены три различные группы пользователей, которые взаимодействуют с ним. Все три веб-сайта взаимодействуют с базовыми службами, из которых состоит приложение Surveys, и предоставляют доступ к хранилищу данных приложения.

–  –  –

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

Компания Tailspin хочет использовать приложение Surveys, чтобы предложить своим клиентам надежную, настраиваемую и гибкую службу для создания и проведения интерактивных онлайн-опросов. Подписчикам необходимо предоставить возможности для создания опросов из вопросов различного типа, а также для брендинга с помощью логотипов и цветовых схем.

Tailspin планирует предлагать подписчикам различные пакеты (по различным ценам) с учетом их специфических потребностей. Самые крупные подписчики получат возможность интеграции приложения Surveys в их собственную инфраструктуру. Например, интеграция с собственной инфраструктурой подписчика поможет обеспечить единый вход (Single SignOn, SSO) или позволит нескольким пользователям управлять опросами или получать доступ к информации о выставлении счетов. Интеграция с собственными инструментами бизнес-аналитики подписчика может обеспечить проведение более сложного анализа результатов опросов. Для компаний-подписчиков малого размера, которым не нужен этот функционал, или у которых нет возможности использовать сложные технологии интеграции, в базовый пакет может быть включена система проверки подлинности. Среди доступных пакетов также должна присутствовать бесплатная пробная версия, чтобы подписчики могли оценить возможности приложения Surveys перед его приобретением.

Кроме того, различные требования предъявляются к масштабируемости веб-сайта подписчика и общедоступного веб-сайта.

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

Бизнес-модель компании Tailspin предусматривает взимание с подписчиков ежемесячной платы за использование такой службы, как приложение Surveys. Компания работает в глобальном масштабе, поэтому должна контролировать, чтобы цены были конкурентоспособными. Кроме того, компания должна покрывать фактические расходы, связанные с эксплуатацией приложения, поэтому для поддержания рентабельности Tailspin должна строго контролировать текущие затраты на сопровождение служб, предлагаемых клиентам.

В рамках данного сценария клиенты (подписчики) компании Tailspin не являются клиентами Windows Azure.

Подписчики платят компании Tailspin, которая в свою очередь платит корпорации Майкрософт за использование служб Windows Azure.

Tailspin делает все возможное, чтобы обеспечить безопасность данных своих подписчиков. Например, данные каждого подписчика не должны быть доступны другим подписчикам, необходимо создавать несколько физических копий каждого опроса, чтобы исключить потерю данных из-за случайного удаления опроса. Кроме того, все данные опроса должны сохраняться, даже если специалисты Tailspin обновляют приложение.

Наконец, к созданию приложения Surveys компания Tailspin хотела бы привлечь имеющихся разработчиков, а также свести к минимуму любое дополнительное обучение.

СЦЕНАРИЙ TAILSPIN 5

АРХИТЕКТУРА ПРИЛОЖЕНИЯ SURVEYS

Для достижения целей компания Tailspin решила реализовать приложение Surveys в виде облачной службы на базе платформы Windows Azure. На рисунке 2 представлен общий вид этой архитектуры.

–  –  –

Приложение Surveys имеет простую архитектуру, ее используют многие другие приложения для Windows Azure. Ядро приложения использует веб-роли, рабочие роли и хранилище Windows Azure. На рисунке 2 показаны три группы пользователей, обращающихся к приложению: собственник приложения, пользователи и подписчики службы Surveys (в данном примере владельцами выступают Adatum и Fabrikam). Здесь также показано, каким образом приложение использует базу данных SQL Windows Azure для предоставления подписчикам возможности экспорта результатов проведенного опроса в реляционную базу данных с целью последующего детального анализа.

В этом руководстве рассматривается процесс проектирования и реализации компанией Tailspin мультитенантного приложения Surveys. Вы также узнаете, как специалисты компании решали общие задачи, связанные с мультитенантными приложениями, например обеспечивали секционирование, расширяемость, организовывали предоставление ресурсов, тестирование и настройку. Например, в этом руководстве описывается, каким образом Tailspin обеспечивает интеграцию ГЛАВА 1 механизма проверки подлинности приложения с собственной инфраструктурой безопасности подписчика с использованием модели «федеративных удостоверений со множеством партнеров». Также здесь описаны причины выбора гибридной модели данных, предусматривающей совместное использование хранилища Windows Azure и базы данных Windows Azure.

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

Для создания приложения специалисты Tailspin планируют использовать Visual Studio, ASP.NET MVC и.NET Framework.

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

–  –  –

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

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

В этой главе рассматривается не конкретно компания Tailspin или приложение Surveys. Здесь на основе сценария из предыдущей главы иллюстрируются некоторые факторы, которые необходимо учитывать при выборе варианта реализации мультитенантного приложения на платформе Windows Azure.

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

ЦЕЛИ И ТРЕБОВАНИЯ

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

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

Также полезно проанализировать цели и требования, определяемые для мультитенантных приложений, с точки зрения как владельца, так и поставщика.

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

• Изоляция. Это самое важное требование для мультитенантного приложения. Ни один владелец не хочет зависеть от действий других, когда он использует приложение. Также каждый хочет быть уверен в том, что никто другой не сможет получить доступ к его данным. С точки зрения владельца, приложение должно работать таким образом, как будто он — единственный пользователь.

ГЛАВА 2

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

• Масштабируемость. Несмотря на то что с мультитенантным приложением одновременно работают множество владельцев, каждый из них хочет, чтобы приложение было достаточно масштабируемым и могло полностью удовлетворить его потребности. Наличие других владельцев и их действия не должны влиять на производительность приложения.

• Затраты. Пользователи мультитенантного приложения также ожидают, что их расходы будут ниже, чем при эксплуатации однотенантного приложения, поскольку мультитенантность подразумевает совместное использование ресурсов. Кроме того, владельцам нужна понятная модель ценообразования, позволяющая прогнозировать расходы, связанные с использованием приложения.

• Настраиваемость. Некоторым владельцам могут потребоваться возможности для настройки приложения, например, путем добавления или исключения функций, изменения цветовых схем или логотипов или даже добавления собственного кода или скрипта.

• Соответствие нормативным требованиям. Владельцам могут потребоваться возможности, позволяющие обеспечить соответствие приложения определенным отраслевым или законодательным требованиям и ограничениям, связанным, например, с хранением персональной информации (Personally Identifiable Information, PII) или обработкой данных за пределами определенной географической области. Требования разных владельцев могут отличаться.

Точка зрения поставщика У поставщика мультитенантного приложения будут свои цели и требования. Далее представлен перечень самых важных целей и требований с точки зрения поставщика.

• Удовлетворение целей и требований владельцев. Поставщик должен обеспечить соответствие предлагаемого приложения ожиданиям владельцев. С этой целью можно заключить официальное соглашение об уровне обслуживания.

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

Приложение должно приносить доход, достаточный для покрытия капитальных и эксплуатационных затрат.

• Выставление счетов. Поставщик должен выставлять владельцам счета. Для этого, возможно, приложение должно учитывать потребляемые ресурсы, если поставщик не установил фиксированную цену. Фиксированная цена подразумевает ежемесячную плату, которую компания Tailspin взимает с каждого владельца, использующего приложение Surveys. Также Tailspin может выставлять владельцам счета с учетом количества участников опроса или любого другого показателя.

РАЗМЕЩЕНИЕ МУЛЬТИТЕНАНТНЫХ ПРИЛОЖЕНИЙ В WINDOWS AZURE 11

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

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

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

• Мониторинг. Поставщик должен постоянно контролировать работу приложения с целью выявления и устранения проблем. Например, необходимо отслеживать, как каждый владелец использует приложение.

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

СРАВНЕНИЕ ОДНОТЕНАНТНОЙ И МУЛЬТИТЕНАНТНОЙ АРХИТЕКТУРЫ

Одно из первых архитектурных решений, которое должна была принять компания Tailspin в процессе работы над приложением Surveys, связано с выбором между однотенантной и мультитенантной архитектурой. На рисунке 1 показана основная разница между этими подходами на высоком уровне. Однотенантная модель предусматривает наличие отдельного физического экземпляра приложения для каждого подписчика, тогда как в мультитенантной модели один физический экземпляр приложения используется совместно многими подписчиками.

Необходимо отметить, что мультитенантная модель обеспечивает разграниченный доступ к данным приложения для различных пользователей. В приложении Surveys клиент Б не должен видеть или изменять опросы или данные клиента А.

Компания Tailspin, будучи владельцем приложения, будет иметь полный доступ ко всем данным, хранящимся в приложении.

ГЛАВА 2

–  –  –

МУЛЬТИТЕНАНТНАЯ АРХИТЕКТУРА В WINDOWS AZURE

Если используется платформа Windows Azure, то различия между однотенантной и мультитенантной моделями не так очевидны, как показано на рисунке 1, поскольку приложение в Windows Azure может состоять из нескольких компонентов, каждый из которых может быть однотенантным или мультитенантным. Например, если приложение включает компонент пользовательского интерфейса, компонент служб и компонент хранилища, то возможная архитектура может выглядеть так, как показано на рисунке 2.

–  –  –

РИСУНОК 2.

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

Глава 3 «Выбор мультитенантной архитектуры данных» посвящена вопросам организации хранения данных и мультитенантности. В главе 4 «Секционирование мультитенантных приложений» рассматриваются вопросы, связанные с секционированием ролей, кэша и очередей Windows Azure. Глава 6 «Обеспечение безопасности мультитенантных приложений» и глава 7 «Управление и мониторинг мультитенантных приложений»

описывают мультитенантность в других элементах приложения.

Какую модель следует положить в основу разрабатываемого вами приложения Windows Azure: однотенантную или мультитенантную? Здесь не может быть правильного или неправильного ответа, из следующего раздела вы поймете, что существует целый ряд факторов, которые могут повлиять на ваш выбор.

ГЛАВА 2

ВЫБОР МЕЖДУ ОДНОТЕНАНТНОЙ И МУЛЬТИТЕНАНТНОЙ АРХИТЕКТУРОЙ

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

Эта глава посвящена вопросам создания архитектуры и управления приложением, также приводятся финансовые соображения. Глава 3 «Выбор мультитенантной архитектуры данных» описывает факторы, которые следует учитывать в процессе выбора подходящей архитектуры данных для мультитенантного приложения.

Соображения по поводу архитектуры Требования к архитектуре приложения будут влиять на выбор между однотенантной и мультитенантной архитектурой.

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

Метод IaaS, реализованный в виртуальных машинах Windows Azure, подробнее рассматривается в главе 2 «Переход к облаку» руководства «Миграция приложений в облако». В главе 3 «Переход к облачным службам Windows Azure»

указанного руководства рассматриваются вопросы использования веб-сайтов Windows Azure для размещения приложения в облаке.

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

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

РАЗМЕЩЕНИЕ МУЛЬТИТЕНАНТНЫХ ПРИЛОЖЕНИЙ В WINDOWS AZURE 15

–  –  –

На рисунке 3 показано масштабирование приложения путем запуска разного количества экземпляров. Если используются облачные службы Windows Azure, то это будет множество экземпляров веб-ролей и рабочих ролей.

–  –  –

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

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

На рисунке 4 показан сценарий, в котором подписчики пакета Premium используют один экземпляр приложения, а подписчики пакета Standard — другой. Обращаем ваше внимание на тот факт, что каждый экземпляр может масштабироваться независимо от других.

По экземпляру для каждого владельца Tailspin

–  –  –

РИСУНОК 4.

Использование нескольких мультитенантных экземпляров Модель, показанная на рисунке 4, позволяет легко масштабировать приложение отдельно для подписчиков пакетов Premium и Standard, однако это не единственный способ создания подписок различного уровня. Например, если подписчики пакетов Premium и Standard используют один и тот же экземпляр, вы могли бы реализовать алгоритм, который поможет отдавать предпочтение пользователям пакета Premium, чтобы их рабочая нагрузка и задачи получали приоритет в пределах экземпляра. С помощью параметров конфигурации можно было бы организовать динамическое управление этим алгоритмом.

ГЛАВА 2

–  –  –

Определение географического местоположения Если владельцы вашего приложения находятся в нескольких географических регионах, то путем предоставления им доступа к ресурсам, расположенным в их стране или регионе, вы сможете повысить производительность и свести к минимуму задержки. В рамках этого сценария вы должны рассмотреть возможность реализации схем секционирования, которые используют определение географического местоположения для сопоставления владельцев с конкретным ресурсом.

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

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

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

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

Проверка подлинности и авторизация Для своего облачного приложения вы можете использовать собственные системы проверки подлинности и авторизации, тогда подписчики будут создавать учетные записи для пользователей приложения. С другой стороны, подписчики могут предпочесть использовать имеющуюся у них систему проверки подлинности (например, учетные записи Microsoft или Google, или учетные записи в их каталоге Active Directory), чтобы не создавать новые учетные записи для вашего приложения.

Для мультитенантного приложения это означает поддержку нескольких поставщиков проверки подлинности, также, возможно, придется выполнить сопоставление со схемой авторизации вашего приложения. Например, пользователь, который является «менеджером» в каталоге Active Directory компании Adatum, может быть сопоставлен с «администратором»

в приложении Surveys от компании Tailspin, которое Adatum использует.

В главе 6 «Обеспечение безопасности мультитенантных приложений» данного руководства вопросы проверки подлинности и авторизации в мультитенантном приложении рассматриваются подробнее.

Для получения дополнительной информации об удостоверениях, проверке подлинности и авторизации в облачных приложениях см. «Guide to Claims-Based Identity and Access Control» («Руководство по идентификаторам и управлению доступом на основе утверждений»). Можно загрузить копию этого руководства в формате PDF.

ГЛАВА 2

–  –  –

Мониторинг приложения Осуществлять мониторинг одного экземпляра приложения проще, чем нескольких.

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

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

Глава 7 «Управление и мониторинг мультитенантных приложений» данного руководства содержит более подробные рекомендации по организации эффективного управления и мониторинга для мультитенантных приложений.

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

ГЛАВА 2

–  –  –

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

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

Глава 7 «Управление и мониторинг мультитенантных приложений» данного руководства содержит более подробные сведения о настройке мультитенантных приложений и реализации эффективного механизма адаптации.

–  –  –

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

Однако для однотенантного экземпляра, запущенного в отдельной учетной записи Windows Azure, некоторые расходы будут фиксированными. Например, придется платить за использование работающего в круглосуточном режиме вычислительного экземпляра и базы данных SQL Windows Azure, поэтому начальная стоимость может быть слишком высокой для небольших компаний-подписчиков. В рамках мультитенантной архитектуры фиксированные затраты можно распределить между владельцами, но вычислить затраты на каждого владельца будет не так просто, и для учета объема ресурсов, используемых каждым владельцем, вашему приложению потребуется дополнительный код. Кроме того, ваши подписчики, скорее всего, захотят отслеживать свои расходы, поэтому учет затрат должен быть максимально прозрачным, вам придется реализовать специальный механизм для предоставления подписчикам доступа к данным о фактическом использовании ресурсов.

Фиксированные ежемесячные платежи В рамках второго подхода, реализованного в приложении Surveys, устанавливаются фиксированные ежемесячные платежи. Заранее нельзя точно определить объем ресурсов, которые потребуются конкретному подписчику. В случае с приложением Surveys, компания Tailspin не может предугадать, какое количество опросов подписчик создаст или сколько респондентов примут участие в опросе за определенный период. Поэтому прибыльность подписчиков будет неодинакова, в некоторых случаях будут даже отрицательные показатели.

Если ваше приложение может Сделав приложение Surveys мультитенантным, компания Tailspin может сгладить автоматически масштабироразличия в интенсивности использования ресурсов разными подписчиками, упро- ваться, это напрямую повлияет стив таким образом задачу прогнозирования расходов и доходов и снизив риск на ваши затраты. Автоматическое возникновения убытков. Чем больше у вас подписчиков, тем легче определить масштабирование помогает среднюю интенсивность использования ресурсов службы. уменьшить расходы, поскольку гарантирует, что вы используете С точки зрения подписчика, наличие фиксированной платы за использование ресуртолько необходимые ресурсы сов означает, что клиент будет заранее точно знать, какие расходы он понесет и в необходимом объеме.

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

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

подписок, доход от которых покроет фиксированные и переменные затраты.

ГЛАВА 2 Различные уровни фиксированных платежей Если ваша клиентская база включает крупные и небольшие компании, то стандартные ежемесячные платежи могут оказаться слишком высокими, что не позволяет эффективно привлекать малые компании. В таком случае подойдет видоизмененный второй подход, подразумевающий наличие нескольких пакетов для разных уровней использования.

Например, в случае с приложением Surveys компания Tailspin может предложить ограниченный пакет услуг по более низкой цене, чем стандартная подписка. Этот пакет может ограничивать количество опросов, которые могут быть созданы подписчиком, или количество респондентов, которые могут принять участие в опросе в течение месяца.

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

Управление затратами на приложение Текущие затраты на приложение Windows Azure можно разделить на фиксированные и переменные. Например, если стоимость использования вычислительного узла равна 0,12 долл. США в час, то стоимость круглосуточного использования двух вычислительных узлов (в целях обеспечения избыточности) в течение месяца — это фиксированная сумма, равная примерно 180 долл. США. Чтобы свести к минимуму расходы в расчете на одного пользователя, вы должны набрать максимально возможное количество подписчиков, не допуская при этом снижения производительности приложения. Вам следует также проанализировать характеристики производительности приложения и определить наилучший метод, который будет задействован при возрастании нагрузки: масштабирование за счет более производительных вычислительных узлов или за счет добавления дополнительных экземпляров. В главе 5 «Максимизация доступности, масштабируемости и эластичности» представлен сравнительный анализ сильных и слабых сторон каждого вида масштабирования.

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

Что касается приложения Surveys компании Tailspin, количество опросов и количество участников каждого опроса будут в значительной степени определять ежемесячные затраты на хранение данных и обработку транзакций. От архитектуры вашего приложения (однотенантная или мультитенантная) величина затрат на одного владельца не зависит. Независимо от модели, конкретному владельцу потребуется один и тот же объем хранилища и одно и то же количество вычислительных циклов. Чтобы эффективно управлять этими затратами, вы должны обеспечить максимально эффективное использование этих ресурсов вашим приложением.

Более подробные сведения об оценке затрат представлены в главе 6 «Оценка затрат на размещение приложений в облаке» руководства «Миграция приложений в облако». Оценить затраты на хранение данных можно с помощью калькулятора Windows Azure Pricing, также будет полезно изучить сообщение в блоге под заголовком «Understanding Windows Azure Storage Billing — Bandwidth, Transactions, and Capacity» («Принципы выставления счетов за использование хранилища Windows Azure: пропускная способность, транзакции и емкость»).

Расходы на инженерно-техническое обеспечение Подписка на Windows Azure — это плата за выполнение вашего приложения в облаке. Также необходимо учитывать расходы на проектирование, реализацию и управление вашим приложением. Обычно составные части у мультитенантного приложения более сложные, чем у однотенантного. Например, необходимо определить, как вы будете изолировать владельцев в пределах экземпляра, чтобы обеспечить конфиденциальность данных, а также оценить, как действия одного владельца могут повлиять на работу других. Эти дополнительные сложности могут значительно увеличить расходы на инженерно-техническое обеспечение, связанные как с разработкой мультитенантного приложения, так и с управлением им.

РАЗМЕЩЕНИЕ МУЛЬТИТЕНАНТНЫХ ПРИЛОЖЕНИЙ В WINDOWS AZURE 27

ДОПОЛНИТЕЛЬНЫЕ СВЕДЕНИЯ

Все представленные в данном руководстве ссылки присутствуют в библиографическом списке на странице http://msdn.microsoft.com/library/jj871057.aspx.

Дополнительная информация о принципах работы с платформой Windows Azure, включая планирование, проектирование и управление приложениями представлена в руководстве «Windows Azure Developer Guidance» («Руководство разработчика Windows Azure»).

Дополнительная информация о проектировании мультитенантных приложений для Windows Azure: «Designing Multitenant Applications on Windows Azure» («Разработка мультитенантных приложений в Windows Azure»).

Дополнительные сведения о расходах, связанных с выполнением приложения на платформе Windows Azure: «Estimating Cost Of Running The Web Application On Windows Azure» («Оценка затрат на веб-приложение, работающее в Windows Azure») и «Windows Azure Cost Assessment» («Оценка затрат на Windows Azure»).

Дополнительная информация об управлении жизненным циклом приложений: «Testing, Managing, Monitoring and Optimizing Windows Azure Applications» («Тестирование, управление, мониторинг и оптимизация приложений для Windows Azure»).

Дополнительные сведения о непрерывном предоставлении и использовании службы Team Foundation Service в сочетании с Windows Azure: «Continuous Delivery for Cloud Services in Windows Azure» («Непрерывное предоставление облачных служб в Windows Azure»).

ГЛАВА 2 Выбор мультитенантной архитектуры данных В этой главе рассматриваются важные факторы, которые необходимо учитывать в ходе проектирования архитектуры данных для мультитенантных приложений, также здесь описывается, как приложение Tailspin Surveys использует данные. Здесь рассматривается модель данных, используемая приложением Surveys, а также обсуждаются причины выбора командой разработчиков Tailspin именно этой модели с учетом ряда конкретных сценариев в приложении. Наконец, читатели узнают, почему и как именно приложение использует базу данных SQL Windows Azure.

–  –  –

База данных SQL также поддерживает федерации, что гарантирует высокую масштабируемость. Федерация использует технологию сегментирования, подразумевающую горизонтальное разделение таблиц на строки в нескольких базах данных.

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

Более подробно федерации в базе данных SQL обсуждаются в статье «Scaling Out with SQL Azure Federation» в журнале MSDN Magazine.

Другие варианты хранения данных Другие варианты хранения для приложений Windows Azure включают использование реляционных баз данных, таких как SQL Server или MySQL, на виртуальной машине Windows Azure, а также баз данных, не имеющих отношения к SQL, таких как MongoDB, в ВМ Windows Azure.

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

Для хранилища данных каждого типа определен гарантированный уровень доступности и максимальная пропускная способность. Например, в соглашении об уровне обслуживания для хранилища данных Windows Azure доступность устанавливается на уровне 99,9 % (любое нарушение влечет за собой частичное возмещение стоимости хостинга). Хранилище BLOB-объектов Windows Azure имеет ограниченную пропускную способность в 60 МБ в секунду для одного BLOB-объекта, в свою очередь, пропускная способность табличного хранилища Windows Azure составляет 500 сущностей в секунду для одной секции. Тщательное планирование системы хранения данных и использование подходящих стратегий секционирования может помочь избежать нарушения этих лимитов.

Гарантированная доступность базы данных SQL Windows Azure также составляет 99,9 %, однако на фактическое время отклика может повлиять дросселирование, которое активируется автоматически, когда основная система обнаруживает перегрузку сервера базы данных или конкретной базы данных. Изначально регулирование активируется из-за возрастающего времени отклика в соответствующей базе данных. Если ситуация не меняется в лучшую сторону, то Windows Azure начинает отклонять запросы на подключение до тех пор, пока нагрузка не уменьшается. Тщательно продуманная структура запросов, своевременное закрытие соединений и соответствующее использование кэширования помогут свести к минимуму вероятность активации функций дросселирования базы данных.

Microsoft SQL Server 2012 обеспечивает поддержку новых функций обеспечения высокой доступности с помощью групп доступности AlwaysOn. Вы можете настроить несколько экземпляров SQL Server 2012 на виртуальных машинах Windows Azure, создав группу доступности, чтобы обеспечить мгновенную отработку отказа, а также возможность чтения из реплик и первичного экземпляра. Также можно одновременно использовать синхронную и асинхронную фиксации в целях обеспечения максимальной производительности и доступности. Соглашение об уровне обслуживания для ролей размещаемых служб гарантирует доступность на уровне 99,9 % при условии наличия двух или более развернутых ролей; с точки зрения возможности подключения к ролям доступность поддерживается на том же уровне.

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

Если приложение и данные, которые оно использует, должны быть разделены географически, следует рассмотреть вопрос об использовании реплик первичного хранилища данных в том же самом местоположении, что и приложение. Функции георепликации в хранилище Windows Azure позволяют создать несколько копий данных в нескольких центрах обработки данных, но вы не можете указать, какие именно центры обработки данных будут использоваться. Однако вы можете ГЛАВА 3 создать учетные записи хранения в соответствующих центрах обработки данных и копировать данные между ними, также можно использовать службу кэша Windows Azure Caching или сеть доставки контента (Content Delivery Network, CDN) для кэширования данных на ресурсах, расположенных ближе к приложению.

При использовании базы данных SQL или решения SQL Server необходимо рассмотреть вопрос о размещении реплик баз данных как можно ближе к приложению, а также о применении функции SQL Database Sync для синхронизации данных.

Загрузить соглашения об уровне обслуживания для служб Windows Azure можно с ресурса Service Level Agreements.

Для получения дополнительной информации о максимизации производительности и доступности мультитенантных приложений см. главу 5 «Максимизация доступности, масштабируемости и эластичности».

МУЛЬТИТЕНАНТНЫЕ АРХИТЕКТУРЫ ДАННЫХ

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

Более подробная информация о мультитенантных архитектурах данных представлена в статьях: «MultiTenant Data Architecture» и «Architecture Strategies for Catching the Long Tail».

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

Вопросы защиты данных в мультитенантном приложении детально обсуждаются в главе 6 «Обеспечение безопасности мультитенантных приложений» данного руководства.

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

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

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

ВЫБОР МУЛЬТИТЕНАНТНОЙ АРХИТЕКТУРЫ ДАННЫХ 33

–  –  –

В следующей таблице показаны схемы секционирования, которые вы могли бы использовать для хранилищ Windows Azure в дополнение к секционированию по подписке Windows Azure.

–  –  –

В следующей таблице показаны схемы секционирования, которые вы могли бы использовать для базы данных SQL Windows Azure, а также для базы данных SQL Server или MySQL в виртуальной машине Windows Azure. Этот метод используется в качестве дополнения к секционированию по подпискам Windows Azure (см. предыдущие таблицы).

–  –  –

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

На момент написания этого руководства ограничения были следующими: до шести серверов базы данных SQL Windows Azure на одну подписку Windows Azure и 150 баз данных на один сервер. Лимиты можно увеличить по запросу, они также могут измениться в будущем.

–  –  –

На рисунке 1 показаны эти варианты на примере двух подписчиков компании Tailspin — Adatum и Fabrikam. Каждый подписчик хранит различные данные, из которых состоят определения опросов.

Отдельная таблица для каждого владельца

–  –  –

РИСУНОК 1 Примеры индивидуальных настроек для отдельных клиентов Краткий заголовок (slug name, «слаг») в таблице Survey — это строка, в которой все пробелы и неподдерживаемые символы заменяются на дефис (-). Термин «слаг» пришел из газетной отрасли, он означает «отлитая наборная строка» и не имеет ничего общего с этими штуками в вашем саду! (Прим. переводчика: одно из значений английского слова slug — «слизняк».) ГЛАВА 3

–  –  –

Ключевым фактором, определяющим масштабируемость табличного хранилища Windows Azure, является выбор ключа секционирования для таблицы. Запросы в рамках одной секции выполняются гораздо быстрее, чем запросы на доступ к сущностям из разных секций. В дополнение ко всему, поддерживаются только транзакции с сущностями в пределах одной секции в одной таблице. Как правило, ключ секции, который включает в себя идентификатор владельца, помогает сделать ваше табличное хранилище Windows Azure масштабируемым, поскольку большая часть ваших запросов будет обращаться только к одной секции, чтобы получить соответствующие данные. Для получения дополнительной информации см. главу 7 «Миграция в табличное хранилище Windows Azure» связанного руководства «Миграция приложений в облако», подготовленного подразделением patterns & practices.

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

Горизонтальное секционирование данных, известное также как сегментирование (sharding), предполагает перенос некоторых записей из данной таблицы в новую. Вертикальное секционирование данных подразумевает перемещение некоторых полей из каждой строки в другую таблицу. Федерации и сегментирование в базе данных SQL Windows Azure более подробно обсуждаются в статье «Федерации в базе данных SQL Windows Azure (прежнее название — SQL Azure)».

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

В этом простом примере принимаются следующие допущения о приложении и данных:

• Мультитенантное приложение хранит данные.

• Вы храните данные в табличном хранилище Windows Azure.

• Существуют два основных типа записей: запись заголовка и запись сведений, между ними организованы отношения «один ко многим».

• Все запросы в приложении связаны с доступом к записям за определенный месяц определенного года.

• Подписчики пакета Premium могут использовать расширенную версию записи сведений. Владелец Б — подписчик пакета Premium; у владельца А стандартная подписка.

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

ГЛАВА 3

–  –  –

Вариант 3 — отдельная таблица для каждого типа базовой сущности Записи заголовка Ключ секционирования Ключ строки Тип записи Идентификатор владельца, Идентификатор сущности Запись заголовка месяц, год заголовка

–  –  –

Вариант 4 — отдельная таблица для каждого типа сущности Записи заголовка Ключ секционирования Ключ строки Тип записи Идентификатор владельца, Идентификатор сущности Запись заголовка месяц, год заголовка

–  –  –

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

• Транзакционное поведение. Табличное хранилище Windows Azure поддерживает только транзакции в пределах одной секции. Если вы должны обеспечить поддержку транзакций, которые охватывают записи заголовков и сведений, вам подходят варианты 1 и 2.

• Производительность запросов. Запросы к табличному хранилищу Windows Azure выполняются быстрее, если вы указываете секции, содержащие запрашиваемые данные. Вам необходимо проанализировать запросы в своем приложении, чтобы принять решение о реализации той или иной схемы секционирования, чтобы оптимизировать обработку этих запросов.

• Сложность кода. Работать с таблицами с несколькими схемами сложнее, чем с таблицами с одной схемой. Однако если вы планируете реализацию дополнительных расширений схемы или пользовательских настроек для схемы каждого владельца, тогда будет сложнее управлять различными таблицами в дополнение к поддержке нескольких схем.

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

• Масштабирование. При наличии очень больших объемов данных и транзакций для масштабирования можно использовать несколько учетных записей хранения в Windows Azure. Необходимо выбрать архитектуру, которая позволяет легко распределить данные между учетными записями хранения, например можно создать несколько учетных записей для различных групп владельцев. Для получения дополнительной информации о масштабируемости мультитенантных приложений см. главу 5 «Максимизация доступности, масштабируемости и эластичности».

• Определение географического положения. Чтобы свести к минимуму задержки и повысить производительность, вы можете организовать хранение данных, относящихся к конкретному владельцу, в конкретном центре обработки данных. Разумеется, ваша архитектура должна поддерживать этот тип секционирования.

Рассмотренные варианты представляют собой альтернативные подходы к хранению мультитенантных данных, конкретно вопрос масштабируемости они не затрагивают. Существует антишаблон для табличного хранилища Windows Azure, предусматривающий добавление сущностей только в начало или конец определенной секции: все операции записи будут выполняться в рамках этой секции, что ограничивает масштабируемость решения. Стандартный подход к реализации этого антишаблона заключается в использовании текущей даты в качестве ключа секционирования таблицы, поэтому в ходе работы с рассмотренными вариантами необходимо проверить, не является ли ожидаемый объем транзакций следствием того, что выбор месяца и года в качестве ключа секционирования не оптимален. Подробная информация представлена в презентации «Windows Azure Storage Deep Dive» на канале Channel 9.

ЦЕЛИ И ТРЕБОВАНИЯ

В данном разделе рассматриваются конкретные цели и требования, которые компания Tailspin предъявляет к архитектуре и структуре элементов используемого приложением хранилища данных.

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

ВЫБОР МУЛЬТИТЕНАНТНОЙ АРХИТЕКТУРЫ ДАННЫХ 43

Масштабируемость приложений На приложение Surveys компании Tailspin будут подписываться все больше пользователей, поэтому хранилище должно быть масштабируемым. Это особенно важно для таблиц Survey, поскольку в некоторых опросах может принять участие очень большое количество респондентов. Кроме того, специалисты Tailspin хотели бы иметь возможности автоматического масштабирования приложения Surveys, поскольку заранее невозможно предугадать, когда владелец создаст опрос, в котором примет участие большое количество респондентов.

–  –  –

Для расширения возможностей анализа в приложении Surveys компания Tailspin позволяет подписчикам экспортировать ответы на опросы в экземпляр базы данных SQL Windows Azure. Подписчики могут выполнять детальный статистический анализ с помощью выбранных самостоятельно инструментов, также этот механизм можно использовать для загрузки результатов опроса в локальное приложение путем экспорта данных из базы данных SQL Windows Azure.

Приложение должно экспортировать все относящиеся к опросам данные в базу данных SQL Windows Azure, включая определения опросов и ответы респондентов.

Эта функция доступна подписчикам пакета Premium с помесячной тарификацией. Остальные владельцы могут приобрести ее в качестве дополнения к своей подписке. Подписчики, которые хотят использовать эту функцию, получают собственный экземпляр базы данных SQL Windows Azure, это предоставляет им максимально широкие возможности для анализа и обработки данных. Например, они могут создавать новые таблицы для сводной информации, сложные аналитические запросы и пользовательские отчеты. При этом каждому владельцу должна обеспечиваться конфиденциальность.

ОБЗОР РЕШЕНИЯ

В этом разделе описываются некоторые особенности приложения Surveys от компании Tailspin, связанные с архитектурой данных, а также обсуждаются факторы, которые побудили специалистов Tailspin реализовать именно такое решение. Здесь также рассматриваются проанализированные компанией Tailspin альтернативы и компромиссы, на которые ей пришлось пойти.

Учетные записи хранения Специалисты Tailspin решили использовать отдельные подписки Windows Azure для владельцев с тарифными планами Premium и Standard, но такой подход привел к увеличению сложности управления подписками и не принес ощутимых преимуществ. Биллинговая информация, предоставляемая службами Windows Azure для каждой отдельной подписки, позволяет Tailspin детально проанализировать свои расходы.

Tailspin планирует использовать отдельные учетные записи хранения в различных географических регионах, где размещается приложение Surveys. Для получения дополнительной информации см. главу 5 «Максимизация доступности, масштабируемости и эластичности».

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

–  –  –

РИСУНОК 2.

Хранилище данных в приложении Surveys Хранение определений опросов Приложение Surveys хранит определения опросов в двух таблицах Windows Azure.

В данном разделе описываются эти таблицы и объясняется, почему компания Tailspin выбрала именно этот вариант.

Tailspin решила размещать определения опросов в табличном хранилище Windows Azure для упрощения этой части приложения. Для каждого опроса создается заголовок с описанием и упорядоченный список вопросов. Создать модель такой структуры можно с использованием иерархических отношений между двумя типами сущностей, хранящихся в таблицах.

ГЛАВА 3 Данные определений опросов извлекаются каждый раз, когда респондент отвечает на вопросы, Tailspin сводит к минимуму количество обращений к хранилищу путем кэширования определений в памяти. Несмотря на то что Tailspin не может использовать транзакции для сохранения определений опросов, поскольку в этом процессе участвуют две таблицы, компании удается сохранить целостность данных благодаря подходу, предусматривающему сохранение сущностей вопросов перед сущностями соответствующего опроса. Это может привести к появлению потерянных сущностей вопросов в случае какого-либо сбоя до сохранения сущности опроса, поэтому Tailspin будет регулярно сканировать таблицу вопросов с целью обнаружения таких потерянных строк.

Транзакции не могут обеспечить полную согласованность данных, которые хранятся в двух отдельных таблицах Windows Azure. Целостности данных можно добиться, если сначала сохранить дочернюю таблицу, а затем, если этот процесс завершится без ошибок,— связанную строку в родительской таблице. Тем не менее это не означает, что всем строкам в дочерней таблице будут в обязательном порядке соответствовать строки в родительской (ошибки могут возникнуть во время второй операции сохранения данных), поэтому Tailspin создаст и будет периодически выполнять отдельный процесс для сканирования дочерней таблицы и поиска потерянных строк. Это приведет к увеличению затрат на разработку и эксплуатацию.

Ниже описываются поля таблицы Surveys. В этой таблице хранится список всех опросов в приложении.

–  –  –

Обе таблицы используют идентификатор владельца, который должен быть указан в ключе секционирования. Это помогает изолировать данные различных владельцев, потому что все запросы в приложении Tailspin Surveys включают в себя значение ключа секционирования. Задача Tailspin по управлению данными упрощается, поскольку все данные владельца хранятся в одной таблице. Например, такой подход позволяет Tailspin беспрепятственно создавать резервные копии всех определений опросов.

Владельцы с подпиской Premium могут добавлять свои метаданные, что позволяет им обеспечивать взаимодействие с собственными приложениями и службами. Для этого Tailspin придется расширить схему таблицы Surveys в хранилище Windows Azure и добавить в приложение код для работы с этими пользовательскими данными.

Задачу расширения таблицы Surveys компания Tailspin может решить двумя способами:

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

• Пользовательские данные хранятся в отдельной таблице.

Специалисты Tailspin выбрали первый вариант. Табличное хранилище Windows Azure позволяет использовать несколько схем в одной таблице, поэтому у каждого владельца могут быть собственные пользовательские поля. Кроме того, у каждого владельца также может быть несколько схем, если он изменяет типы пользовательских данных, которые ему нужно хранить. В следующей таблице показано, что специалисты компании Adatum добавили новые пользовательские поля до создания своего второго опроса, и что Fabrikam использует пользовательские поля, отличные от полей Adatum.

ГЛАВА 3

–  –  –

Хранение ответов на опросы Приложение Surveys использует хранилище BLOB-объектов для хранения ответов на опросы. Приложение создает хранилище BLOB-объектов для каждого опроса с использованием следующего шаблона именования: surveyanswers-имя владельца-краткий заголовок опроса. Таким образом обеспечивается уникальность имени контейнера для каждого опроса, а приложение может беспрепятственно определить, к какому опросу или владельцу относятся те или иные ответы.

Специалисты Tailspin решили использовать BLOB-объект для хранения каждого завершенного респондентом опроса, в данном конкретном сценарии это быстрее и отказ от таблиц оказался оправданным. Разработчики провели сравнительное тестирование и пришли к выводу, что в BLOB-объект данные сохраняются быстрее, чем в виде набора строк в табличном хранилище (с помощью Entity Group Transaction). Однако при использовании хранилища BLOB-объектов для размещения ответов на вопросы, специалисты Tailspin также должны предусмотреть возможности для просмотра подписчиками своих ответов в том порядке, в котором они были даны. Более подробно процесс сравнительного анализа двух вариантов хранения ответов на опросы (табличное хранилище или хранилище BLOB-объектов) рассматривается в главе 5 «Максимизация доступности, масштабируемости и эластичности».

Для каждого завершенного опроса приложение Surveys сохраняет BLOB-объект в контейнер этого опроса. Содержимое каждого BLOB-объекта представляет собой объект SurveyAnswer, сериализованный в формате JavaScript Object Notation (JSON). Объект SurveyAnswer инкапсулирует все ответы респондента на отдельные вопросы опроса. В следующем примере кода показаны классы SurveyAnswer и QuestionAnswer. Свойство QuestionAnswers класса SurveyAnswer — это список объектов QuestionAnswer.

C# public class SurveyAnswer {...

public string SlugName { get; set; } public string Tenant { get; set; } public string Title { get; set; } public DateTime CreatedOn { get; set; } public IListQuestionAnswer QuestionAnswers { get; set; } } public class QuestionAnswer { public string QuestionText { get; set; } public QuestionType QuestionType { get; set; } [Required(ErrorMessage = "*Пожалуйста, ответьте на вопрос.")] public string Answer { get; set; } public string PossibleAnswers { get; set; } }

ВЫБОР МУЛЬТИТЕНАНТНОЙ АРХИТЕКТУРЫ ДАННЫХ 51

Имя BLOB-объекта, используемого для хранения каждого завершенного респондентом опроса,— это его уникальный глобальный идентификатор (GUID). Это означает, что приложение сохраняет результаты опроса таким образом, что имена BLOB-объектов совершенно не подходят для целей упорядочения. Специалисты Tailspin выбрали этот вариант, отдавая предпочтение сохранению BLOB-объектов с использованием шаблона именования, отражающего порядок, в котором система получила ответы респондента. Это помогло им избежать необходимости использования антишаблона, предусматривающего добавление только в начало или конец, который рассматривается в презентации Windows Azure Storage Deep Dive на канале Channel 9.

Однако специалисты Tailspin должны предусмотреть возможности для просмотра подписчиками своих ответов в том порядке, в котором они были даны. С этой целью в приложении Surveys используется второе хранилище BLOB-объектов для размещения упорядоченного списка ответов на вопросы каждого опроса. Для каждого опроса приложение сохраняет BLOBобъект, который содержит сериализованный объект List с упорядоченными именами всех BLOB-объектов с ответами (каждый из которых содержит сериализованный объект SurveyAnswer) для конкретного опроса. Объект List сериализуется в формате JSON. В разделе «Реализация разбиения на страницы» далее в этой главе описывается, как приложение Surveys использует эти объекты List для обеспечения возможности постраничного просмотра результатов опроса.

Но при наличии очень большого количества ответов на вопросы может снижаться производительность, поскольку процесс обновления этого списка будет занимать все больше времени. Для получения дополнительной информации по данной проблеме см. раздел «Управление списком ответов на опрос» в главе 7 «Управление и мониторинг мультитенантных приложений».

Хранение сводок по ответам на опросы Приложение Surveys хранит сводные статистические данные для каждого опроса в хранилище BLOB-объектов. Для каждого опроса создается BLOB-объект с именем имя владельца-краткий заголовок опроса в контейнере surveyanswerssummaries. Чтобы сохранить данные, приложение сериализует объект SurveyAnswersSummary в формате JSON. Объект SurveyAnswersSummary содержит сводную информацию об опросе, например сведения об общем количестве ответов в свойстве TotalAnswers. Для каждого опроса создается один объект SurveyAnswersSummary.

Свойство QuestionAnswersSummaries объекта SurveyAnswersSummary содержит список вопросов конкретного опроса.

Объект QuestionAnswerSummary содержит сводную информацию об отдельном вопросе, например среднее значение для вопроса, ответы на который укладываются в определенный числовой диапазон. Каждому вопросу в конкретном опросе соответствует один объект QuestionAnswerSummary.

ГЛАВА 3 В следующем примере кода показаны классы SurveyAnswersSummary и QuestionAnswersSummary, которые используются для определения этой сводной информации.

C# public class SurveyAnswersSummary {...

public string Tenant { get; set; } public string SlugName { get; set; } public int TotalAnswers { get; set; } public IListQuestionAnswersSummary QuestionAnswersSummaries { get; set; }...

} public class QuestionAnswersSummary { public string AnswersSummary { get; set; } public QuestionType QuestionType { get; set; } public string QuestionText { get; set; } public string PossibleAnswers { get; set; } } Обратите внимание, сводка сохраняется как строковая величина (string) для вопросов всех типов, в том числе и числового.

Это позволяет свести к минимуму количество изменений, необходимых для добавления нового типа вопросов в приложение Surveys.

Сравнение методов разбиения на страницы Разработчики компании Tailspin рассматривали два возможных решения для разбиения результатов опросов на страницы на основе различных моделей хранения. В первом варианте предполагалось, что приложение хранит ответы на опросы в табличном хранилище. Второй метод, который в итоге был применен, подразумевал, что приложение хранит данные опросов в хранилище BLOB-объектов.

Разбиение на страницы при использовании табличного хранилища данных Разработчики компании Tailspin рассматривали две функции интерфейса API табличного хранилища Windows Azure для реализации своего решения. Первая функция связана с маркером продолжения, который извлекается из запроса, он позволяет выполнять каждый следующий запрос после завершения предыдущего. Для управления списком маркеров продолжения можно использовать структуру стека данных, это позволяет предусмотреть возможность перехода на одну страницу вперед или назад при просмотре ответов на вопросы конкретного опроса. Этот стек маркеров продолжения необходимо хранить вместе со сведениями о состоянии сеанса пользователя, чтобы предоставить ему возможности для навигации.

Пример практического применения данного подхода описан в разделе «Реализация разбиения на страницы в хранилище таблиц Windows Azure» главы 7 «Переход к хранилищу таблиц Windows Azure» в руководстве «Миграция приложений в облако».

ВЫБОР МУЛЬТИТЕНАНТНОЙ АРХИТЕКТУРЫ ДАННЫХ 53

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

Разбиение на страницы при использовании хранилища BLOB-объектов В данном случае предполагается использовать отдельный BLOB-объект для хранения ответа на каждый вопрос опроса. Чтобы обеспечить возможность доступа к BLOB-объектам в определенном порядке, необходим полный список этих объектов. При наличии такого списка можно получить сведения о предыдущем и следующем BLOB-объектах, что позволяет пользователю перемещаться вперед и назад, просматривая результаты опроса. Если нужно будет упорядочить данные каким-либо другим образом, потребуются дополнительные списки.

Сравнение подходов В главе 5 «Максимизация доступности, масштабируемости и эластичности» сказано, что размещение ответов на опросы непосредственно в хранилищах BLOB-объектов обеспечивает экономию. Кроме того, разбивать результаты на страницы при использовании табличного хранилища данных будет сложнее, поскольку стек маркеров продолжения придется хранить вместе со сведениями о состоянии сеанса Очевидное решение не всегда будет оптимальным (в данном пользователя.

случае речь идет об использоТем не менее необходимо оценить затраты и сложность, которые связаны вании табличного хранилища).

с управлением упорядоченным списком BLOB-объектов во втором из двух альтернативных решений. В данном случае потребуются два дополнительных обращения к базе данных с целью сохранения каждого нового ответа: для извлечения списка из хранилища BLOB-объектов и для его помещения обратно в это хранилище. Тем не менее для сохранения каждого ответа потребуется меньше транзакций, чем при использовании табличного хранилища. Кроме того, можно избежать необходимости хранения сведений о состоянии сеанса, разместив ссылки на следующий и предыдущий BLOB-объекты непосредственно на веб-странице.

–  –  –

Пользовательский интерфейс предоставляет подписчикам возможности для экспорта результатов опроса в экземпляр базы данных SQL. Соответствующее сообщение затем помещается в очередь, чтобы уведомить рабочую роль. Один из процессов в рабочей роли осуществляет мониторинг очереди сообщений и выполняет инструкции по экспорту ответов на вопросы конкретного опроса подписчика в таблицы базы данных SQL. На рисунке 3 показана структура таблиц в базе данных SQL Windows Azure.

–  –  –

РЕАЛИЗАЦИЯ Теперь настало время более подробно рассмотреть некоторые фрагменты кода в приложении Surveys от Tailspin. По мере изучения этого раздела может потребоваться загрузка решения Visual Studio для приложения Tailspin Surveys с сайта http://wag.codeplex.com/.

Классы хранения данных Приложение Surveys использует классы хранения для управления хранилищем.

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

Класс SurveyStore Этот класс отвечает за сохранение определений опросов в табличное хранилище и их последующее извлечение.

–  –  –

Класс SurveySqlStore Этот класс отвечает за сохранение данных ответов на опрос в базу данных SQL Windows Azure. Для получения дополнительной информации см. раздел «Экспорт данных» далее в этой главе.

Класс SurveyTransferStore Этот класс отвечает за помещение сообщения в очередь, когда подписчик запрашивает экспорт данных опроса в базу данных SQL Windows Azure.

ГЛАВА 3

–  –  –

Для каждого пользовательского поля задается имя, тип данных (например, строковый или целый), отображаемое значение для надписи в пользовательском интерфейсе, логический флаг (устанавливается для обязательных полей) и значение по умолчанию (необязательно). Подписчик может добавить или удалить определения пользовательских полей на вкладке Model extensions (Расширения модели) своего частного веб-сайта.

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

В следующем примере кода показано определение класса Survey, который содержит список определяемых пользователем полей. Интерфейс lUDFModel задает свойство UserDefinedFields.

C# [Serializable] public class Survey : IUDFModel { private readonly string slugName;

...

public string Tenant { get; set; } [Required(ErrorMessage = "* Укажите заголовок (Title) для опроса.")] public string Title { get; set; } public DateTime CreatedOn { get; set; } public ListQuestion Questions { get; set; } public IListUDFItem UserDefinedFields { get; set; } } ГЛАВА 3 На рисунке 4 показано, что механизм сохранения нового опроса поддерживает настраиваемые поля, здесь также представлены основные классы, которые участвуют в этом процессе. В следующем разделе этой главы процесс рассматривается подробнее.

–  –  –

Метод SaveSurvey класса SurveyStore использует объект Survey в качестве параметра и отвечает за создание объекта SurveyRow и добавление его в качестве новой строки в таблицу Survey. Класс SurveyStore в качестве параметров для своего конструктора использует экземпляры объектов, отвечающих за реализацию интерфейса lAzureTable для таблиц Survey и Question.

Объекты, отвечающие за реализацию интерфейса lAzureTable, являются базовыми типами, которые принимают тип строки таблицы, например SurveyRow или QuestionRow, и предоставляют свойство с именем ReadWriteStrategy типа lAzureTableRWStrategy, значение этого свойства задает класс, поддерживающий методы ReadEntity и WriteEntity.

Следующий пример кода взят из класса ContainerBootstraper в проекте Tailspin.Web. Здесь показано, как приложение регистрирует необходимые типы для внедрения зависимостей в класс SurveyStore, включая экземпляр класса SurveyRowRWStrategy для свойства ReadWriteStrategy класса AzureTable.

C# container.RegisterTypeIUDFDictionary, UDFDictionary();

container.RegisterTypeIAzureTableRWStrategy, SurveyRowRWStrategy(typeof(SurveyRow).Name);

var readWriteStrategyProperty = new InjectionProperty( "ReadWriteStrategy", new ResolvedParameter( typeof(IAzureTableRWStrategy), typeof(SurveyRow).Name));

container.RegisterTypeIAzureTableSurveyRow, AzureTableSurveyRow( new InjectionConstructor(cloudStorageAccountType, AzureConstants.Tables.Surveys), readWriteStrategyProperty, retryPolicyFactoryProperty)...

ГЛАВА 3 Метод SaveSurvey класса SurveyStore сохраняет экземпляр SurveyRow в табличное хранилище путем вызова метода Add экземпляра AzureTable. Этот метод создает новый класс — TableServiceContext — для доступа к таблице Windows Azure путем вызова метода CreateContext, определенного в классе AzureTable. Метод CreateContext выполняет привязку методов ReadEntity и WriteEntity класса SurveyRowRWStrategy к событиям ReadingEntity и WritingEntity класса TableServiceContext, как показано в следующем примере кода.

C# private TableServiceContext CreateContext() {...

if (this.ReadWriteStrategy != null) { context.ReadingEntity += (sender, args) = this.ReadWriteStrategy.ReadEntity(context, args);

context.WritingEntity += (sender, args) = this.ReadWriteStrategy.WriteEntity(context, args);

} return context;

} Класс SurveyRowRWStrategy — это потомок класса UDFModelRWStrategy, он не переопределяет метод WriteEntity.

В следующем примере кода показан метод WriteEntity класса UDFModelRWStrategy, который создает определенные пользователем поля и добавляет их в схему таблицы.

C# public virtual void WriteEntity( TableServiceContext context, ReadingWritingEntityEventArgs args) { var ns = XNamespace.Get(DATASERVICESNS);

var nsmd = XNamespace.Get(DATASERVICESMETADATANS);

var survey = args.Entity as SurveyRow;

if (survey != null && survey.UserDefinedFields != null && survey.UserDefinedFields.Count 0) { var properties = args.Data.Descendants(nsmd + "properties").First();

foreach (var udfItem in survey.UserDefinedFields) { var udfField = new XElement(ns + udfItem.Name, udfItem.Value);

udfField.Add(new XAttribute(nsmd + "type", udfItem.GetEdmType()));

properties.Add(udfField);

} } }

–  –  –

Чтение пользовательских полей из таблицы Surveys Процесс, отвечающий за сохранение определения опроса в табличное хранилище Windows Azure, всегда обрабатывает пользовательские поля, значения которых заданы в данных конфигурации владельца. Когда определение опроса извлекается из хранилища, оно должно включать пользовательские поля, которые были созданы при первоначальном сохранении опроса.

На рисунке 5 показано, что механизм чтения определения опроса поддерживает настраиваемые поля, эти поля добавляются в возвращаемый класс SurveyRow. Также здесь показаны базовые классы, которые участвуют в этом процессе.

–  –  –

Таблица в хранилище Windows Azure РИСУНОК 5.

Обзор механизма извлечения настраиваемых полей в опросе Класс SurveyStore выполняет запрос Select к экземпляру AzureTable, который был встроен в него на этапе инициализации.

После возникновения события ReadingEntity при извлечении сущностей из класса TableServiceContext выполняется метод ReadEntity из класса SurveyRowRWStrategy. Класс SurveyRowRWStrategy содержит ссылку на экземпляр класса, отвечающего за реализацию интерфейса lUDFDictionary. Выполнение алгоритмов для регистрации внедрения зависимостей, с которыми вы уже познакомились, приводит к тому, что в данном случае будет задействован экземпляр класса UDFDictionary.

ГЛАВА 3 Метод ReadEntity класса SurveyRowRWStrategy вызывает метод InstanceFieldsFor класса UDFDictionary, чтобы получить имена полей из метаданных таблицы, затем вызывается метод ReadEntity класса UDFModelRWStrategy для извлечения значений полей из самой таблицы. Класс SurveyRowRWStrategy затем передает набор заданных пользователем полей в свойство UserDefinedFields экземпляра SurveyRow.

Реализация разбиения на страницы Примеры кода в этом разделе разделены на две группы. Первая группа показывает, как приложение управляет упорядоченным списком BLOB-объектов. Вторая — как приложение использует этот список для организации постраничного просмотра ответов.

Управление упорядоченным списком ответов на опросы Приложение Tailspin Surveys сохраняет и обрабатывает ответы с помощью двух асинхронных задач в рабочей роли. Для получения дополнительной информации о том, как специалисты компании Tailspin организовали сохранение и обработку ответов на опросы, см. главу 5 «Максимизация доступности, масштабируемости и эластичности». Данный раздел посвящен вопросам реализации в приложении Tailspin Surveys возможности постраничного просмотра ответов на опросы, которые хранятся в BLOB-объектах.

Метод PostRun класса UpdatingSurveyResultsSummaryCommand в рабочей роли вызывает метод AppendSurveyAnswer ldsToAnswerList для набора новых ответов на опрос, обработанных в процессе выполнения метода Run. В следующем примере кода показано, как метод AppendSurveyAnswerldsToAnswerList класса SurveyAnswerStore извлекает список ответов на опросы из BLOB-объекта, добавляет новые ответы в список и сохраняет его обратно в хранилище BLOB-объектов.

C# public void AppendSurveyAnswerIdsToAnswersList( string tenant, string slugName, IEnumerablestring surveyAnswerIds) { OptimisticConcurrencyContext context;

string id = string.Format(CultureInfo.InvariantCulture, "{0}-{1}", tenant, slugName);

var answerIdList = this.surveyAnswerIdsListContainer.Get(id, out context) ?? new Liststring(1);

answerIdList.AddRange(surveyAnswerIds);

this.surveyAnswerIdsListContainer.Save(context, answerIdList);

}

ВЫБОР МУЛЬТИТЕНАНТНОЙ АРХИТЕКТУРЫ ДАННЫХ 63

Приложение хранит список ответов на опрос в объекте List, который сериализуется в формате JSON и хранится в BLOB-объекте. Для каждого опроса создается отдельный BLOB-объект, все объекты хранятся в одном контейнере.

Для получения дополнительной информации о параллельном контроле, реализованном в приложении Surveys для сохранения списка ответов на опросы, см. раздел «Пессимистический и оптимистический параллельный контроль» в главе 5 «Максимизация доступности, масштабируемости и эластичности».

–  –  –

Этот метод сначала сбрасывает данные опроса в базе данных SQL Windows Azure, а затем поочередно обрабатывает все ответы на опрос и сохраняет данные в экземпляр базы данных SQL владельца. Приложение не пытается распараллелить выполняемые операции. Для подписчиков с большими объемами данных экспорт может выполняться в течение достаточно продолжительного времени.

Для организации взаимодействия с базой данных SQL Windows Azure приложение использует технологию LINQ to SQL. Следующий код из класса SurveySqlStore показывает, как приложение использует классы SurveyData и SurveySqlDataContext. Эти классы создает конструктор SurveySql.dbml.

ГЛАВА 3

–  –  –

Когда метод действия Display класса SurveysController из проекта TailSpin.Web.Survey.Public формирует представление для вывода на экран опроса, он извлекает определение опроса из табличного хранилища и помещает в модель, используемую для отображения. В следующем примере кода показан этот метод действия.

C# [HttpGet] public ActionResult Display(string tenant, string surveySlug) { var surveyAnswer = CallGetSurveyAndCreateSurveyAnswer( this.surveyStore, tenant, surveySlug);

var model = new TenantPageViewDataSurveyAnswer(surveyAnswer);

if (surveyAnswer != null) { model.Title = surveyAnswer.Title;

} return this.View(model);

} Для отображения вопросов представление использует класс EditorExtensions. В примере кода ниже страница Display.aspx использует элемент Html.EditorFor, который описан в классе System.Web.Mvc.EditorExtensions.

HTML...

...

Этот элемент поочередно обрабатывает все вопросы, которые контроллер получил из хранилища, и использует служебный класс QuestionTemplateFactory, чтобы определить, какой пользовательский элемент управления (файл.ascx) должен быть задействован для обработки вопросов. Пользовательские элементы управления FiveStar.ascx, MultipleChoice.ascx и SimpleText.ascx расположены в папке EditorTemplates проекта.

ГЛАВА 3 Отображение сводной статистики Асинхронная задача, которая формирует сводные статистические данные на основе ответов на опрос (задача описана в главе 5 «Максимизация доступности, масштабируемости и эластичности»), помещает сводки в хранилище BLOB-объектов.

Она использует отдельный BLOB-объект для каждого опроса. Приложение Surveys отображает сводную статистику так же, как сами вопросы. В следующем фрагменте кода показан метод действия Analyze класса SurveysController из проекта TailSpin.Web, который считывает результаты из хранилища BLOB-объектов и вносит данные в модель.

C# public ActionResult Analyze(string tenant, string surveySlug) { var surveyAnswersSummary = this.surveyAnswersSummaryStore.GetSurveyAnswersSummary(tenant, surveySlug);

var model = this.CreateTenantPageViewData(surveyAnswersSummary);

model.Title = surveySlug;

return this.View(model);

} Для отображения вопросов представление использует класс Html.DisplayFor. В следующем примере кода показан фрагмент файла Analyze.aspx.

HTML li /li Шаблоны пользовательских элементов управления для отображения сводной статистики: Summary-FiveStar.ascx (отображает среднее значение для вопросов типа числовой диапазон), Summary-MultipleChoice.ascx (отображает гистограмму) и Summary-SimpleText.ascx (который отображает облако слов). Эти шаблоны размещены в папке DisplayTemplates проекта TailSpin.Web. Чтобы обеспечить поддержку дополнительных типов вопросов, необходимо добавить дополнительные шаблоны пользовательских элементов управления в эту папку.

ВЫБОР МУЛЬТИТЕНАНТНОЙ АРХИТЕКТУРЫ ДАННЫХ 69

ДОПОЛНИТЕЛЬНЫЕ СВЕДЕНИЯ

Все представленные в данном руководстве ссылки присутствуют в библиографическом списке на странице http://msdn.micr0s0ft.c0m/library/jj871057.aspx.

Для получения дополнительной информации о службах хранения Windows Azure, см. статью Data Services и блог Windows Azure Storage Team Blog.

Сравнение табличного хранилища Windows Azure и базы данных SQL Windows Azure представлено в статье «Хранилище таблиц Windows Azure и база данных SQL Windows Azure — сходство и отличия».

Дополнительные сведения о маркерах продолжения и табличном хранилище Windows Azure см. в разделе «Реализация разбиения на страницы в хранилище таблиц Windows Azure» главы 7 «Переход к хранилищу таблиц Windows Azure»

в руководстве «Миграция приложений в облако».

ГЛАВА 3 Секционирование мультитенантных приложений В данной главе рассматриваются архитектура и внедрение решения Surveys, особое внимание уделяется тому, что это приложение мультитенантное. Непосредственное отношение к мультитенантной архитектуре имеют вопросы, связанные с секционированием приложения, организацией его взаимодействия с пользователем, настройкой приложения для множества владельцев, обработкой состояния сеанса и кэшированием. В данной главе описано, как компания Tailspin решала эти вопросы в отношении приложения Surveys. Для других приложений оптимальными могут быть иные подходы.

СЕКЦИОНИРОВАНИЕ ПРИЛОЖЕНИЯ WINDOWS AZURE

Необходимость секционирования приложения Windows Azure обусловлена двумя взаимосвязанными факторами.

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

Приложение Windows Azure, как правило, состоит из множества элементов, таких как рабочие роли, веб-роли, очереди, хранилища данных, кэш.

Если у вас мультитенантное приложение, вы можете выбрать различные модели для каждого из этих элементов:

• Мультитенантная модель с одним экземпляром. Например, один экземпляр очереди может обрабатывать сообщения для всех владельцев в вашем приложении.

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

• Мультитенантная модель с несколькими экземплярами. Например, владельцы уровня Premium получают собственные очереди, а уровень Standard предоставляет доступ только к общей очереди.

В главе 2 «Размещение мультитенантных приложений в Windows Azure» подробно описаны особенности всех перечисленных моделей, также там рассматриваются факторы, которые обуславливают выбор конкретной модели для того или иного компонента вашего приложения. Глава 3 «Выбор мультитенантной архитектуры данных» посвящена обсуждению этих вопросов с точки зрения организации хранения данных в приложении Windows Azure. В этой главе особое внимание уделяется секционированию рабочих и веб-ролей, очередей и кэша. Секционирование рассматривается с точки зрения решений, принятых специалистами Tailspin в процессе проектирования и внедрения приложения Surveys.

ГЛАВА 4 На рисунке 1 показана взаимосвязь различных компонентов Windows Azure, обсуждаемых в этой главе.

–  –  –

РИСУНОК 1.

Ключевые компоненты Windows Azure, обсуждаемые в этой главе

Комментарии к рисунку 1:

• Административный доступ возможен на уровне подписки Windows Azure с использованием учетной записи Windows или ключа API управления.

• Подписка Windows Azure может включать несколько облачных служб и несколько учетных записей хранения.

• Каждая облачная служба получает уникальное DNS-имя.

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

СЕКЦИОНИРОВАНИЕ МУЛЬТИТЕНАНТНЫХ ПРИЛОЖЕНИЙ 73

Секционирование веб-ролей и рабочих ролей Приложение Windows Azure, как правило, использует несколько типов ролей. Например, в приложении Tailspin Surveys развернута одна рабочая роль и две веб-роли (одна для общедоступного веб-сайта, вторая для частного веб-сайта владельца). Веб-роли и рабочие роли Windows Azure разворачиваются непосредственно в облачной службе в рамках подписки. Варианты секционирования развертывания для разных владельцев описаны в следующей таблице.

Схема секционирования Примечания Одна подписка для Упрощает выставление счетов отдельным владельцам за потребляемые ими вычислительные ресурсы.

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

Если вы собираетесь развернуть приложение в рамках подписки владельца, то в процессе подготовки к работе владелец должен предоставить сведения, требуемые для доступа, например ключи API управления или учетные данные Microsoft.

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

Новая подписка Windows Azure создается вручную.

Ресурсы и затраты не будут распределяться между разными владельцами. Каждый владелец должен платить за все используемые им экземпляры ролей.

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

Одна подписка Если вы предоставляете владельцам возможность подписаться на пакеты с различным функционалом (например, на несколько владельцев это могут быть уровни Basic, Standard и Premium), то целесообразным представляется вариант, подразумевающий использование различных подписок, это упрощает отслеживание расходов по каждому уровню функциональных возможностей.

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

Каждая облачная служба Предоставлять доступ к облачным службам можно автоматически.

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

владельцем Это упрощает учет затрат по каждому владельцу, поскольку каждая облачная служба указывается отдельной строкой в счете за использование служб Windows Azure.

Обеспечивается максимальная изоляция владельцев.

Ресурсы и затраты не будут распределяться между разными владельцами. Каждый владелец должен платить за все используемые им экземпляры ролей.

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

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

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

Одна роль на несколько Мультитенантность поддерживается при наличии веб-роли или рабочей роли.

владельцев Между владельцами одной роли распределяются ресурсы и затраты на их предоставление.

ГЛАВА 4

–  –  –

Специалисты компании Tailspin могли бы также добавить запись CNAME в свою конфигурацию DNS, чтобы сопоставить пользовательский поддомен с приложением Surveys. Например, Tailspin могла бы сопоставить http://surveys.tailspin.com и http://tailspinsurveys.cloudapp.net/surveys.

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

Вариант 2. Путь URL При использовании ASP.

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

Для всех запросов можно использовать один и тот же домен. Например, чтобы предоставить общий доступ к перечню всех опросов, созданных тем или иным владельцем, компания Tailspin могла бы использовать URL-адрес http://tailspinsurveys.cloudapp.net/{tenant}/surveys, где {tenant} — это идентификатор владельца.

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

Вариант 3. Отдельный поддомен для каждого владельца Маршрутизация на основе поддомена не входит в стандартный функционал MVC для маршрутизации, но реализовать такой подход в MVC можно.

Например, см. запись в блоге «ASP.NETMVC Domain Routing». Этот вариант подходит, например, для идентификации владельцев общедоступных веб-сайтов без проверки подлинности.

Чтобы можно было использовать отдельные поддомены для разных владельцев, необходимо создать запись CNAME для каждого владельца в вашей конфигурации DNS.

Конфигурация DNS в компании Tailspin могла бы быть следующей:

adatum.tailspinsurveys.com CNAME tailspinsurveys.cloudapp.net fabrikam.tailspinsurveys.com CNAME tailspinsurveys.cloupapp.net Некоторые поставщики DNS позволяют использовать записи CNAME с подстановочными символами, это избавляет от необходимости создавать отдельную запись для каждого владельца. Например, *.tailspinsurveys.com CNAME tailspinsurveys.cloudapp.net Вариант 4. Пользовательские домены для владельцев Существует несколько способов, которые помогут вам предоставить владельцам возможность сопоставить пользовательский домен с вашим приложением Windows Azure.

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

Для получения дополнительной информации о настройке заголовков узлов в приложении Windows Azure, см. статьи «Настройка веб-роли для нескольких веб-сайтов».

ГЛАВА 4

–  –  –

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

Модель 1 Облачная служба Tailspin

–  –  –

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

–  –  –

Конечно, можно создавать отдельный именованный кэш для каждого владельца, но для этого придется вносить изменения в конфигурацию службы. Как правило, несколько именованных кэшей используются для того, чтобы реализовать несколько политик кэширования. Например, специалисты компании Tailspin могли бы использовать различные политики кэширования для владельцев уровня Premium и Standard, чтобы время жизни сеансов для подписчиков пакета Premium составляло 30 минут, а для подписчиков пакета Standard — всего 5.

СЕКЦИОНИРОВАНИЕ МУЛЬТИТЕНАНТНЫХ ПРИЛОЖЕНИЙ 81

Служба Windows Azure Shared Caching позволяет создавать отдельные именованные кэши, максимальный размер каждого из которых ограничен. Однако если вы планируете создавать отдельный кэш для каждого владельца, готовьтесь к дополнительным расходам, поскольку вам придется платить за каждый общий кэш, который вы создаете.

–  –  –

Разработка опросов Когда подписчик создает новый опрос в приложении Surveys, вопросы вносятся в него последовательно, один за другим.

На рисунке 4 показана последовательность экранов из раннего макета этой части пользовательского интерфейса (подписчик создает опрос из двух вопросов).

–  –  –

ОБЗОР РЕШЕНИЯ

В данном разделе описан подход, реализованный компанией Tailspin для достижения целей и удовлетворения требований, связанных с секционированием приложения.

Секционирование очередей и рабочих ролей Чтобы владельцы с подпиской Premium могли получить привилегированное обслуживание, а владельцы с подпиской Standard — обычное, специалистам Tailspin пришлось проанализировать два варианта секционирования нагрузки рабочей роли Tailspin Surveys.

Первый вариант подразумевает использование двух разных рабочих ролей для владельцев с подписками Standard и Premium. Компания Tailspin в таком случае смогла бы использовать две независимые очереди для доставки сообщений двум рабочим ролям. В рамках второго варианта предполагалось использовать одну рабочую роль и две очереди для сообщений — по одной для подписок Standard и Premium. Рабочая роль тогда присваивала бы высокий приоритет сообщениям из очереди подписки Premium.

Специалисты компании Tailspin выбрали второй вариант, поскольку он избавляет от необходимости развертывания и управления разными типами рабочих ролей. Управление приоритетами различных подписок реализовано на уровне конфигурации значений для единственной рабочей роли.

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

Однако специалисты Tailspin поняли, что пропускная способность очередей хранилища Windows Azure ограничена, т. е.

в единицу времени очередь может обработать ограниченное количество сообщений. Поэтому рекомендуется использовать несколько очередей, а также циклический перебор на каждом конце очереди, чтобы равномерно распределить сообщения между очередями, при этом читать сообщения нужно из всех очередей. Для получения дополнительной информации см. раздел «Пропускная способность очередей Azure» в главе 7 «Управление и мониторинг мультитенантных приложений».

Изоляция владельцев в веб-ролях Глава 3 «Выбор мультитенантной архитектуры данных» посвящена вопросам изоляции данных различных владельцев в модели данных, реализованной в приложении Surveys. В этом разделе описывается, каким образом приложение Surveys использует таблицы маршрутизации и области MVC для того, чтобы каждый владелец мог получить доступ только к своим собственным данным.

Компания Tailspin хотела предоставить владельцам возможность использовать свое собственное DNS-имя для организации доступа респондентов к опросам, задействуя заголовки узлов и виртуальные сайты. Однако многие более мелкие владельцы не стали бы мириться с дополнительными сложностями, связанными с управлением записями DNS, кроме того, вы не сможете создать новый сайт и заголовок узла без повторного развертывания приложения. Поэтому Tailspin отказалась от этой идеи.

СЕКЦИОНИРОВАНИЕ МУЛЬТИТЕНАНТНЫХ ПРИЛОЖЕНИЙ 85

–  –  –

http://tailspin.cloudapp.net Этот адрес HTTPS по умолчанию использует порт 80 для доступа к веб-роли, отвечающей за общедоступные опросы. Сертификат SSL в данном случае не используется, поэтому сайту можно присвоить несколько DNS-имен. Tailspin будет по умолчанию использовать DNS-имя http://surveys.tailspin.com для организации доступа к опросам, владельцы приложения в дальнейшем смогут создавать собственные записи CNAME для сопоставления с http://surveys.tailspin.com, например http://surveys.adatum.com, http://surveys.tenant2.org или http://survey.tenant3.co.de.

Доступ к приложению Tailspin Surveys в различных географических регионах Tailspin планирует развернуть независимые размещаемые облачные службы для Tailspin придется опубликовать копий приложения Surveys в различных географических регионах. Это позволяет рекомендации для своих подподписчикам размещать свои опросы таким образом, чтобы свести к минимуму писчиков по поводу использадержки для пользователей. Каждая региональная версия службы Tailspin Surveys зования записей CNAME получит свой адрес URL, для этого будут использоваться различные поддомены. в настройках DNS.

Например, Tailspin может воспользоваться следующими URL-адресами для предоставления доступа к версиям службы Tailspin Surveys, размещенным в США, Европе и Азиатско-Тихоокеанском регионе: http://surveys.tailspin.com, http://eusurveys.tailspin.com и http://fesurveys.tailspin.com. Подписчики могут сопоставлять собственные DNSимена с этими адресами.

Если необходимо предоставить подписчикам возможность размещения опроса для глобального доступа, а не для конкретного региона, опросы можно разместить на всех облачных службах Tailspin Surveys.

Специалисты Tailspin затем смогли бы использовать диспетчер трафика Windows Azure для направления клиентских запросов к ближайшей версии Tailspin Surveys. Чтобы узнать об этом подробнее, см. статью «Traffic Manager» и главу 6 «Maximizing Scalability, Availability, and Performance in the Orders Application» руководства «Building Hybrid Applications in the Cloud on Windows Azure», подготовленного подразделением patterns & practices.

Сохранение сведений о состоянии сеансов Веб-сайт владельца использует состояние сеанса в процессе создания опроса.

Разработчики Tailspin рассматривали три возможных варианта управления состоянием сеанса.

• Управление всем процессом создания опроса на стороне клиента с использованием JavaScript. Готовые опросы предполагалось отправлять на сервер с использованием вызовов AJAX.

• Хранение промежуточного состояния опроса, над которым работает подписчик, в стандартном встроенном объекте Request.Session. Поскольку веб-роль Tailspin будет запущена на нескольких узлах, компания не может использовать возможности предлагаемого по умолчанию поставщика состояния сеанса, который работает в оперативной памяти, поэтому специалистам понадобится другой такой поставщик, например из службы Windows Azure Caching. Для получения дополнительной информации см. статью «Caching in Windows Azure».

ГЛАВА 4

–  –  –

Производительность Первый вариант обеспечивает наилучшую производительность, поскольку клиент выполняет практически всю работу, не обращаясь к серверу, и только на заключительном этапе браузер посылает сообщение HTTP POST для отправки готового опроса на сервер. В рамках второго варианта в приложении будут возникать небольшие задержки, продолжительность которых будет зависеть от количества одновременных сеансов, объема данных в объектах сеансов и задержек в ходе обмена информацией между веб-ролью и кэшем. Если компания Tailspin будет использовать службу Windows Azure Shared Caching, эти задержки будут более продолжительными, чем при использовании Windows Azure Caching. Реализация третьего варианта также приведет к возникновению задержек, потому что для обработки каждого вопроса приложение будет обращаться к серверу, и каждый запрос HTTP и ответное сообщение будут включать в себя все данные о текущем состоянии.

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

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

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

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

Специалисты Tailspin остановились на втором варианте, подразумевающем использование поставщика состояния сеансов, встроенного в службу Windows Azure Caching. Такое решение соответствует требованиям Tailspin к разработке этой части приложения Surveys.

Изоляция помещенных в кэш данных владельца Специалисты компании Tailspin решили хранить данные о состоянии сеанса в кэше Windows Azure, кроме того, для кэширования данных приложения будет использоваться служба Windows Azure Caching. Tailspin решила развернуть совмещенный кэш Windows Azure, который использует часть памяти, выделенной для экземпляров веб-ролей общедоступного веб-сайта.

Для получения дополнительной информации о службе кэширования Windows Azure Caching см. статью «Overview of Caching in Windows Azure».

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

ГЛАВА 4 РЕАЛИЗАЦИЯ Теперь настало время более подробно рассмотреть некоторые фрагменты кода в приложении Surveys от Tailspin. По мере изучения этого раздела может потребоваться загрузка решения Visual Studio для приложения Tailspin Surveys с сайта http://wag.codeplex.com/.

Приоритизация задач в рабочей роли Чтобы рабочая роль в приложении Tailspin Surveys поддерживала приоритизацию задач разных групп владельцев, разработчики Tailspin внесли в нее «соединительный код» для запуска задач в рабочей роли. Следующий пример кода взят из метода Run класса WorkerRole в проекте Tailspin.Workers.Surveys, из него вы увидите, каким образом приложение Surveys использует класс BatchMultipleQueueHandler из этого соединительного кода.

C# var standardQueue = this.container.Resolve IAzureQueueSurveyAnswerStoredMessage (SubscriptionKind.Standard.ToString());

var premiumQueue = this.container.Resolve IAzureQueueSurveyAnswerStoredMessage (SubscriptionKind.Premium.ToString());

BatchMultipleQueueHandler.For(premiumQueue, GetPremiumQueueBatchSize()).AndFor(standardQueue, GetStandardQueueBatchSize()).Every(TimeSpan.FromSeconds( GetSummaryUpdatePollingInterval())). WithLessThanTheseBatcheIterationsPerCycle( GetMaxBatchIterationsPerCycle()).Do(this.container.Resolve UpdatingSurveyResultsSummaryCommand());

–  –  –

Метод Run создает две очереди Windows Azure для независимой обработки сообщений владельцев с подписками Standard и Premium. Рабочая роль присваивает высокий приоритет задачам обработки сообщений от подписчиков уровня Premium на основе размера пакетов, который она считывает из файла конфигурации службы с помощью методов GetPremiumQueueBatchSize и GetStandardQueueBatchSize. Кроме того, рабочая роль использует метод GetSummaryUpdatePollinglnterval для чтения файла конфигурации службы и установки интервала опроса для извлечения сообщений из очереди, а также метод GetMaxBatchlterationsPerCycle для определения максимального количества сообщений, которые будут обработаны в каждом цикле.

Необходимо ограничивать максимальное количество сообщений, извлекаемых процессом рабочей роли из очереди в каждом цикле. Если код будет продолжать работу, пока не прочитает все сообщения из очереди, и при этом веб-роль будет добавлять сообщения быстрее, чем может их обработать, цикл будет бесконечным!

Класс BatchMultipleQueueHandler в рабочей роли позволяет вызывать команды типа IBatchCommandT с помощью метода Do. Команды можно выполнять в отношении нескольких очередей Windows Azure типа lAzureQueue с использованием методов For и AndFor. Интервал задает метод Every. Метод WithLessThanTheseBatch lterationsPerCycle устанавливает ограничение на количество пакетов, извлекаемых из очереди перед началом обработки сообщений.

В примере кода, приведенном выше, показана рабочая роль, которая обрабатывает очереди Premium и Standard, используемые для передачи сообщений SurveyAnswer StoredMessage. Сообщения обрабатываются каждые 10 секунд с использованием класса UpdatingSurveyResultsSummaryCommand.

Существует также класс QueueHandler, который обрабатывает сообщения из одной очереди. Его интерфейс API несколько упрощен: метод Do позволяет вызывать Структура класса команды типа ICommand, метод For определяет одну очередь Windows Azure типа BatchMultipleQueueHandler lAzureQueue, а метод Every задает интервал обработки сообщений. позволяет компилятору проверить, что обе очереди Задачи, которые Tailspin выполняет в рабочей роли с помощью плат- и класс UpdatingSurveyResults формы, рассматриваемой в этой главе, включают сохранение ответов SummaryCommand настроены на опросы и формирование сводной статистики. Описание этих задач на один и тот же тип см. в главе 5 «Максимизация доступности, масштабируемости сообщений.

и эластичности».

ГЛАВА 4 BatchMultipleQueueHandler и связанные классы В этом разделе рассматривается реализация класса BatchMultipleQueueHandler и связанных с ним классов. Реализация с использованием класса QueueHandler проста, но выполняемые задачи относятся к более простому интерфейсу ICommand вместо интерфейса IBatchCommand.

РИСУНОК 5.

Основные соединительные типы

СЕКЦИОНИРОВАНИЕ МУЛЬТИТЕНАНТНЫХ ПРИЛОЖЕНИЙ 93

На рисунке 5 показаны основные типы, используемые в соединительном коде для класса BatchMultipleQueueHandler, с помощью которого приложение устанавливает высокий приоритет для задач владельцев с подпиской Premium. Сначала рабочая роль вызывает метод For для статического класса BatchMultipleQueueHandler, который, в свою очередь, вызывает метод For класса BatchMultipleQueueHandlerT. Метод For возвращает экземпляр BatchMultipleQueueHandlerT, который содержит ссылку на подлежащий мониторингу экземпляр IAzureQueueT.

Соединительный код идентифицирует очередь по имени и сопоставляет ее с типом сообщений (потомком типа AzureQueueMessage). Например, очереди для подписок Standard и Premium работают с одним и тем же типом сообщений — SurveyAnswerStoredMessage. В следующем примере кода показано, как статический метод For класса BatchMultiple QueueHandler создает экземпляр BatchMultipleQueueHandlerT и вызывает метод For, передавая размер пакета в качестве параметра.

C# using Tailspin.Web.Survey.Shared.Stores.AzureStorage;

public static class BatchMultipleQueueHandler { public static BatchMultipleQueueHandlerT ForT(IAzureQueueT queue, int batchSize) where T : AzureQueueMessage { return BatchMultipleQueueHandlerT.For (queue, batchSize);

} } Затем рабочая роль вызывает метод AndFor для каждой дополнительной очереди, задействованной в процессе передачи сообщений. В следующем примере кода показаны методы For и AndFor класса BatchMultipleQueueHandlerT.

C# public static BatchMultipleQueueHandlerT For (IAzureQueueT queue, int batchSize) { if (queue == null) { throw new ArgumentNullException("queue");

} batchSize = Math.Max(1, batchSize);

return new BatchMultipleQueueHandlerT(queue, batchSize);

} ГЛАВА 4

–  –  –

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

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

Применение таблиц маршрутизации MVC Для управления потоком запросов приложение Tailspin Surveys использует таблицы маршрутизации ASP. NET и области MVC, это позволяет идентифицировать подписчика и сопоставлять запросы с соответствующими функциональными возможностями приложения.

В следующем примере кода показано, как общедоступный веб-сайт Surveys использует таблицы маршрутизации, чтобы с помощью URL определить, какой опрос отображать.

C# using System.Web.Mvc;

using System.Web.Routing;

public static class AppRoutes { public static void RegisterRoutes(RouteCollection routes) { routes.MapRoute( "Home", string.Empty, new { controller = "Surveys", action = "Index" });

routes.MapRoute( "ViewSurvey", "survey/{tenant}/{surveySlug}", new { controller = “Surveys”, action = "Display" });

routes.MapRoute( "ThankYouForFillingTheSurvey", "survey/{tenant}/{surveySlug}/thankyou", new { controller = "Surveys", action = "ThankYou" });

} } ГЛАВА 4

–  –  –

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

C# public static void RegisterRoutes(RouteCollection routes) { routes.MapRoute( "OnBoarding", string.Empty, new { controller = "OnBoarding", action = "Index" });

routes.MapRoute( "FederationResultProcessing", "FederationResult", new { controller = "ClaimsAuthentication", action = "FederationResult" });

routes.MapRoute( "FederatedSignout", "Signout", new { controller = "ClaimsAuthentication", action = "Signout" });

}...

} ГЛАВА 4

–  –  –

В следующем примере показано содержимое образца файла ServiceDefinition.csdef и определений двух веб-ролей в приложении Tailspin Surveys.

XML ServiceDefinition name="Tailspin.Cloud" xmlns=...

WebRole name="Tailspin.Web" enableNativeCodeExecution="true" Sites Site name="Web" Bindings Binding name="HttpsIn" endpointName="HttpsIn" / /Bindings /Site /Sites Certificates Certificate name="localhost" storeLocation="LocalMachine" storeName="My" / /Certificates Endpoints InputEndpoint name="HttpsIn" protocol="https" port="443" certificate="localhost" / /Endpoints...

/WebRole WebRole name="Tailspin.Web.Survey.Public" Sites Site name="Web" Bindings Binding name="HttpIn" endpointName="HttpIn" / /Bindings /Site /Sites Endpoints InputEndpoint name="HttpIn" protocol="http" port="80" / /Endpoints...

/WebRole WorkerRole name="Tailspin.Workers.Surveys"...

/WorkerRole /ServiceDefinition ГЛАВА 4 Этот образец файла ServiceDefinition.csdef не совсем аналогичен файлу в загружаемом решении, которое использует другое имя для сертификата SSL.

Вы можете использовать разные сертификаты SSL в ходе тестирования приложения с применением локального эмулятора вычислений. Убедитесь, что файлы конфигурации правильно ссылаются на соответствующие сертификаты, прежде чем публиковать приложение в Windows Azure. Более подробные сведения об управлении развертыванием представлены в главе «3 – Переход к облачным службам Windows Azure» руководства «Перенос приложений в облако, издание 3-е».



Pages:   || 2 | 3 |

Похожие работы:

«Организации по Международному Мониторингу Эффективные Методики для Достижения Перемен Внутри Страны Автор: Пол Магиан Под редакцией: Нэнси Л. Пирсон Тактический учебник опубликован Проектом Новые Тактики под руководством Центра для Жертв Пыток Опубликовано: Центр для Жертв Пыток Новые Тактики в осущ...»

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

«Дм. Льв. ИВАНОВЪ. Горный Инжвнвръ.з * " е — •• ИСКОПАЕМЫЕ УГЛИ ЮЖНО-УССУРІЙСКАГО КРАЯ и СУЧАНСКОЕ МЪСТОРОЖДЕШЕ ВЪ ОСОБЕННОСТИ. С.-ПЕТЖРБУРГЪ. Типографія С. Корнатовскаго, Малая Корская, 9. 1S4. Дозволено цензурою. С.-Петербурга, 24-го Августа 1894 года. Извлеч. изъ M 4 "Изветш О...»

«Оригинальные статьи Хирургическое лечение "рефрактерной" глаукомы Ю.С. Астахов, Е.А. Егоров, СЮ. Астахов, Ю.А. Брезель Surgical treatment at refractory glaucoma Yu.S. Astakhov, E.A. Egorov, S.Yu. Astakhov, Yu.A.Brezel Ophthalmology department of St.-Petersburg State Me...»

«Ф ЕД Е Р А Л Ь Н О Е АГЕНТСТВО ПО Т Е Х Н И Ч Е С К О М У Р Е Г У Л И Р О В А Н И Ю И М Е Т Р О Л О Г И И СВИДЕТЕЛЬСТВО об у т в ер ж д ени и типа средств измерени й RU.C.39.010.A № 43363 Срок действия до 01 августа 2016 г.НАИМЕНОВАНИЕ ТИПА СРЕДСТВ ИЗМЕРЕНИЙ Измери...»

«В ходятъ д раза въ м ы ва сяцъ.Ф Ф Ф.Ф чЬ Ф. А $ * 'г-.и л ^ Цна годовому изданію Подписка принимается въ ре­ & 3 дакціи ьВдомостей* при Бласъ доставкою и пересылкою № 9. 4 говіденск. духовн. Семинаріи. $ ШЕСТЬ рублей серебромъ.. ^ ^ ^ г ч г Г ~...»

«НАУЧНЫЙ ЭКСПЕРТ Научный электронный журнал ВЫПУСК Центр проблемного анализа и государственно-управленческого проектирования Научный эксперт Ежемесячный научный электронный журнал Мы представляем вашему вниманию электронный журнал, название которого полностью отражает е...»

«ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ УЛЬЯНОВСКОЕ ВЫСШЕЕ АВИАЦИОННОЕ УЧИЛИЩЕ ГРАЖДАНСКОЙ АВИАЦИИ (ИНСТИТУТ) Ф ак ул ь тет лётной эксплуа...»

«Государственное бюджетное образовательное учреждение высшего профессионального образования Московской области "Международный университет природы, общества и человека "Дубна" (университет "Дубна") Институт системного анализа и управления Кафедра информационных технологий УТВЕРЖДАЮ проректор...»

«И. А. Бунин Куприн Это было давно — когда я только что узнал о его существовании, впервые увидал в "Русском богатстве" его имя, которое все тогда произносили с ударением на первом слоге, и этим ударением, как я видел это впоследствии, почему-то так оскорбляли его, что он, как всегда в минуты гнева, позвериному щурил глаза, и бе...»

«ВОСЬМОЙ АРБИТРАЖНЫЙ АПЕЛЛЯЦИОННЫЙ СУД ПОСТАНОВЛЕНИЕ от 8 июня 2010 г. по делу N А70-14382/2009 Резолютивная часть постановления объявлена 1 июня 2010 года. Постановление изготовлено в полном объеме 8 июня 2010 года.Восьмой арбитражный апелляционный суд в составе: председательствующего судьи...»

«Праведность возвышает народ, а беззаконие бесчестие народов Воскресение России Газета Пермского центра Христиан Веры Евангельской № 1 (10) февраль апрель 2014г. Выходит с 2009 года "Так говорит...»

«ДАЙДЖЕСТ НОВОСТЕЙ В РОССИЙСКИХ СМИ по вопросам учета налогообложения 21 августа 2008 года (обзор подготовлен пресс-службой компании "РУФАУДИТ") Е.Ю. Афанасьева Особенности бухгалтерского учета ценных бумаг Разъяснены порядок и особенности...»

«БЕЗДЕЙСТВИЕ КАК ФОРМА ПРЕСТУПНОГО ПОВЕДЕНИЯ. ОСОБЕННОСТИ БЕЗДЕЙСТВИЯ В НЕКОТОРЫХ ПРЕСТУПЛЕНИЯХ СО СПЕЦИАЛЬНЫМ СУБЪЕКТОМ Лосева А.В. Институт сферы обслуживания и предпринимательства (филиал) Донского государственного университета Шахты, Россия INA...»

«Приложение №1 Муниципальная программа "Развитие внутреннего и въездного туризма в Курумканском районе на 2017 – 2019 годы" Полное Муниципальная программа "Развитие внутреннего и въездного наименование ту...»

«Рабочая программа учебной дисциплины разработана на основе Федерального государственного образовательного стандарта среднего профессионального образования по специальности 21.02.10 "Геология и разведка нефтяных и газовых месторож...»

«0001 ПЕЧИ БАННЫЕ, УВАЖАЕМЫЙ ПОКУПАТЕЛЬ! ПОЗДРАВЛЯЕМ ВАС С УДАЧНЫМ ВЫБОРОМ! Инструкция по монтажу и эксплуатации предназначена для изучения принципа работы, правил безопасной эксплуатации и обслуживания печи банной "Везувий". К работам по монтажу и эксплуатаци...»

«Инструкция по эксплуатации Многофункциональный инверторный сварочный аппарат MIG-MAG-FLUX / MMA / TIG DC-LIFT MULTIMIG-228 Дата производства: 04/2015 Инструкция по эксплуатации многофункционального инверторного сварочного аппарата MULTIMIG-228 БЫСТРЫЙ ЗАПУСК –2– Инструкция по эксплуатации многофункционал...»

«Электронный научно-образовательный журнал ВГСПУ "Грани познания". №4(31). Апрель 2014 www.grani.vspu.ru И.К. КИМ (Волгоград) гОсударствО, ОБществО, личнОсть в прОграммных дОкументах пОльских пОлитических сил в периОд режима санации в пОльше С опорой на программные документы рассматрива...»

«Департамент кадровой политики Губернатора Свердловской области МАТЕРИАЛЫ межрегионального семинара совещания: "Теория и практика государственной службы: основные направления дальнейшего развития" 7-8 июня 2012 года г. Екатеринбург 2012 г.СОДЕРЖАНИЕ: Гузь В.П. О перспективах и направлениях работы органов государствен...»

«МИНИСТЕРСТВО ТРУДА И СОЦИАЛЬНОЙ ЗАЩИТЫ РОССИЙСКОЙ ФЕДЕРАЦИИ ПИСЬМО от 10 июля 2013 г. N 18-2/10/2-3836 ОБ ОБЗОРЕ РЕКОМЕНДАЦИЙ ПО ОСУЩЕСТВЛЕНИЮ КОМПЛЕКСА ОРГАНИЗАЦИОННЫХ, РАЗЪЯСНИТЕЛЬНЫХ И ИНЫХ МЕР ПО НЕДОПУЩЕНИЮ ДОЛЖНОСТНЫМИ ЛИЦАМИ ПОВЕДЕНИЯ, КОТОРОЕ МОЖЕТ ВОСПРИНИМАТЬСЯ ОКРУЖАЮЩИМИ КАК ОБЕЩАНИЕ ДАЧИ ВЗЯТКИ ИЛИ ПРЕДЛОЖЕНИЕ ДАЧ...»

«Содержание Пояснительная записка Проблема духовно-нравственного воспитания в условиях современного общества 1. приобрела особое значение. Потеря моральных ориентиров, обесценивание таких понятий, как совесть, честь, долг, привели к негативным последствиям в обществе: социальное сиротство,...»

«Не предназначено для выпуска, опубликования или распространения в Австралии, Канаде, Японии или США. Данные материалы не являются предложением к продаже ценных бумаг в США. При отсутствии регистрации в Комис...»

«Инструкция по секс игрушками 25-03-2016 1 Милицейское книгопечатание является диагностической повторимостью, если, и только если безвозбранные ковшики не повышающегося страхуются из надоеды. Человеконенавистник будет приукрашивать, только если неизмельченные и сушильные расследования закончат грохать. Атм...»

«УЗИ опорно-двигательного аппарата Cтандартные плоскости сканирования Standardebenen der Sonografie der Bewegungsorgane Jrn Hinzmann Peter Kupatz Geleitwort von Egmont Scola 2., vollstndig berarbeitete und erweiterte Auage 180 Abbildungen Georg Thieme Verlag Stuttgart New York УЗИ опорно-двигательного аппарата Cтандартные...»

«1 КОМИТЕТ ПО ТРУДУ И ЗАНЯТОСТИ НАСЕЛЕНИЯ САНКТ-ПЕТЕРБУРГА ИНФОРМАЦИОННЫЙ БЮЛЛЕТЕНЬ "ОХРАНА И БЕЗОПАСНЫЕ УСЛОВИЯ ТРУДА" № 4 (33) 2015 Санкт-Петербург Декабрь 2015 года "Охрана и безопасные условия труда" № 4 (33) 2015 СОДЕРЖАНИЕ Приказ Министерства труда и социальной защиты Российской Федерации от 1...»

«Из решения Коллегии Счетной палаты Российской Федерации от 24 декабря 2014 года № 64К (1010) "О результатах контрольного мероприятия "Проверка полноты уплаты таможенных платежей, соблюдения мер таможенно-тарифного...»

«Н.К. Кононова ЦИРКУЛЯЦИОННЫЕ ХАРАКТЕРИСТИКИ КЛИМАТИЧЕСКИХ ЭКСТРЕМУМОВ Исследования последних лет показали, что в 20—30-е и 60—70-е годы прошлого века в развитии циркуляционных процессов Северного полушария отмечались зональные...»

«Данная рабочая программа составлена на основе Программы общеобразовательных учреждений Начальная школа УМК " Планета знаний", примерной программы по предмету "Технология", рекомендованной Министерством образования РФ, программы О....»










 
2017 www.book.lib-i.ru - «Бесплатная электронная библиотека - электронные ресурсы»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.