Машина состояний: closed, open, half-open

«Быстро отказывай, когда зависимость больна» звучит просто, пока не задашь два трудных вопроса: когда именно он начинает отклонять вызовы и как он вообще снова начинает доверять зависимости? Отклоняй слишком рьяно — и один сбой блокирует здоровый сервис; доверяй слишком рьяно — и ты долбишь ещё сломанный сервис в момент, когда остывание закончилось, опрокидывая его обратно. Брейкер отвечает на оба маленькой точной машиной состояний — три состояния и один таймер — и почти каждый продакшен-брейкер, от Netflix Hystrix до resilience4j, есть вариация на эту тему. Сделай состояния и переходы правильно — и остальное это тюнинг.

Три состояния, четыре перехода

Circuit breaker — это конечный автомат, обёртывающий каждый вызов к зависимости:

• Closed — нормальное состояние. Вызовы проходят насквозь, и брейкер считает отказы. Когда отказы пересекают условие срабатывания, он переходит в open и запускает таймер остывания.
• Open — сработавшее состояние. Каждый вызов отклоняется мгновенно (исключение или фолбэк), вообще не трогая зависимость. Это быстрый отказ из прошлого урока. Когда таймер остывания истекает, он переходит в half-open.
• Half-open — пробующее состояние. Ограниченное число пробных вызовов пускается насквозь проверить, восстановилась ли зависимость. Если они успешны, брейкер возвращается в closed и сбрасывает счётчики. Если хоть один падает, он идёт прямо обратно в open и перезапускает остывание.

Вот и вся машина: closed → open при слишком многих отказах, open → half-open по таймеру, half-open → closed при успехе, half-open → open при отказе. Переходы важны не меньше состояний, потому что каждый из них — решение, сколько нагрузки слать зависимости в неопределённом состоянии.

Таймер остывания — это циферблат восстановления

Самая значимая настройка — как долго брейкер остаётся в open до пробы — Hystrix зовёт её sleepWindowInMilliseconds (по умолчанию 5 с), resilience4j зовёт её waitDurationInOpenState (по умолчанию 60 с). Это прямой компромисс:

• Слишком коротко. Брейкер пробует почти сразу, до того как зависимость успела восстановиться, поэтому проба падает и он снова размыкается. Хуже того, если он перекидывается open → half-open слишком быстро, он может осциллировать (флапать) между состояниями, посылая всплески обречённых вызовов.
• Слишком долго. Зависимость восстановилась секунды назад, но брейкер продолжает отклонять всех, превращая короткий сбой даунстрима в долгий самонанесённый отказ.

Универсального правильного ответа нет; он отслеживает, сколько зависимость обычно восстанавливается. Брейкер перед сервисом, который перезапускается за ~10 с, хочет остывание около этого, не 60 с и не 1 с.

Зачем существует half-open

Состояние half-open — это умная часть. Без него у тебя было бы лишь два варианта, когда таймер срабатывает: остаться closed-или-open наугад, или распахнуть ворота полностью и послать весь трафик разом. Второй опасен — сервис, который только вернулся, хрупок, и внезапный потоп всего бэклога может его затаймаутить и опрокинуть прямо обратно. Это громовое стадо на оживающем сервисе.

Half-open решает это, посылая только струйку — permittedNumberOfCallsInHalfOpenState у resilience4j по умолчанию 10 — и завязывая решение на них. Оживающий сервис доказывает себя на горстке вызовов, прежде чем брейкер распахнётся полностью. Одна тонкость: по умолчанию resilience4j не двигает open → half-open по одному таймеру (automaticTransitionFromOpenToHalfOpenEnabled = false); он ждёт прихода следующего вызова после остывания, чтобы простаивающий брейкер не пробовал зависимость, которой никто не пользуется.