Стратегии обработки частичного сбоя
Совет
Это содержимое является фрагментом из электронной книги, архитектуры микрослужб .NET для контейнерных приложений .NET, доступных в документации .NET или в виде бесплатного скачиваемого PDF-файла, который можно читать в автономном режиме.
Чтобы устранить частичные сбои, используйте одну из описанных здесь стратегий.
Использование асинхронного взаимодействия (например, взаимодействия на основе сообщений) между внутренними микрослужбами. Настоятельно рекомендуется не создавать длинные цепочки синхронных HTTP-вызовов между внутренними микрослужбами, так как этот подход в конечном счете приведет к сбоям. Напротив, асинхронный (на основе сообщений) обмен данными следует использовать только после выполнения начального цикла "запрос — ответ" между внутренними микрослужбами. Исключение составляет интерфейсное взаимодействие между клиентскими приложениями и первым уровнем микрослужб или детально настроенными шлюзами API. Итоговая согласованность и управляемые событиями архитектуры помогут свести к минимуму волновой эффект. Эти подходы обеспечивают более высокий уровень автономности микрослужбы и, таким образом, позволяют избежать возникновения указанной здесь проблемы.
Использование повторных попыток с экспоненциальной выдержкой. Этот метод помогает не допускать короткие и временные сбои, выполняя многократные повторные попытки вызова в случае, если служба была недоступна в течение небольшого промежутка времени. Такая проблема может возникать из-за периодических неполадок сети или при перемещении микрослужбы или контейнера на другой узел в кластере. Однако, если эти повторные попытки неправильно настроены с размыкателями цепи, волновой эффект может усилиться, что в конечном итоге не исключает даже отказ в обслуживании (DoS).
Обход времени ожидания сети. Как правило, клиенты должны разрабатываться так, чтобы не переходить в состояние блокировки на неопределенное время и всегда использовать таймауты при ожидании ответа. Время ожидания исключает постоянную занятость ресурсов.
Использование шаблона размыкателя цепи. В этом случае клиентский процесс отслеживает количество неудачных запросов. Если частота ошибок превышает установленный предел, размыкатель цепи отключается, поэтому дальнейшие попытки немедленно завершаются сбоем. (Если не удается выполнить большое количество запросов, это означает, что служба недоступна и что отправка запросов не является бессмысленной.) После истечения времени ожидания клиент должен повторить попытку и, если новые запросы успешны, закройте выключатель.
Предоставление резервных механизмов. При использовании этого подхода клиентский процесс в случае сбоя запроса реализует резервную логику, например возвращает кэшированные данные или значение по умолчанию. Этот вариант подходит для запросов, но несколько сложен для обновлений или команд.
Ограничение на максимальное количество запросов в очереди. Клиенты должны также устанавливать верхний предел на количество ожидающих запросов, отправляемых клиентской микрослужбой в конкретную службу. Если предел был достигнут, вероятно, нет никакого смысла выполнять дополнительные запросы, так как эти попытки сразу же завершатся ошибкой. С точки зрения реализации для выполнения этого требования можно использовать политику изоляции отсеков Polly. По сути, этот подход представляет собой регулирование распараллеливания с использованием SemaphoreSlim в качестве реализации. Он также позволяет формировать очередь вне переборки. Избыточную нагрузку можно распределить заранее — еще до выполнения (например, если считается, что достигнута полная мощность). В результате он реагирует на определенные сценарии сбоя быстрее, чем это сделал бы размыкатель цепи, поскольку размыкатель цепи ждет возникновения сбоев. Объект BulkheadPolicy в Polly отображает степень заполнения переборки и очереди и предлагает события на случай переполнения, поэтому его также можно использовать для выполнения автоматического горизонтального масштабирования.
Дополнительные ресурсы
Шаблоны устойчивости
https://learn.microsoft.com/azure/architecture/framework/resiliency/reliability-patternsПовышение устойчивости и оптимизация производительности
https://learn.microsoft.com/previous-versions/msp-n-p/jj591574(v=pandp.10)Переборка. Репозиторий GitHub. Реализация с политикой Polly.
https://github.com/App-vNext/Polly/wiki/BulkheadПроектирование устойчивых приложений для Azure
https://learn.microsoft.com/azure/architecture/framework/resiliency/app-designОбработка временных сбоев
https://learn.microsoft.com/azure/architecture/best-practices/transient-faults