Поделиться через

Основы архитектуры приложений Azure

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

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

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

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

Типичный проект на месте

  • Монолитные и совмещенные функции и данные
  • Предназначено для прогнозируемого масштаба или избыточного ресурсоснабжения
  • Реляционная база данных
  • Синхронизированная обработка
  • Предназначен для предотвращения отказов и измеряет среднее время между отказами (MTBF)
  • Ресурсы подготавливаются с помощью ИТ-функций
  • Серверы Snowflake и домашние серверы

Типичный облачный дизайн

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

Разработка приложений для Azure

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

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

Соответствие стандартам внедрения облачных решений организации

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

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

Следуйте Well-Architected Framework

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

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

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

Общие сведения о стандартных стилях архитектуры

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

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

Рабочие нагрузки в Well-Architected Framework

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

Наилучшие практики

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

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

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

Каталог шаблонов облачного проектирования Azure решает конкретные проблемы в распределенных системах.

Выбор информированных технологий

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

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

Оценка эталонных архитектур

Центр архитектуры Azure содержит статьи о идеях решения, примерах рабочих нагрузок и эталонных архитектурах. В этих статьях обычно перечислены общие компоненты и рекомендации, которые соответствуют Well-Architected Framework. Некоторые из этих статей включают развертываемое решение, размещенное на сайте GitHub. Хотя маловероятно, что один из этих сценариев точно соответствует тому, что вы создаёте, они являются хорошей отправной точкой. Вы можете адаптировать рекомендации в соответствии с конкретными потребностями.

Просмотрите каталог архитектур в Центре архитектуры Azure.

Ознакомьтесь со руководствами для конкретной службы

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

  • руководства по платформеWell-Architected Framework: Платформа Well-Architected предоставляет статьи о многих службах Azure. В статьях к каждой службе применяются пять основных принципов архитектуры.

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

Переходите с другой облачной платформы?

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

Следующий шаг

  • Стили архитектуры