Принципы проектирования для приложений Azure

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

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

Основные принципы

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

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

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

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

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

Операционные принципы

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

  • Используйте управляемые службы. Используйте платформу как службу (PaaS), а не инфраструктуру как службу (IaaS). Управляемые службы снижают операционные издержки, предоставляют встроенные возможности масштабирования и позволяют командам сосредоточиться на логике приложений, а не на обслуживании инфраструктуры.

  • Используйте службу удостоверений. Используйте платформу управляемых удостоверений, например идентификатор Microsoft Entra, вместо создания или эксплуатации собственной системы удостоверений. Управляемые решения обеспечивают хранение учетных данных, функции проверки подлинности, возможности федерации и соответствие отраслевым стандартам.

Стратегические принципы

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

  • Создавайте с учётом потребностей бизнеса. Принятие решений по проектированию на основе бизнес-требований. Определите четкие цели, такие как цели времени восстановления (ОСРВ), документируйте соглашения об уровне обслуживания (SLA) и целевые уровни обслуживания (SLO), моделируйте приложения в рамках бизнес-доменов и планируйте рост, балансируя функциональные и нефункциональные требования.

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

Применение этих принципов

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

  • Начните с бизнес-требований , чтобы понять, что вы создаете и почему.

  • Проектирование с учетом отказов путем реализации возможностей самовосстановления и избыточности.

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

  • Используйте службы Azure для снижения операционной сложности и сосредоточиться на бизнес-логике.

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

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