Была ли эта страница полезной?
Ваш отзыв об этом контенте важен для нас. Расскажите нам о том, что вы думаете.
Дополнительный отзыв?
1500 символов осталось
MSDN Library

Рекомендации по разработке для облачных служб Azure

Обновлено: Июнь 2014 г.

Авторы: Селсин Тюркаслан (Selcin Turkarslan)

Рецензенты:Тим Виман (Tim Wieman), Валерий Мизонов (Valery Mizonov), Авилай Парех (Avilay Parekh), Паоло Сальватори (Paolo Salvatori), Стив Говард (Steve Howard)

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

  • Компоненты Azure.

  • Модели выполнения.

  • Управление данными.

  • Сеть.

  • Поддерживаемые пакеты средств разработки программного обеспечения (SDK) и т. д.

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

Миграция существующего приложения в Azure включает следующие действия.

  • Выбор модели выполнения вычисления, которая лучше всего подходит для вашего приложения (например, облачные службы, веб-сайты, виртуальные машины (VM) и т. д.). Прочтите статью «Знакомство с Azure: модели выполнения».

  • Добавление конкретной конфигурации Azure и пользовательского кода.

  • Хранение данных и управление ими в Azure.

  • Повторная упаковка существующего приложения как приложения Azure.

  • Развертывание приложения в Azure.

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

  • Соглашения об уровне обслуживания.

  • Планирование загрузки.

  • Выставление счетов клиентам.

  • Аудит.

  • Мониторинг приложений.

  • Анализ трафика.

  • Управление затратами.

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

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

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

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

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

В дополнение к функциональному различию ролей каждая роль служит для приложения в качестве единицы масштабирования. Например, у вас есть 20 экземпляров веб-роли для обслуживания большего количества трафика. Это значит, что вы можете иметь только 5 экземпляров рабочей роли для асинхронной обработки запросов веб-роли. Если нужно создать простое приложение ASP.NET, PHP, Node.js или веб-службу, можно использовать только веб-роль. Рекомендуется выполнить подробные тесты на функциональность и эффективность в облачной службе. Эти тесты позволят вам определить оптимальное число экземпляров роли и размера VM, перед тем как развертывать приложение в рабочей среде. Дополнительные сведения о концепциях облачных служб см. в Центре разработчика Azure и Центре документации Azure.

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

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

  • Наиболее близкие к большинству клиентов.

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

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

Перед началом реализации облачной службы Azure необходимо сначала получить подписку на Microsoft Azure. Дополнительные сведения см. на веб-сайте Microsoft Azure. Теперь нужно подготовить среду разработки. Корпорация Майкрософт предоставляет зависящие от языка программирования пакеты SDK для .NET, Java, PHP, Node.js, Python и Ruby. Самые последние сведения о поддерживаемых языках программирования и платформах см. в Центре документации Microsoft Azure. Кроме того, для доступа ко всем клиентским библиотекам, пакетам SDK и средствам командной строки Azure можно использовать Центр загрузки средств и пакета SDK Azure.

Microsoft Azure также предоставляет службу веб-сайтов Azure для размещения веб-сайтов и веб-приложений. Веб-сайты Azure — это полностью управляемое предложение PaaS, которое позволяет развертывать и масштабировать веб-приложения за секунды. Дополнительные сведения см. в разделе веб-сайты Azure.

Чтобы разрешить клиентским приложениям, выполняющимся на разных платформах, подключаться к источникам реляционных данных, корпорация Майкрософт выбрала ODBC. Это стандартное клиентское подключение API для собственных клиентских приложений, которые подключаются к базе данных SQL Azure (база данных SQL). Поставщик OLE DB для собственного клиента SQL Server будет в последний раз поставляться в SQL Server 2012. Он не будет поддерживаться в базе данных SQL.

При записи приложений в Windows или Azure используйте поставщик данных .NET для SQL Server. Кроме того, можно использовать драйвер ODBC для собственного клиента SQL Server, который поставляется вместе с версией SQL Server 2008 R2 или более поздней. При разработке новых или будущих версий приложения рекомендуется адаптировать ODBC. Существующие приложения, использующие OLE DB, рекомендуется использовать для миграции на ODBC в будущем. Дополнительные сведения о преобразовании приложения OLE DB в приложение ODBC см. в разделе «Преобразование приложений SQL Server из OLE DB в ODBC». Сведения о группе ADO.NET по устаревшим компонентам OLE DB см. разделе «Объявление об устаревших компонентах поставщика OLE DB Microsoft SQL Server».

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

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

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

Далее перечисляются некоторые доступные средства поиска и устранения неполадок и разные виды техники для Azure.

  • Средство диагностики Azure (WAD). Это средство выполняет сбор данных операций и диагностических данных службы Azure. Служба диагностики Azure записывает в журналы диагностические данные из различных источников данных:

      • журналы служб IIS;

      • журналы инфраструктуры диагностики Windows;

      • журналы событий Windows;

      • счетчики производительности;

      • аварийные дампы;

      • пользовательские журналы ошибок.

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

  • Пакет управления System Center Azure. Пакет управления мониторингом в Azure позволяет отслеживать доступность и производительность приложений, выполняющихся в Azure. Дополнительные сведения см. в разделе «Руководство по пакету мониторинга для приложений Azure». Рекомендуется использовать диагностику Azure и пакет управления System Center Azure. Дополнительные сведения см. в видео на веб-странице System Center 2012: управление приложениями в частном и общедоступном облаках.

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

  • Управление подключениями к базе данных SQL. С его помощью обрабатываются коды ошибок путем реализации в приложении логики повторных попыток. Дополнительные сведения см. в разделе «Управление ресурсами базы данных SQL Azure».

  • Командлеты PowerShell Azure: Они позволяют просматривать и настраивать облако и службы управления данными Azure, а также управлять ими непосредственно из PowerShell. Эти средства могут быть полезны при разработке и тестировании приложений, которые используют службы Azure. Дополнительные сведения см. в разделе «Ссылки на командлеты Azure».

  • Решение ссылки Основы облачных служб. В этом приложении демонстрируется, как создать службы Azure, резервное копирование которых выполняется в базе данных. Эта демонстрация основана на подходе, разработанном группой консультирования клиентов Microsoft Azure во время работы с реальными клиентами. Узнайте базовые компоненты для горизонтального масштабирования приложений Azure, включая сбор и использование данных телеметрии в приложении. Решение ссылки находится на веб-странице Основы облачных служб в Microsoft Azure. Руководство включает вики-сайт TechNet (Вики-сайт основ облачных служб) с подробными статьями.

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

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

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

  • Очереди хранилища Azure. Очереди хранилища Azure можно использовать для хранения сообщений, к которым клиенты могут получить доступ, а также для предоставления надежного обмена сообщениями между экземплярами ролей. Дополнительные сведения см. в разделах «Использование хранилища очередей из .NET» и «Хранилище».

  • Шина обслуживания Azure. Рекомендуется использовать служебную шину Azure для любого взаимодействия между службами Azure. Кроме того, используйте служебную шину Azure для сохранения интеграции между локальными серверами и Azure. Шина обслуживания предоставляет безопасные возможности обмена сообщениями и ретрансляции на уровне приложений. Служебная шина Azure предлагает облачную инфраструктуру обмена сообщениями, которая поддерживает обычную, безопасную службу сообщений в общедоступной сети. Она предоставляет простое, унифицированное пространство имен, например, https://myhostname.servicebus.windows.net. Шина обслуживания поддерживает следующие модели программирования: API-интерфейс .NET, API-интерфейс REST и WCF. Дополнительные сведения см. на веб-странице Документация служебной шины и в разделе «Сравнительный анализ очередей Azure и очередей служебной шины».

  • Azure Active Directory. Рекомендуется использовать Azure Active Directory (AD) для предоставления горизонтально масштабируемого управления доступом на базе утверждений для веб-служб и пользовательских приложений, размещаемых в облаке. Azure Active Directory — это полное облачное решение по управлению удостоверениями и доступом. Оно совмещает основные службы каталогов, расширенное управление удостоверениями, безопасность и управление доступом к приложению. Azure AD также предлагает разработчикам платформу управления удостоверениями для доставки элементов управления доступом в приложения на базе централизованной политики и правил. Служба обеспечивает также интеграцию с Windows Identity Foundation (WIF). Дополнительные сведения см. в разделе «Проверка подлинности веб-пользователей с помощью управления доступом Azure Active Directory» и на веб-странице Документация Azure Active Directory.

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

  • Сеть доставки содержимого Azure. Сеть доставки содержимого Azure (CDN) предлагает разработчикам глобальное решение для кэширования содержимого. Можно кэшировать содержимое в ближайших к клиентам расположениях для предоставления лучшего взаимодействия с вашим приложением. CDN кэширует большие двоичные объекты и статические выходные данные экземпляров вычисления Azure в стратегических расположениях. Благодаря этому CDN предоставляет максимальную пропускную способность для доставки содержимого пользователям. Доставку CDN для поставщиков содержимого можно активировать с использованием портала управления платформой Azure. Дополнительные сведения см. на веб-странице Документация Azure CDN.

  • Виртуальная сеть Azure: Виртуальная сеть Azure позволяет создать логически изолированный раздел в Azure. Затем можно безопасно подключить его к локальному центру обработки данных или одному клиентскому компьютеру с помощью подключения IPsec. Виртуальная сеть упрощает использование масштабируемой инфраструктуры Azure по запросу. Она также обеспечивает локальное подключение к данным и приложениям, в том числе к системам под управлением Windows Server, UNIX и мейнфреймам. Дополнительные сведения см. на веб-странице Документация виртуальной сети.

  • Azure ExpressRoute. Azure ExpressRoute позволяет создавать частные подключения между центрами обработки данных Azure и локальной или совместно используемой инфраструктурой. Подключения ExpressRoute не выходят в общедоступный Интернет. Они обеспечивают высокую надежность, защищенность, скорость работы и меньшую задержку по сравнению с обычными подключениями через Интернет. При помощи ExpressRoute можно устанавливать подключения к Azure в расположении ExpressRoute (на территории поставщика Exchange). Кроме того, можно напрямую подключаться к Azure из существующей сети WAN (например, из сети MPLS VPN). Дополнительные сведения см. на веб-страницах Общие сведения об ExpressRoute и Документация ExpressRoute.

Дополнительные сведения см. на веб-странице Сетевые службы.

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

  • Новое развертывание

  • Изменения конфигурации

  • Добавочное обновление кода

  • Существенное обновление

Дополнительные сведения см. в разделах «Управление облачными службами», «Управление развертываниями в Azure» и «Управление службами».

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

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

См. также

Показ:
© 2015 Microsoft