Как диагностировать каскадный отказ сервисов (cascading failure) при высокой нагрузке?

Короткий ответ

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

Как это работает подробнее

Без таймаутов/circuit breaker медленная зависимость «съедает» воркеры вызывающего сервиса; когда свободных воркеров не остаётся, сервис не может обслуживать вообще никакие запросы, и отказ распространяется дальше по цепочке.

Пример кода

СхемаКопировать

Метрики при инциденте:
- payment-service p99 latency: 200ms -> 15000ms (деградация зависимости)
- order-service thread pool usage: 40% -> 100% (воркеры заняты ожиданием payment-service)
- order-service error rate (все эндпоинты): 0.1% -> 80% (каскад)

Что использовать на практике

• Практика. Диагностика начинается с метрик — рост latency и error rate на конкретной исходящей зависимости, рост использования пула соединений/потоков, затем рост ошибок на сервисе в целом; трассировка помогает увидеть, что все «зависшие» запросы ждут один и тот же downstream-вызов.

Подводные камни

• Риск. Лечить симптом (увеличивать размер пула воркеров), не устраняя причину (отсутствие таймаутов и изоляции); не разделять ресурсы (bulkhead) между вызовами к разным зависимостям.