Не все бэкенд-сервисы разворачиваются одинаково

Команда готовится к выкату новой функциональности. Обновление API-сервиса проходит гладко — несколько секунд rolling replacement, zero downtime. Затем наступает очередь воркера. Кто-то нажимает «деплой», и внезапно все поставленные в очередь задачи по обработке изображений исчезают. Команда смотрит в логи в замешательстве: «С API же сработало. Почему сломался воркер?»

Этот сценарий повторяется в инженерных командах каждую неделю. Коренная причина почти никогда не кроется в баге инструмента деплоя. Это непонимание того, с каким типом бэкенд-сервиса они имеют дело.

Бэкенд-сервисы выглядят похоже. Все они запускаются на серверах, у всех есть код, всем нужны обновления. Но то, как они получают работу, как хранят состояние и как обрабатывают прерывания, принципиально различается. Пайплайн CI/CD, который отлично работает для одного типа, может молча уничтожить данные для другого.

API-сервисы: всегда слушают, всегда доступны

Самый знакомый тип бэкенда — API-сервис. Он слушает порт, ждет входящих запросов от мобильных приложений, веб-сайтов или других сервисов и возвращает ответ. Пользователи сразу чувствуют, когда API-сервис падает — приложение перестает загружаться, страница показывает ошибку, транзакция срывается.

Следующая блок-схема классифицирует бэкенд-сервисы по способу получения работы и сопоставляет каждый тип с рекомендуемой стратегией деплоя.

API-сервисы должны быть всегда готовы. Они обязаны обрабатывать всплески трафика, масштабируя инстансы вверх и вниз. Они должны принимать новые соединения, пока старые еще обрабатываются. И, что критично, их нужно обновлять без потери выполняющихся запросов.

Для CI/CD это означает, что стратегия деплоя имеет значение. Простой деплой с остановкой и запуском оборвет активных пользователей. Rolling updates, blue-green деплой или canary релизы становятся необходимостью. Пайплайн должен проверять, что новые инстансы проходят health checks, прежде чем старые будут удалены.

Воркеры: обрабатывают задачи, а не запросы

Воркеры не общаются напрямую с пользователями. Они забирают задачи из очереди, обрабатывают их одну за другой и сохраняют результаты. Изменение размера изображений, отправка писем, генерация отчетов — это работа воркеров. Пользователь загружает фото и получает ответ мгновенно, но изменение размера происходит за кулисами.

Поскольку воркеры не обслуживают живые запросы, их можно обновлять более аккуратно. Ключевая задача — не потерять активные задачи. Хороший пайплайн для воркера ждет завершения текущей задачи перед остановкой старого процесса. Если система очередей это поддерживает, воркер может сообщить об остановке, завершить текущую задачу и выйти. Новые инстансы запускаются, забирают следующие задачи из очереди, и система продолжает работу без потерь.

Ошибка, которую совершают команды, — это отношение к воркерам как к API-сервисам. Они убивают процесс немедленно во время деплоя, и все выполняющиеся задачи теряются. Очередь не знает, что задача провалилась на полпути — она просто не видит сигнала о завершении. Задача исчезает в черной дыре.

Kubernetes Deployment предполагает бесконечную работу и использует readiness probes для управления трафиком. Job, напротив, выполняется до завершения и использует restartPolicy: Never:

# API-сервис - работает постоянно, нужен readiness probe
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-service
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
      - name: api
        image: myapp/api:latest
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
---
# Воркер - выполняет одну задачу, затем завершается
apiVersion: batch/v1
kind: Job
metadata:
  name: image-resize-job
spec:
  template:
    spec:
      restartPolicy: Never
      containers:
      - name: worker
        image: myapp/worker:latest
        command: ["process-queue"]

Планировщики: время решает всё

Планировщики запускают задачи по расписанию. Очистить старые данные в полночь. Синхронизироваться с внешней системой каждый час. Сгенерировать ежедневные отчеты в 6 утра.

Проблема планировщиков — избежать дублирования выполнения. Если планировщик запускает задачу очистки, а деплой перезапускает планировщик прямо в момент старта задачи, есть риск, что новый инстанс также запустит ту же задачу. Теперь очистка выполняется дважды, что может вызвать конфликты или проблемы с данными.

Хороший пайплайн для планировщика гарантирует, что новый инстанс не запустится, пока старый все еще выполняет запланированную задачу. Также нужен механизм для обнаружения и пропуска пересекающихся запусков. Некоторые команды используют распределенные блокировки или маркеры в базе данных для предотвращения двойного выполнения.

Потребители: успевать за потоком

Потребители похожи на воркеров, но обрабатывают непрерывный поток данных. Они читают из брокеров сообщений, таких как Kafka или RabbitMQ, обрабатывают сообщения в реальном времени и часто должны сохранять свою позицию в потоке.

Ключевое отличие — скорость и отслеживание offset. Если потребитель отстает, ему нужно догнать, не перегружая систему. Если потребитель падает, он должен возобновить работу с того места, где остановился, а не с начала.

Для CI/CD это означает, что деплой должен аккуратно обрабатывать фиксацию offset. Остановка потребителя без фиксации текущего offset может привести к повторной обработке уже обработанных сообщений. Перезапуск с неправильного offset может пропустить сообщения или обработать их дважды. Пайплайн должен координироваться с брокером сообщений для обеспечения graceful shutdown и возобновления.

Внутренние сервисы: скрытые зависимости

Внутренние сервисы не доступны фронтенд-приложениям. Они обслуживают другие сервисы внутри системы — аутентификацию, конфигурацию, логирование, feature flags. Множество сервисов зависят от них, часто синхронно.

Опасность внутренних сервисов — каскадные сбои. Небольшое изменение в сервисе аутентификации может сломать каждый сервис, который его вызывает. Медленный ответ от сервиса конфигурации может вызвать таймауты во всей системе.

Эти сервисы требуют более строгого тестирования и более осторожного деплоя. Пайплайн должен запускать интеграционные тесты, которые симулируют реальное поведение вызывающих сервисов. Деплой должен быть постепенным, с мониторингом зависимых сервисов. Откат должен быть быстрым и надежным, потому что радиус поражения велик.

Практический чек-лист для пайплайнов бэкенд-сервисов

Прежде чем проектировать пайплайн для любого бэкенд-сервиса, задайте эти вопросы:

• Как этот сервис получает работу? (запрос, очередь, расписание, поток)
• Можно ли его безопасно остановить на середине задачи? Если да, что происходит с задачей?
• Хранит ли он какое-либо состояние в памяти, которое нельзя восстановить?
• Что произойдет, если два инстанса выполнят одну и ту же задачу одновременно?
• Какие другие сервисы сломаются, если этот сервис упадет?
• Как долго этот сервис может быть недоступен, прежде чем пользователи или системы заметят?

Ответы подскажут, нужны ли вам rolling updates, graceful shutdown hooks, координация очередей или упорядочивание деплоя с учетом зависимостей.

Вывод

Пайплайн CI/CD — это не универсальный скрипт. Это отражение того, как на самом деле работает ваш сервис. API-сервисам нужна осведомленность о соединениях. Воркерам — гарантии завершения задач. Планировщикам — предотвращение пересечения. Потребителям — управление offset. Внутренним сервисам — координация зависимостей.

Когда вы понимаете, с каким типом бэкенд-сервиса имеете дело, вы перестаете копировать шаблоны пайплайнов из блогов и начинаете строить пайплайны, которые защищают ваши данные, ваших пользователей и сон вашей команды.