Прерыватель цепи

Единственная задача прерывателя в состоянии closed — считать последовательные сбои и срабатывать, когда они превышают порог. Ключевая тонкость — «последовательные»: успех сбрасывает счётчик в ноль, так что один удачный вызов поглощает соседние сбои. Порог (скажем, 5) — это параметр настройки: слишком низкий — и транзиентный сбой без нужды открывает цепь; слишком высокий — и реально сломанная зависимость получает N повторов до отсечения потока. На этом этапе реализуй именно это: счётчик, инкрементирующийся при каждом сбое, сбрасывающийся при успехе и переводящий в 'open' по достижении порога. Короткого замыкания пока нет — это следующий этап. Сначала сделай правильный скелет конечного автомата: состояния 'closed', 'open', 'half-open'; на этом этапе только 'closed' принимает вызовы. Сделай порог и длительность open конфигурируемыми, а часы инжектируй параметром каждого вызова, а не захватывай при конструировании — именно это делает всю систему юнит-тестируемой без мокирования Date.now().

Как только цепь открыта, каждый вызов должен провалиться быстро, не касаясь зависимости — весь смысл паттерна в том, чтобы перестать усиливать нагрузку на то, что уже сломано. Прерыватель бросает исключение немедленно, и — что критично — вообще не вызывает обёрнутую функцию: открытая цепь — это обещание, что зависимость получит ноль запросов в окне восстановления. Это важно, потому что каждый вызов в адрес борющегося сервиса добавляет латентность, занимает поток или соединение и потенциально замедляет восстановление. Измерь короткое замыкание, верифицировав, что счётчик вызовов обёрнутой функции остаётся нулём, пока прерыватель открыт. Брошенная ошибка должна быть отличима от ошибок самой обёрнутой функции, чтобы вызывающая сторона могла решить — деградировать изящно или пробросить: универсального Error недостаточно; типизированный CircuitOpenError (или флаг на ошибке) даёт вызывающей стороне этот выбор. Окно восстановления (openMs) стартует с момента срабатывания, а не с момента последнего вызова.

Окно восстановления истекло, и ты не прыгаешь сразу обратно в closed — ты прощупываешь. Цепь в состоянии half-open пропускает ровно один вызов к зависимости: если он успешен, прерыватель сбрасывается в closed; если нет — снова открывается с таймером, сброшенным к now. Ограничение «ровно один» критично для нагрузки: если ты пропускаешь пачку вызовов в момент истечения окна, ты рискуешь снова сломать сервис, который только начал восстанавливаться. halfOpenMax контролирует, сколько параллельных зондов разрешено (обычно 1). Переход состояния по результату зонда должен быть атомарным с точки зрения вызывающей стороны: успешный зонд должен сбросить счётчик сбоев и перевести состояние в closed за один логический шаг, а не двумя отдельными записями. Правильно реализуй проверку времени: переход из open в half-open не событийный (никакой таймер не срабатывает) — он проверяется лениво при следующем вызове. state(now) возвращает 'half-open', когда now >= openedAt + openMs, а путь вызова проверяет state(now) перед принятием решения.

На данный момент у тебя три состояния и четыре перехода: closed→open (порог превышен), open→half-open (окно истекло, лениво), half-open→closed (зонд успешен), half-open→open (зонд неудачен). Проведи аудит машины на баги повторного входа: что происходит, если два вызывающих одновременно попадают в окно half-open? Первый зонд-вызов должен владеть переходом; второй не должен тоже зондировать — если halfOpenMax равен 1, второй вызов, пока зонд в полёте, должен либо делать короткое замыкание (считая in-flight как ещё открытое), либо ждать, в зависимости от дизайна. Сделай этот выбор явным и протестированным. Также проведи аудит пути сброса: после успеха зонда и перехода в closed следующие N сбоев должны снова срабатывать прерыватель с нуля — убедись, что счётчик сбоев был действительно сброшен, а не просто замаскирован. Нарисуй полный конечный автомат (в виде комментария в коде — нормально), назвав каждый переход и его защиту, чтобы будущий сопровождающий не реконструировал это из кода.

Счётчик последовательных сбоев имеет острый изъян: один успех посреди серии сбоев сбрасывает счётчик в ноль, поэтому зависимость, падающая в 80% случаев, может никогда не сработать прерыватель, если 20% успехов распределены. Скользящее окно считает сбои и общие вызовы за последние N секунд (кольцевой буфер или колесо вёдер), срабатывает при частоте сбоев >= порог% и гораздо точнее отражает реальное здоровье зависимости. Компромисс — память: окно 60 секунд с бакетами по 1 мс — это 60 000 счётчиков на экземпляр прерывателя; большинство реализаций используют 10–60 более грубых бакетов (каждый охватывает одну секунду). Реализуй скользящее окно как замену счётчика последовательных сбоев. Ключево: истечение бакета основано на времени: бакет 61-секундной давности просрочен и его сбои не считаются, но нельзя полагаться на фоновую зачистку — истекай лениво при поступлении нового вызова. Протестируй граничный случай: сбои, попадающие ровно на границу бакета (при возрасте окна == windowMs), не должны считаться.

Прерыватель цепи, срабатывающий молча, — это простой без сигнала. Отправляй счётчики для: всех вызовов, сбоев, коротких замыканий (вызовов, отклонённых в open), успешных зондов, неудачных зондов и переходов состояний. Это числа, которые говорят, правильно ли настроен прерыватель: если число коротких замыканий нулевое, а сбои растут — порог слишком высок; если коротких замыканий огромное количество, а зависимость здорова — окно слишком длинное. Счётчики дешевы (только инкремент), поэтому отправляй их на каждом пути вызова. Для вызывающих ошибка circuit-open — возможность изящной деградации: вернуть кэшированный результат, значение по умолчанию или 503 с Retry-After, выведенным из openedAt + openMs - now. Спроектируй интерфейс Fallback, который прерыватель принимает опционально и вызывает, когда цепь открыта. Протестируй, что фолбэк срабатывает при открытой цепи и не срабатывает при закрытой — прерыватель не должен поглощать результат фолбэка как успех и непреднамеренно сбрасывать счётчик сбоев.