Проектирование приложений критически важных рабочих нагрузок в Azure
При разработке приложения критически важны требования к функциональным и нефункциональным приложениям. В этой области проектирования описываются шаблоны архитектуры и стратегии масштабирования, которые помогают обеспечить устойчивость приложения к сбоям.
Внимание
Эта статья является частью серии критически важных рабочих нагрузок Azure Well-Architected Framework. Если вы не знакомы с этой серией, мы рекомендуем вам начать с Что такое критически важная рабочая нагрузка?
Архитектура единиц масштабирования
Все функциональные аспекты решения должны быть способны к масштабированию в соответствии с изменениями спроса и, в идеале,
Мы рекомендуем этот подход, так как он отвечает ограничениям масштаба отдельных ресурсов и всего приложения. Это помогает в сложных сценариях развертывания и обновления, так как единица масштабирования может быть развернута как одна единица. Кроме того, можно протестировать и проверить определенные версии компонентов в модуле, прежде чем направлять в него трафик пользователей.
Предположим, что ваше критически важное приложение — это онлайн-каталог продуктов. Он имеет поток пользователя для обработки комментариев и оценок продукта. Поток использует API для получения и публикации комментариев и оценок, а также вспомогательных компонентов, таких как конечная точка OAuth, хранилище данных и очереди сообщений. Конечные точки статических API представляют собой детализированные функциональные единицы, которые должны адаптироваться к изменениям по требованию. Базовая платформа приложений также должна иметь возможность масштабироваться соответствующим образом. Чтобы избежать узких мест производительности, подчиненные компоненты и зависимости также должны масштабироваться до соответствующей степени. Они могут масштабироваться независимо, как отдельные единицы масштабирования или вместе в рамках одной логической единицы.
Примеры единиц масштабирования
На следующем рисунке показаны возможные области для единиц масштабирования. Области варьируются от модулей pod микрослужб до узлов кластера и меток регионального развертывания.
Диаграмма, показывающая различные диапазоны единиц масштабирования.
Рекомендации по проектированию
Область. Область единицы масштабирования, связь между единицами масштабирования и их компонентами должна быть определена в соответствии с моделью емкости. Учитывайте нефункциональный требования к производительности.
Ограничения масштаба. Ограничения и квоты масштаба подписки Azure могут иметь отношение к проектированию приложений, выбору технологий и определению единиц масштабирования. Единицы масштабирования помогают обойти ограничения масштабирования службы. Например, если кластер AKS в одном модуле может иметь только 1000 узлов, можно использовать два единицы для увеличения этого ограничения до 2000 узлов.
Ожидаемая загрузка. Используйте количество запросов для каждого потока пользователя, ожидаемой пиковой частоты запросов (запросов в секунду) и шаблонов ежедневного и еженедельного или сезонного трафика для информирования основных требований к масштабированию. Кроме того, следует учитывать ожидаемые шаблоны роста как для трафика, так и для объема данных.
Приемлемое снижение производительности. Определите, является ли сервис с ухудшенным качеством и долгим временем отклика приемлемым при нагрузке. При моделировании необходимой емкости критически важным фактором является производительность решения под нагрузкой.
Нефункциональные требования. Технические и бизнес-сценарии имеют различные аспекты устойчивости, доступности, задержки, емкости и наблюдаемости. Анализ этих требований в контексте конечных пользовательских потоков. У вас будет относительная гибкость в проектировании, принятии решений и выборе технологий на уровне пользовательского потока.
Рекомендации по проектированию
Определите область применения единицы масштабирования и условия, при которых она будет активироваться.
Убедитесь, что все компоненты приложения могут масштабироваться независимо или как часть единицы масштабирования, которая включает другие связанные компоненты.
Определите связь между единицами масштабирования на основе модели емкости и нефункциональными требованиями.
Определите метку регионального развертывания, чтобы объединить подготовку, управление и операцию ресурсов регионального приложения в разнородном, но взаимозависимом масштабируемом модуле. По мере увеличения нагрузки можно развертывать дополнительные метки в одном регионе Azure или в разных регионах Azure, чтобы горизонтально масштабировать решение.
Используйте подписку Azure в качестве единицы масштабирования, чтобы ограничения масштабирования в одной подписке не ограничивают масштабируемость. Этот подход применяется к сценариям с высокомасштабируемыми приложениями, имеющими значительный объем трафика.
Определите необходимую емкость на основе выявленных шаблонов трафика, чтобы обеспечить достаточную емкость в периоды пиковых нагрузок и избежать ухудшения качества обслуживания. Кроме того, оптимизируйте емкость в нерабочие часы.
Измеряйте время, необходимое для горизонтального увеличения и уменьшения, чтобы гарантировать, что естественные вариации трафика не приводят к неприемлемому ухудшению качества обслуживания. Отслеживайте длительности операций масштабирования как операционную метрику.
Примечание.
При развертывании в стартовой зоне Azure убедитесь, что подписка этой зоны выделена приложению для обеспечения четкой границы управляемости и предотвращения антипаттерна «шумного соседа».
Глобальное распределение
Невозможно избежать сбоя в любой высоко распределенной среде. В этом разделе приведены стратегии устранения многих сценариев сбоя. Приложение должно иметь возможность противостоять региональным и зональным сбоям. Его необходимо развернуть в активной/активной модели так, чтобы нагрузка распределялась по всем регионам.
Просмотрите это видео, чтобы получить общие сведения о планировании сбоев в критически важных приложениях и максимальной устойчивости:
Рекомендации по проектированию
Избыточность. Приложение должно быть развернуто в нескольких регионах. Кроме того, в регионе мы настоятельно рекомендуем использовать зоны доступности, чтобы обеспечить устойчивость к сбоям на уровне центра обработки данных. Зоны доступности имеют периметр задержки менее 2 миллисекунда между зонами доступности. Для рабочих нагрузок, которые часто взаимодействуют между зонами, эта задержка может привести к снижению производительности при передаче данных между зонами.
Активно-активная модель. Рекомендуется использовать стратегию активного и активного развертывания, так как она обеспечивает максимальную доступность и обеспечивает более высокое соглашение об уровне обслуживания (SLA). Однако это может привести к проблемам синхронизации данных и согласованности для многих сценариев приложений. Решение проблем на уровне платформы данных при рассмотрении компромиссов с повышенными затратами и инженерными усилиями.
Активное или активное развертывание в нескольких облачных поставщиках — это способ потенциально снизить зависимость от глобальных ресурсов в одном поставщике облачных служб. Однако стратегия многооблачного активно-активного развертывания вносит значительную сложность в отношении CI/CD. Кроме того, учитывая различия в спецификациях ресурсов и возможностях между поставщиками облачных служб, вам потребуется специализированные метки развертывания для каждого облака.
Географическое распределение. Рабочая нагрузка может иметь требования к соответствию географическому расположению данных, защите данных и хранению данных. Рассмотрите, есть ли определенные регионы, в которых должны находиться данные или где должны быть развернуты ресурсы.
Источник запроса. Географическое расположение и плотность пользователей или зависимых систем должно информировать о принятии решений о глобальном распределении.
Подключение. То, как пользователи или внешние системы получают доступ к рабочей нагрузке, будет влиять на ваш дизайн. Рассмотрите возможность доступности приложения через общедоступный Интернет или частные сети, использующие каналы VPN или Azure ExpressRoute.
Рекомендации по проектированию и выбор конфигурации на уровне платформы см. в разделе "Платформа приложений: глобальное распределение".
Архитектура слабо связанная на основе событий
Сцепление обеспечивает взаимодействие служб через чётко определённые интерфейсы. Слабое соединение позволяет компоненту приложения работать независимо. Стиль архитектуры микрослужб соответствует критически важным требованиям. Это обеспечивает высокую доступность, предотвращая каскадные сбои.
Для обеспечения свободного связывания мы настоятельно рекомендуем использовать событийно-ориентированную архитектуру. Асинхронная обработка сообщений через посредника может создать устойчивость.
Схема, иллюстрирующая асинхронную связь, управляемую событиями.
В некоторых сценариях приложения могут объединять свободное и жесткое связывание в зависимости от бизнес-целей.
Рекомендации по проектированию
Зависимости среды выполнения. Свободно связанные службы не должны быть ограничены для использования одной вычислительной платформы, языка программирования, среды выполнения или операционной системы.
Масштабирование. Службы должны быть в состоянии масштабироваться независимо. Оптимизируйте использование ресурсов инфраструктуры и платформы.
Отказоустойчивость. Ошибки должны обрабатываться отдельно и не должны влиять на клиентские транзакции.
Целостность транзакций. Рассмотрим эффект создания и сохраняемости данных, происходящих в отдельных службах.
Распределенная трассировка. Для выполнения сквозной трассировки может понадобиться сложная оркестрация.
Рекомендации по проектированию
Выравнивание границ микрослужбы с критически важными потоками пользователей.
Используйте асинхронное взаимодействие на основе событий, где это возможно для поддержки устойчивого масштабирования и оптимальной производительности.
Используйте такие шаблоны, как исходящий и транзакционный сеанс, чтобы гарантировать согласованность, чтобы каждое сообщение было обработано правильно.
Пример: подход на основе событий
Эталонная реализация Mission-Critical Online использует микросервисы для обработки одной бизнес-транзакции. Она выполняет операции записи асинхронно, используя брокер сообщений и работника. Операции чтения синхронны, и результат возвращается напрямую вызывающему коду.
Схема, показывающая взаимодействие на основе событий.
Шаблоны устойчивости и обработка ошибок в коде приложения
Критически важное приложение должно быть разработано таким образом, чтобы обеспечивать устойчивость и учитывать как можно больше сценариев сбоя. Эта устойчивость обеспечивает максимальную доступность и надежность служб. Приложение должно иметь возможности самостоятельного восстановления, которые можно реализовать с помощью шаблонов проектирования, таких как повторные попытки с отступлением и автоматическое выключение.
Для постоянных сбоев, которые невозможно полностью устранить с помощью логики приложения, модель состояния системы и операционные обёртки должны предпринять корректирующие действия. Код приложения должен включать надлежащее инструментирование и ведение журнала для информирования модели работоспособности и упрощения последующего устранения неполадок или анализа первопричин по мере необходимости. Необходимо реализовать распределенную трассировку, чтобы предоставить вызывающему абоненту понятное сообщение об ошибке, включающее идентификатор корреляции в случае возникновения сбоя.
Такие средства, как Application Insights, помогают выполнять запросы, производить корреляцию и визуализировать трассировки приложений.
Рекомендации по проектированию
Правильные конфигурации。 Не редкость, когда временные проблемы приводят к каскадным сбоям. Например, повторные попытки без соответствующей задержки усугубят проблему при ограничении скорости работы сервиса. Вы можете распределять задержки между повторными попытками линейно или увеличивать их экспоненциально для уменьшения интенсивности через растущие задержки.
Показатели здоровья. Функциональные проверки в коде приложения можно предоставлять с помощью конечных точек работоспособности, которые внешние решения могут опрашивать для получения состояния работоспособности компонента приложения.
Рекомендации по проектированию
Ниже приведены некоторые распространенные шаблоны проектирования программного обеспечения для устойчивых приложений:
| Расписание | Итоги |
|---|---|
| Выравнивание нагрузки на основе очередей | Представляет буфер между потребителями и запрошенными ресурсами, чтобы обеспечить согласованные уровни нагрузки. По мере того как запросы потребителей помещаются в очередь, рабочий процесс обрабатывает их в соответствии с запрошенным ресурсом в темпе, заданном рабочей ролью и возможностью запрашиваемого ресурса обрабатывать запросы. Если потребители ожидают ответов на их запросы, необходимо реализовать отдельный механизм реагирования. Примените приоритетный порядок, чтобы наиболее важные действия выполнялись сначала. |
| Прерыватели цепи | Обеспечивает стабильность, ожидая восстановления или быстро отклоняя запросы, а не блокируя при ожидании недоступной удаленной службы или ресурса. Этот шаблон также обрабатывает ошибки, которые могут занять переменное время для восстановления после подключения к удаленной службе или ресурсу. |
| Распределительный блок | Пытается разделять экземпляры сервисов на группы на основе требований к нагрузке и доступности, изолируя сбои для поддержания функциональности сервисов. |
| Сага | Управляет согласованностью данных между микрослужбами, имеющими независимые хранилища данных, обеспечивая обновление служб с помощью определенных каналов событий или сообщений. Каждая служба выполняет локальные транзакции для обновления собственного состояния и публикует событие для активации следующей локальной транзакции в саге. Если обновление службы завершается сбоем, сага выполняет компенсирующие транзакции, чтобы компенсировать действия, предпринятые на предыдущих этапах обновления службы. Отдельные действия по обновлению службы могут реализовать шаблоны устойчивости, такие как повторная попытка. |
| Мониторинг точек проверки состояния | Реализует функциональные тесты в приложении, к которому внешние средства могут обращаться через открытые конечные точки с регулярными интервалами. Вы можете интерпретировать ответы от конечных точек, используя ключевые операционные метрики для информирования о состоянии приложения и активации операционных ответов, таких как выдача предупреждения или выполнение компенсирующего развертывания отката. |
| Повторить | Элегантно и незаметно обрабатывает временные сбои.
— Отмените, если ошибка вряд ли будет носить временный характер и вряд ли будет успешно устранена, если попытаться выполнить операцию снова. — Повторите попытку, если ошибка редкая или нехарактерная, и операция, скорее всего, будет выполнена успешно при повторной попытке сразу же. — повторите попытку после задержки, если ошибка вызвана условием, которое может потребовать короткого времени для восстановления, таких как сетевое подключение или сбои высокой нагрузки. Примените подходящую стратегию отката по мере увеличения задержек повторных попыток. |
| Регулирование | Управляет потреблением ресурсов, используемых компонентами приложений, что защищает их от чрезмерного использования. Когда ресурс достигает порогового значения нагрузки, он откладывает операции с более низким приоритетом и уменьшает несущественную функциональность, чтобы основная функциональность могла продолжаться до тех пор, пока не будут доступны достаточные ресурсы для возвращения к нормальной работе. |
Ниже приведены некоторые дополнительные рекомендации.
Используйте предоставленные поставщиком пакеты SDK, такие как пакеты SDK Azure, для подключения к зависимым службам. Используйте встроенные возможности устойчивости вместо реализации пользовательских функций.
Применяйте подходящую стратегию отката при повторных попытках вызова зависимостей, чтобы избежать искусственного сценария DDoS-атаки.
Определите общие критерии проектирования для всех команд микрослужб приложений для обеспечения согласованности и скорости использования шаблонов устойчивости на уровне приложения.
Рассмотрите возможность реализации шаблонов устойчивости с помощью проверенных стандартных пакетов, таких как Polly для C# или Sentinel для Java. Кроме того, платформы обмена сообщениями, такие как NServiceBus или MassTransit предоставляют встроенные функции устойчивости, что помогает избежать необходимости в дополнительном коде надежности.
Используйте идентификаторы корреляции для всех событий трассировки и сообщений журнала, чтобы связать их с заданным запросом. Возвращать идентификаторы корреляции вызывающей стороне для всех вызовов, а не только для неудачных запросов.
Используйте структурированное ведение журнала для всех сообщений. Выберите единый приемник операционных данных для трассировок приложений, метрик и журналов, чтобы операторы могли легко отлаживать проблемы. Дополнительные сведения см. в разделе «Сбор, агрегация и хранение данных мониторинга для облачных приложений».
Убедитесь, что операционные данные используются вместе с бизнес-требованиями для формирования модели работоспособности приложений.
Выбор языка программирования
Важно выбрать правильные языки программирования и платформы. Эти решения часто определяются наборами навыков или стандартизованными технологиями в организации. Однако важно оценить производительность, устойчивость и общие возможности различных языков и платформ.
Рекомендации по проектированию
Возможности комплекта средств разработки. Существуют различия в возможностях, предлагаемых пакетами SDK службы Azure на различных языках. Эти различия могут повлиять на выбор службы Azure или языка программирования. Например, если Azure Cosmos DB является возможным вариантом, Go может не быть подходящим языком разработки, так как не существует стороннего пакета SDK.
Обновления функций. Рассмотрим частоту обновления пакета SDK с новыми функциями для выбранного языка. Часто используемые пакеты SDK, такие как библиотеки .NET и Java, часто обновляются. Другие пакеты SDK или пакеты SDK для других языков могут обновляться реже.
Несколько языков программирования или платформ. Для поддержки различных составных рабочих нагрузок можно использовать несколько технологий. Однако следует избежать разрастания, так как она представляет сложность управления и операционные проблемы.
Опция вычисления. Устаревшее или закрытое программное обеспечение может не выполняться в службах PaaS. Кроме того, вы не сможете включать устаревшее или закрытое программное обеспечение в контейнеры.
Рекомендации по проектированию
Оцените все соответствующие пакеты SDK Azure для необходимых возможностей и выбранных языков программирования. Проверьте соответствие нефункциональным требованиям.
Оптимизируйте выбор языков программирования и платформ на уровне микрослужбы. Используйте несколько технологий по мере необходимости.
Определите приоритет пакета SDK для .NET для оптимизации надежности и производительности. Пакеты SDK для .NET Azure обычно предоставляют дополнительные возможности и часто обновляются.
Следующий шаг
Ознакомьтесь с рекомендациями по платформе приложений.
Платформа приложений