Проектирование приложений критически важных рабочих нагрузок в Azure

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

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

Важно!

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

GitHub logoПроект критически важных открытый код

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

Архитектура единиц масштабирования

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

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

Совет

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

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

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

Mission-critical scale units

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

Рекомендации по проектированию

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

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

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

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

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

При проектировании высокодоступной архитектуры сначала задавайте эти вопросы.

Сколько запросов требуется для поддержки каждого потока пользователя? Прогнозируются ли шаблоны использования?

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

Ожидается ли рост трафика? С какой скоростью он будет расти?

Ожидаемые шаблоны роста как для трафика, так и для объема данных информируют о разработке, о устойчивом масштабе.

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

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

Рекомендации по проектированию

  • Определите единицу масштабирования при превышении ограничений масштабирования одного развертывания.

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

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

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

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

Примечание

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

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

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

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

Важно!

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

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

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

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

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

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

Пример. Подход к единицам масштабирования подписки

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

Mission-Critical Subscription Scale Units

Глобальное распределение

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

Ниже приведены некоторые стратегии по устранению многих сценариев сбоя.

  • Зоны доступности (AZ) позволяет выполнять высокодоступные региональные развертывания в разных центрах обработки данных в пределах региона. Почти все службы Azure доступны в зональной конфигурации (где служба закреплена в определенной зоне) или в избыточной между зонами конфигурации (где платформа автоматически обеспечивает охват службы между зонами и может выдержать сбой зоны). Эти конфигурации обеспечивают отказоустойчивость до уровня центра обработки данных.

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

Стратегия развертывания "активный — активный" представляет собой золотой стандарт, так как он обеспечивает максимальную доступность и обеспечивает более высокий составной соглашение об уровне обслуживания (SLA). Хотя активный — активный — это рекомендуемый подход, он может привести к проблемам синхронизации данных и согласованности во многих сценариях приложений, и эти проблемы должны быть полностью решены на уровне платформы данных с другими компромиссами, от увеличения воздействия затрат и увеличения технических усилий.

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

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

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

Mission-critical online architecture

Рекомендации по проектированию

  • Не все службы или возможности доступны в каждом регионе Azure, поэтому в зависимости от выбранных регионов развертывания могут возникнуть последствия доступности службы. — Например, Зоны доступности недоступны в каждом регионе.

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

  • Практика развертывания Azure Сейф (SDP) гарантирует, что все изменения кода и конфигурации (плановое обслуживание) на платформе Azure проходят поэтапное развертывание с анализом работоспособности при обнаружении какого-либо ухудшения состояния во время выпуска. После успешного завершения этапов Canary и Pilot обновления платформы сериализуются между региональными парами, обеспечивая одновременное обновление только одного региона в каждой паре.

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

При разработке глобально распределенной архитектуры начните с этих вопросов.

Существуют ли определенные регионы, в которых должны находиться данные или где должны быть развернуты ресурсы?

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

Откуда физически исходят запросы?

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

Будут ли пользователи подключаться из домашних и (или) организационных сетей? Можно ли ожидать, что все пользователи будут иметь быстрые подключения к Интернету?

Метод подключения, с помощью которого пользователи или системы обращаются к приложению, будь то через общедоступный Интернет или частные сети с помощью ПОДКЛЮЧЕНИЯ VPN или Express Route.

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

  • Зоны доступности периметр задержки менее 2 миллисекунда между зонами доступности.

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

Рекомендации по проектированию

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

    Важно!

    Для сценариев, предназначенных для >SLO = 99,99 %, рекомендуется как минимум три региона развертывания, чтобы максимально увеличить составное соглашение об уровне обслуживания и общую надежность.

  • Используйте стратегию развертывания "активный — активный", где это возможно для максимальной надежности.

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

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

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

  • Определите и проверьте цели точки восстановления (RPO) и цели времени восстановления (RTO).

  • Географическое размещение ресурсов Azure с пользователями для минимизации сетевой задержки и максимальной комплексной производительности.

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

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

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

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

    • Если подходит только один регион Azure, следует развернуть несколько меток развертывания ("региональные единицы масштабирования") в выбранном регионе, чтобы снизить некоторые риски, используя Зоны доступности для обеспечения отказоустойчивости на уровне центра обработки данных. Однако такой значительный компромисс в географическом распределении резко ограничивает достижимые составные соглашения об уровне обслуживания и общую надежность.
    • Если подходящие регионы Azure не предоставляют все необходимые возможности, будьте готовы к компрометации согласованности с метками регионального развертывания, чтобы определить приоритеты географического распределения и повысить надежность.
      • Например, если география ограничена двумя регионами, где поддерживается только один регион Зоны доступности (модель центра обработки данных 3 + 1), создайте шаблон дополнительного развертывания с помощью изоляции домена сбоя, чтобы обеспечить развертывание обоих регионов в активной конфигурации, гарантируя, что основной регион содержит несколько меток развертывания.
  • Согласование текущей доступности служб с стратегиями развития продуктов при выборе регионов развертывания; Не все службы могут быть доступны в каждом регионе в день 1.

  • Используйте Зоны доступности, где это возможно, для максимальной доступности в одном регионе Azure.

Пример: подход к глобальному распределению

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

Mission-Critical Global Distribution

Слабо связанной архитектуры на основе событий

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

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

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

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

Asynchronous event-driven communication

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

Рекомендации по проектированию

  • Не все содержимое, которое решение делает доступным через Интернет, создается динамически. Приложения обслуживают статические ресурсы (изображения, JavaScript, CSS, файлы локализации и т. д.) и динамическое содержимое.

    • Рабочие нагрузки с часто используемым статическим содержимым значительно выигрывают от кэширования, так как это снижает нагрузку на серверные службы и сокращает задержку доступа к содержимому для конечных пользователей.
  • Кэширование можно реализовать в Azure в собственном коде с помощью Azure Front Door или сети доставки содержимого Azure (CDN).

    • Azure Front Door предоставляет собственные возможности кэширования пограничных вычислений Azure и функции маршрутизации для разделения статического и динамического содержимого.
      • Создавая соответствующие правила маршрутизации в Azure Front Door, /static/* трафик можно прозрачно перенаправлять на статическое содержимое.
    • Более сложные сценарии кэширования можно реализовать с помощью службы Azure CDN для создания полноценной сети доставки содержимого для значительных объемов статического содержимого.
      • Служба Azure CDN, скорее всего, будет более экономичной, но не обеспечивает те же расширенные возможности маршрутизации и Брандмауэр веб-приложений (WAF), которые рекомендуются для других областей проектирования приложений. Однако она обеспечивает дополнительную гибкость для интеграции с аналогичными службами из сторонних решений, таких как Akamai и Verizon.
    • При сравнении служб Azure Front Door и Azure CDN необходимо изучить следующие факторы принятия решений:
      • Можно выполнить необходимые правила кэширования с помощью обработчика правил.
      • Размер сохраненного содержимого и связанных с ними затрат.
      • Цена за месяц для выполнения обработчика правил (плата взимается за запрос в Azure Front Door).
      • Требования к исходящему трафику (цена отличается по назначению).

Рекомендации по проектированию

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

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

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

  • Учитывая строжную рекомендацию (область проектирования сети и подключения) для использования Azure Front Door для глобальной маршрутизации и Брандмауэр веб-приложений (WAF), рекомендуется приоритизировать использование возможностей кэширования Azure Front Door, если не существует пробелов.

Пример: подход на основе событий

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

Mission-Critical event driven architecture

Шаблоны устойчивости на уровне приложения и обработка ошибок

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

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

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

Такие средства, как приложение Azure Аналитика, помогают значительно запрашивать, сопоставлять и визуализировать трассировки приложений.

Рекомендации по проектированию

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

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

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

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

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

Модель Сводка
Выравнивание нагрузки на основе очередей Представляет буфер между потребителями и запрошенными ресурсами, чтобы обеспечить согласованные уровни нагрузки. Так как запросы потребителей помещены в очередь, рабочий процесс отменяет запросы и обрабатывает их в соответствии с запрошенным ресурсом в темпе, заданном рабочей ролью, и способность запрашиваемого ресурса обрабатывать запросы. Если потребители ожидают ответы на свои запросы, необходимо также реализовать отдельный механизм ответа.
Автоматическое выключение Обеспечивает стабильность, ожидая восстановления или быстро отклоняя запросы, а не блокируя при ожидании недоступной удаленной службы или ресурса. Кроме того, обрабатывает ошибки, которые могут занять переменное время для восстановления при подключении к удаленной службе или ресурсу.
Распределительный блок Стремится разделить экземпляры службы на группы на основе требований к нагрузке и доступности, изолируя сбои для поддержания функциональности службы.
Saga Управляйте согласованностью данных в микрослужбах с независимыми хранилищами данных, гарантируя, что службы обновляют друг друга через определенные каналы событий или сообщений. Каждая служба выполняет локальные транзакции для обновления собственного состояния и публикует событие для активации следующей локальной транзакции в саге. Если обновление службы завершается сбоем, сага выполняет компенсирующие транзакции для противодействия предыдущим шагам обновления службы. Отдельные шаги обновления службы могут сами реализовать шаблоны устойчивости, такие как повторная попытка.
Мониторинг конечных точек работоспособности Внедрение в приложение функциональных проверок, к которым внешние средства могут регулярно получать доступ через предоставленные конечные точки.
Повторные попытки Обрабатывает временные сбои элегантно и прозрачно.
Регулирование Управляет потреблением ресурсов, используемых компонентами приложения, что позволяет защитить их от переполнения. Когда ресурс достигает порогового значения нагрузки, он должен защитить его доступность, отложив операции с более низкой важностью и снижая неисключающую функциональность, чтобы основные функциональные возможности могли продолжаться до тех пор, пока не будут доступны достаточные ресурсы для возврата к нормальной работе.

Рекомендации по проектированию

  • Разработка и разработка кода приложения для прогнозирования и обработки сбоев.

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

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

  • Реализуйте шаблоны устойчивости с помощью проверенных стандартных пакетов, таких как Polly для C# или Sentinel для Java.

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

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

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

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

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

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

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

Ознакомьтесь с рекомендациями по платформе приложений.