Архитектура бэкенда
Graceful shutdown: тест с выбором ответа
Шесть вопросов поперёк всего юнита. Каждый отражает решение, которое ты принимаешь во время реального деплоя — не определение для заучивания, а порядок или disposition, которые нужно сделать правильно до того, как истечёт grace period.
Убедись, что связываешь контракт сигналов, гонку deregistration, порядок drain, безопасность requeue и координацию флота — тот синтез, к которому вели отдельные уроки.
Команда выкатывает корректный 45-секундный SIGTERM-обработчик drain, но запросы всё равно обрываются на каждом деплое. Dockerfile запускает приложение через sh -c 'node server.js'. В чём корневая причина?
Сервис с безупречным SIGTERM-обработчиком, который закрывает листенер в тот же миг, как приходит сигнал, всё равно даёт короткий всплеск connection-refused в самом начале каждого rollout. Почему и как чинить?
Обработчик shutdown закрывает HTTP-сервер и пул БД в одном шаге. Большинство деплоев чистые, но иногда несколько запросов падают посреди drain с ошибками pool-closed. Какой принцип нарушен?
Воркер очереди четыре минуты внутри задачи, когда приходит SIGTERM, а grace period 30s. Какая правильная disposition и что делает её безопасной?
Во время shutdown сервис начинает проваливать и readiness, и liveness probe, чтобы «выключиться быстрее». Drain'ы начинают обрезаться. Что пошло не так?
Каждый shutdown отдельного инстанса безупречен, но rolling-деплои под нагрузкой всё равно сбрасывают тонкий слой 502, и иногда выжившие поды падают. Какая пара fleet-уровневых исправлений это решает?
Сквозная линия юнита — одна упорядоченная дисциплина. Сначала контракт сигналов — SIGTERM должен реально дойти до зарегистрированного обработчика в PID 1, иначе SIGKILL завершит всё на дедлайне grace period. Затем гонка deregistration: провали readiness и выжди propagation до того, как перестанешь принимать, чтобы не отказывать трафику, который балансировщик ещё маршрутизирует. Затем drain в reverse dependency order — HTTP первым, datastores последними — чтобы ни один in-flight запрос не потерял ресурс, который ему ещё нужен, и всё это под guardian timeout. Работа, не влезающая в бюджет дедлайна, отклоняется (длинные запросы) или ставится в requeue (задачи), и requeue безопасен только при идемпотентном consumer. Наконец, подними это до флота: surge перед drain, deregister перед terminate и jitter синхронных closes — потому что локальная корректность не складывается в глобальную бесплатно.