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

Стратегии обработки частичного сбоя

Подсказка

Это фрагмент из электронной книги «Архитектура микрослужб .NET для контейнеризованных приложений .NET», доступной в документации .NET или в виде бесплатного скачиваемого PDF-файла, который можно прочитать в автономном режиме.

Скачать в формате PDF

Архитектура микросервисов .NET для приложений .NET в контейнерах, миниатюра обложки электронной книги.

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

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

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

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

Используйте паттерн Circuit Breaker. В этом подходе клиентский процесс отслеживает количество неудачных запросов. Если частота ошибок превышает настроенное ограничение, то «автоматический выключатель» срабатывает, чтобы дальнейшие попытки сразу прекращались. (Если не удается выполнить большое количество запросов, это означает, что служба недоступна, и что отправка запросов бессмысленна.) После истечения времени ожидания клиент должен повторить попытку, и если новые запросы окажутся успешными, следует замкнуть автоматический переключатель.

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

Ограничение количества очередных запросов. Клиенты также должны наложить верхнюю границу на количество невыполненных запросов, которые микрослужба клиента может отправлять в определенную службу. Если лимит достигнут, то, вероятно, бессмысленно делать дополнительные запросы, и такие попытки должны сразу завершаться неудачей. С точки зрения реализации политика изоляции Bulkhead может использоваться для выполнения этого требования. Этот подход, по сути, является ограничителем параллелизации с SemaphoreSlim в качестве реализации. Он также разрешает очередь за пределами переборки. Вы можете заранее сбросить избыточную нагрузку ещё до начала выполнения (например, если ёмкость считается полной). Это делает ответ системы на определенные сценарии сбоев более быстрым, чем автоматический выключатель, поскольку автоматический выключатель ожидает появления сбоев. Объект BulkheadPolicy в Polly показывает, насколько заполнены переборка и очередь, и предлагает события на случай переполнения, и может использоваться для автоматического горизонтального масштабирования.

Дополнительные ресурсы

НазадДалее