Архитектура бэкенда
Circuit breakers: тест с выбором ответа
Суть Тест с выбором на синтез по всему юниту — fast-fail, машина из трёх состояний, пороги срабатывания, bulkheads, fallback'и и сбои на масштабе флота.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего юнита. Каждый отражает решение, которое ты принимаешь в реальном инциденте — не определение для заучивания, а компромисс, который надо взвесить, когда downstream болен, а твои потоки заполняются.
Цель
Убедись, что связываешь fast-fail, машину состояний, пороги срабатывания, bulkheads, fallback’и и сбои на масштабе флота — тот синтез, к которому вели отдельные уроки.
Викторина
Completed
Платёжный провайдер замедляется с 50 мс до 5 с, но не возвращает ошибок. За секунды весь сервис — включая маршруты, которые не трогают платежи — перестаёт отвечать. Почему медленный случай хуже полного отказа и какова роль breaker'а?
Heads-up Ничего не повреждается — вред в занятости ресурсов, каждый вызывающий пришпилен к медленному вызову. Breaker освобождает ресурсы через fast-fail; он не откатывает данные.
Heads-up Припаркованные потоки берутся из общего пула, поэтому неродственные маршруты тоже голодают. Breaker сужает blast radius, а не расширяет его.
Heads-up Медленный успех стоит всего, что стоил бы реальный успех, плюс ожидание; он пришпиливает ресурсы на весь timeout. Медленное — опасное состояние именно потому, что вызывающие продолжают ждать.
Викторина
Completed
Breaker настроен с cooldown (resilience4j waitDurationInOpenState) в 1 с перед зависимостью, которой нужно около 20 с на перезапуск после падения. Что идёт не так?
Heads-up Cooldown короче реального времени восстановления зависимости гарантирует, что проба попадёт в всё ещё сломанный сервис; breaker флапает вместо восстановления. Cooldown должен отслеживать реальное время восстановления.
Heads-up Он покидает open каждую секунду, чтобы зондировать — в этом и проблема. Он снова входит в open, потому что проба падает, а не потому, что застрял.
Heads-up Cooldown — это лишь то, как долго длится open перед half-open; короткий всё равно идёт в half-open, просто слишком рано.
Викторина
Completed
Низконагруженный admin-эндпоинт видит около 10 запросов/минуту. Один транзиентный timeout в 3 часа ночи срабатывает его breaker на весь cooldown, быстро отказывая каждому последующему запросу из-за единственного блипа. Какая настройка — правильный фикс, и почему не просто поднять failure-rate threshold?
Heads-up Более короткий cooldown лишь снижает урон ложного срабатывания; он не останавливает срабатывание на единственном вызове. Порог объёма — это то, что предотвращает срабатывание.
Heads-up Детекция медленных вызовов тут ни при чём — ложное срабатывание пришло из failure rate, посчитанного на слишком малом числе вызовов, а не из медленного вызова.
Heads-up Тип окна меняет определение «недавнего», но единственный отказ всё равно даёт 100% rate внутри любого окна. Только минимальный порог объёма защищает от срабатывания на единственном вызове.
Викторина
Completed
Три downstream'а — платежи, рекомендации, поиск — делят один пул из 50 потоков. Рекомендации (наименее важные) замедляются до 5 с, и весь сервис падает, хотя их breaker в итоге срабатывает. Что добавляет bulkhead, чего breaker сам по себе не может?
Heads-up Более быстрое окно срабатывает раньше, но пул всё равно может осушиться до его реакции; только разбиение бюджета сдерживает сбой. Bulkhead — это недостающая изоляция, а не более быстрая реакция.
Heads-up Ретраи добавляют нагрузку и так больной зависимости; они не изолируют. Bulkhead разбивает бюджет конкурентности на зависимость.
Heads-up Breaker'ы на зависимость всё равно черпают из одного общего пула потоков, поэтому медленная зависимость осушает общий бюджет до реакции её breaker'а. Изоляция требует потолка конкурентности на зависимость, и это bulkhead.
Викторина
Completed
Команда оборачивает шаткий сервис рекомендаций в breaker и выкатывает. В следующий инцидент breaker не срабатывает, а главная страница висит — вызовы рекомендаций не ошибаются, они занимают по 30 с каждый. Чего не хватает и какой второй кусок ещё нужен, когда breaker сработает?
Heads-up Порог не помогает, когда не считается ни одного отказа — зависания никогда не регистрируются как отказы без timeout. Timeout — это то, что превращает зависание в считаемый отказ.
Heads-up Больший пул откладывает голодание, но breaker всё равно не считает зависания. Timeout — это то, что заставляет зависание выглядеть как отказ.
Heads-up Ретрай 30-секундного зависания умножает урон. Breaker'у нужен timeout, чтобы ограничить и посчитать каждый вызов, плюс fallback на то, что вернуть, когда открыт.
Викторина
Completed
Сервис A зовёт B зовёт C, каждый ретраит до 4 раз при отказе, на флоте из пятидесяти инстансов. C коротко вздрагивает. Дрожь превращается в устойчивый самонаведённый сбой. Каков доминирующий механизм и какой фикс его ограничивает?
Heads-up Breaker'ы не повреждают данные, а вред тут — мультипликативная нагрузка, а не корректность. 64x retry amplification — вот механизм.
Heads-up Общее состояние покупает общий взгляд ценой сетевого вызова на горячем пути и новой зависимости; оно не адресует retry storm под breaker'ом. Storm ограничивается ограничением ретраев и держанием breaker'а над ними.
Heads-up Backoff разносит попытки одного клиента, но клиенты, упавшие вместе, ре-синхронизируются в волны; jitter — это то, что разрывает корреляцию, а breaker над ретраями — то, что ограничивает множитель.
Итог
Сквозная линия юнита — одна цепочка решений: медленная зависимость голодит общий пул, поэтому breaker быстро отказывает ей (closed считает отказы, open отвергает мгновенно, half-open зондирует), срабатывая на failure rate по скользящему окну с минимальным порогом объёма, причём медленное считается отказом. Bulkhead изолирует бюджет на зависимость, чтобы один больной downstream не осушил весь пул до срабатывания реактивного breaker’а; timeout превращает зависание в считаемый отказ, а fallback решает, что вернуть, когда открыт; на масштабе флота реальная опасность — retry amplification (4×4×4 = 64), укрощаемая держанием breaker’а над ретраями, ограничением абсолютного rate ретраев и jitter’ом и ретраев, и half-open проб. У каждого пер-инстансового защитного устройства должна быть история на уровне флота.