Конкурентный сервис ингеста на Go

До любого кода оцени работу. Реши целевую частоту интейка (скажем, 2000 req/s), фан-аут на запрос (каждый интейк порождает N вызовов downstream) и собственную ёмкость downstream'а — их произведение и есть твой бюджет конкурентности, и он конечен. Выпиши SLO (например, p99 приёма < 20 мс, сквозной p99 < 500 мс, нулевой неограниченный рост горутин) и явные non-goals. Ключевое решение: Go-сервис, порождающий по горутине на единицу входящей работы, не имеет верхней границы, поэтому уже сейчас зафиксируй ограниченный пул, размер которого подобран под то, что downstream'ы реально могут поглотить, а не под то, что клиенты могут прислать.

Реализуй handler интейка и фиксированный пул воркеров, питаемый буферизованным каналом. Handler валидирует и кладёт в очередь; фиксированный набор горутин-воркеров (размером с твой бюджет конкурентности, а не случайно с GOMAXPROCS) разгребает канал и делает фан-аут. Каждая горутина принимает context, а рабочий элемент несёт свой дедлайн. Суть — в структуре: одно место порождает воркеров, один канал они читают, так что число горутин — это выбранная тобой константа, а не эмерджентное свойство трафика.

Реши, что происходит при заполненной очереди. Неправильный ответ — неограниченный канал, который глотает всё, пока не умрёт память; правильный — ограниченная очередь плюс семафор, где полная очередь означает, что handler интейка быстро возвращает 503 + Retry-After, а не блокируется. Сделай границу явной, а сброс — наблюдаемым. Backpressure — это разница между сервисом, который под перегрузкой деградирует плавно, и тем, который наращивает многосекундный хвост латентности и затем ловит OOM: буферизация — не стратегия ёмкости, она лишь прячет момент, когда ты исчерпал ресурс.

Оберни каждый вызов downstream так, чтобы одна медленная или падающая зависимость не приколола весь пул. Дай каждому вызову пер-попыточный таймаут, выведенный из дедлайна элемента, ретрай только идемпотентных отказов с ограниченным экспоненциальным backoff + jitter, и прекращай ретраи в момент отмены родительского context. Ловушка, которой надо избегать: наивные ретраи усиливают частичный сбой до полного — если твой downstream на 50% ошибок, а каждый клиент ретраит 3×, ты утроил нагрузку на то, что уже падает. Используй errgroup или структурный фан-аут, чтобы упавший сосед отменял остальных, а дедлайн был жёстким потолком, а не пожеланием.

Сделай работающий сервис читаемым снаружи. Снимай структурные логи (log/slog) с request/trace id, который можно скоррелировать через фан-аут, выставь net/http/pprof на приватный порт для живых профилей горутин, кучи и CPU, и публикуй метрики: rate интейка, долю сброса (503), глубину очереди, утилизацию воркеров, error/latency downstream и — ту, что ловит утечку, — живое число горутин. Именно это делает этап инцидента диагностируемым, а не игрой в угадайку; плоская линия горутин на дашборде — твоё раннее предупреждение, что утечка, которую ты позже вызовешь, происходит.

Сделай завершение осознанным. На SIGTERM прекрати принимать новый интейк (server.Shutdown), затем закрой очередь и дай воркерам доделать элементы в полёте в пределах дедлайна слива, отменяя то, что не уложилось. Отказ, которого надо избегать, — это shutdown с потерей работы: процесс выходит в момент SIGTERM от оркестратора, бросая всё в очереди и в полёте. Корректный слив упорядочен — останови интейк, сигнализируй воркерам, подожди с ограниченным таймаутом, форс-отмени отстающих — и именно это делает выкатку или scale-down незаметным событием, а не всплеском потерянных запросов.

Выкати как минимальный безопасный образ и задеплой с lifecycle-хуками, которые делают предыдущий этап осмысленным. Собери статический бинарь, положи в distroless или scratch базу (единицы МБ, без шелла, non-root, без зашитых секретов) и подключи health деплоя: liveness-проба, ловящая задедлоченный процесс, и readiness-проба, не пускающая трафик, пока пул не поднялся. Сделай terminationGracePeriod оркестратора длиннее твоего дедлайна слива, чтобы SIGTERM → слив → выход успевал до SIGKILL — иначе твой graceful shutdown декоративен.

Вызови реальную утечку: вызов downstream, где горутина шлёт в небуферизованный канал, чей получатель сдался по таймауту, так что каждый отменённый запрос навсегда оставляет одну горутину висеть. Под нагрузкой линия живых горутин ползёт вверх, куча растёт вместе с ней, GC работает тяжелее, и в итоге сервис ловит OOM или дедлок. Обнаружь это по своей метрике горутин, сними pprof-профиль горутин, чтобы найти тысячи, припаркованных на одной отправке в канал, почини (дай отправителю выход — select по ctx.Done() или буферизованный слот) и подтверди, что линия выровнялась. Затем напиши пост-мортем: более длинный интервал GC или больший лимит памяти лишь покупают время; корневая причина — горутина без выхода при отмене.