Graceful shutdown: выключаемся вежливо

Сигнал без обработчика в Go действует жёстко: процесс завершается немедленно, defer не выполняется, соединения закрываются ОС-ом посреди ответов. Первая половина решения — перестать пользоваться обёрткой http.ListenAndServe: она удобна, но не даёт доступа к самому серверу, а выключать нужно именно его. Вместо неё собирается объект http.Server с Addr и Handler — chi-роутер здесь обычный http.Handler — и запускается в горутине. Вторая половина — перехват сигналов: signal.NotifyContext(context.Background(), os.Interrupt, syscall.SIGTERM) возвращает контекст, чей Done закрывается по Ctrl+C (SIGINT) или kill (SIGTERM). main засыпает на <-stop.Done(), просыпается по сигналу и вызывает srv.Shutdown(ctx). С этого момента и до возврата Shutdown процесс обязан жить: документация net/http прямо предупреждает, что ListenAndServe сразу вернёт ErrServerClosed, а программа не должна завершаться, не дождавшись Shutdown. Это и есть graceful shutdown в go — не библиотека, а протокол из четырёх шагов в main.

Shutdown описан в документации net/http как трёхшаговая процедура, и знание шагов отвечает сразу на несколько «а что если». Шаг первый: закрываются все открытые listeners — порт перестаёт слушаться, новые соединения получают отказ на уровне ОС. Шаг второй: закрываются idle-соединения — те, что держат keep-alive, но не обрабатывают запрос. Шаг третий: Shutdown ждёт, пока активные соединения — хендлеры в работе — вернутся в idle, и только потом завершается. Ждёт он ровно до истечения переданного контекста: таймаут пять-тридцать секунд задаётся context.WithTimeout, и defer cancel() рядом обязателен. Если контекст истёк раньше, Shutdown возвращает ctx.Err() — context.DeadlineExceeded — но активные соединения сам не рвёт: это делает либо srv.Close(), либо завершение main. Отдельная оговорка доков: hijacked-соединения — websockets, long-poll — Shutdown не ждёт вообще, их закрывает ваш код. И главное: graceful касается только HTTP — фоновые горутины он не видит, о них следующий блок.

Shutdown закрывает только HTTP-слой, а у сервиса есть и другие ресурсы: пул соединений с БД, воркеры, очереди, файловые буферы. Порядок здесь диктуется зависимостями: пока Shutdown не вернулся, хендлеры ещё пишут в базу — закрывать пул до этого значит превратить последние легитимные запросы в 500, то есть воспроизвести проблему, ради которой всё затевалось. Рабочая последовательность: сигнал → srv.Shutdown(ctx) → остановка воркеров → db.Close(). Воркеры — горутины, которые Shutdown не ждёт: они не связаны с соединениями, и сервер о них не знает. Их останавливает main: канал задач закрывается, WaitGroup дожидается хвостов, и только после этого освобождается БД. Контекст приложения из NotifyContext удобен как общий выключатель: воркеры следят за ctx.Done() в select — тот же приём, что и в отмене контекста из урока продвинутого курса. Для библиотек, которым нужен хук в момент выключения, у http.Server есть RegisterOnShutdown — функция вызывается при старте Shutdown.

Не всякий сигнал — повод умирать. SIGHUP исторически означал «терминал отвалился», но демоны давно переосмыслили его как «перечитай конфиг»: nginx по SIGHUP перечитывает настройки, не разрывая соединений. В Go без обработчика SIGHUP завершает процесс — если сервис живёт под systemd или в контейнере, решите заранее, что делает ваш SIGHUP: то же выключение, перечитывание конфига или ничего. С сигнальной перезагрузкой соседствует файловая: viper из курса по конфигам умеет WatchConfig и OnConfigChange — вотчер следит за файлом настроек и перечитывает его без участия сигналов. Граница простая: сигнал — внешний ручной триггер, файловый вотчер — автоматика на изменение; оба не требуют рестарта процесса, и graceful shutdown остаётся для настоящих перезапусков — смены бинарника, а не настроек. Если конфиг меняется горячо, проверьте, что зависимости — пул, лимиты, таймауты — тоже перечитываются, а не считываются один раз в main при старте.

В поиске гуляет запрос «chi graceful», и стоит разложить, что тут чьё: chi — только Handler, вся механика выключения живёт в net/http. Роутеру нечего останавливать — он просто перестаёт получать запросы, когда Shutdown закрыл listener. Настоящая связка chi с выключением — в дедлайнах: middleware.Timeout из урока про таймауты кладёт лимит в контекст каждого запроса, и хендлеры, следящие за r.Context().Done(), завершаются сами — без них один зависший long-poll растянет Shutdown на весь таймаут. Websockets и SSE chi не закрывает — hijacked-соединения Shutdown не ждёт: держите реестр активных подключений и закрывайте его в своей последовательности. Ещё одна деталь деплоя за балансировщиком: сначала снять под с балансировки — readiness-проба перестаёт отвечать, — затем слать сигнал, чтобы «новые запросы не принимались» совпало с реальностью. Порядок из прошлого урока — единый формат ошибок — пригодится и здесь: отказ в период выключения тоже должен быть JSON-ом, а не обрывом.