Когда в организации насчитываются десятки, а тем более сотни микросервисов, хаотичный подход к их выпуску в продакшен быстро превращается в источник постоянных инцидентов. Событийно-управляемая архитектура (EDA) добавляет к классическим сложностям развёртывания целый пласт специфических проблем: перестройка материализованных состояний, повторная обработка потоков, совместимость схем и влияние на нижестоящих потребителей.

В этой главе мы разберём фундаментальные принципы, архитектурные компоненты и конкретные шаблоны развёртывания, которые помогут выпускать обновления предсказуемо и безопасно.

Это шестнадцатая глава цикла. Она опирается на главу I (Team Topologies, distributed monolith), главу III (schema evolution), главу IV (Data Liberation), главу V (state stores, rebalance), главу VI (reprocessing), главу VII (state store migration), главу VIII (Saga, human-in-the-loop), главу XII (Kafka Streams), главу XIV (CI/CD, tooling) и главу XV (testing infrastructure). Здесь мы замыкаем цикл: от паттернов и качества — к безопасной доставке в production.

IПринципы развёртывания EDA

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

Два принципа про взаимодействие сервисов:

1. Минимизируйте зависимые изменения. Если развёртывание сервиса А требует синхронного обновления API или модели данных в Б, это сигнал о размытых границах bounded contexts.
2. Обсуждайте критические изменения заранее. Когда breaking change неизбежен, все downstream-потребители должны получить план миграции до начала развёртывания.

Если развёртывание микросервиса А невозможно без одновременного развёртывания микросервиса Б, перед вами не два микросервиса, а один монолит, разрезанный по ошибке. — Distributed Monolith Anti-Pattern

IICI vs CD vs Continuous Deployment

Эти три понятия часто путают, хотя между ними принципиальная разница:

На практике сквозное непрерывное развёртывание для stateful EDA реализуется крайне редко: обновление может потребовать полного перестроения state и повторного прогона входных потоков, что занимает часы и создаёт колоссальную нагрузку. Большинство команд останавливаются на непрерывной доставке (CD-delivery), оставляя за собой право выбирать момент запуска.

IIIKubernetes operators: управление EDA-инфраструктурой

Для деплоя Kafka Streams, Flink, Kafka Connect нужны operators — Kubernetes-контроллеры, которые знают, как управлять специфическими workloads.

# Пример CRD для Kafka-топика (Strimzi)
apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaTopic
metadata:
  name: orders-raw-stream
  labels:
    strimzi.io/cluster: my-cluster
spec:
  partitions: 12
  replicas: 3
  config:
    retention.ms: 2592000000
    cleanup.policy: delete

---
# Пример CRD для Flink job (Flink K8s Operator)
apiVersion: flink.apache.org/v1beta1
kind: FlinkDeployment
metadata:
  name: order-enrichment
spec:
  image: my-registry/order-enrichment:1.2.0
  flinkVersion: v1_18
  jobManager:
    resource:
      memory: 2048m
      cpu: 1
  taskManager:
    resource:
      memory: 4096m
      cpu: 2
  job:
    jarURI: local:///opt/flink/usrlib/order-enrichment.jar
    parallelism: 4
    upgradeMode: savepoint

Operators дают декларативный подход: вы описываете желаемое состояние в YAML, operator приводит кластер к этому состоянию. Для EDA это критично — вручную управлять Kafka + Schema Registry + Kafka Connect + мониторинг + 100 микросервисов нереально.

IVStatefulSet и PVC: stateful workloads в Kubernetes

Kafka Streams, Flink TaskManagers и другие stateful EDA-сервисы требуют особого подхода к деплою:

# Пример StatefulSet для Kafka Streams
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: order-processor
spec:
  serviceName: order-processor
  replicas: 3
  selector:
    matchLabels:
      app: order-processor
  template:
    metadata:
      labels:
        app: order-processor
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchLabels:
                app: order-processor
            topologyKey: kubernetes.io/hostname
      containers:
      - name: processor
        image: my-registry/order-processor:1.2.0
        volumeMounts:
        - name: state
          mountPath: /var/lib/kafka-streams
  volumeClaimTemplates:
  - metadata:
      name: state
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 100Gi

VGitOps и environment promotion

GitOps — декларативный подход, при котором желаемое состояние кластера описано в git, а controller (Argo CD, Flux) синхронизирует реальное состояние с этим описанием.

1. Dev → Staging → Production. Последовательное продвижение изменений через среды.
2. Environment parity. Одинаковые конфигурации во всех средах — то, что работает в staging, работает в production.
3. Configuration management. Helm, Kustomize для параметризации манифестов.
4. Automated sync. Argo CD сам применяет изменения из git через N секунд после коммита.
5. Rollback через git revert. Откат = revert коммита в git, controller приводит кластер к предыдущему состоянию.

VIDatabase migrations: schema evolution для state stores

В EDA сервисы обычно имеют внешние state stores (PostgreSQL, DynamoDB) помимо Kafka. Как мигрировать схему БД безопасно?

Expand-Migrate-Contract для БД

1. Expand: добавить новое поле рядом со старым. Оба заполняются.
2. Migrate: обновить код читать новое поле. Двойная запись.
3. Contract: удалить старое поле после миграции всех потребителей.

Это тот же паттерн, что и для схем событий (глава III). Единый подход к evolution схем — событий и БД — снижает когнитивную нагрузку на команду.

VIIБазовый шаблон: полная остановка и перезапуск

Самый простой и универсальный подход. Служит основой для всех остальных шаблонов и подходит, когда допустимо кратковременное прекращение обработки.

1. Фиксация кода. Разработчик сливает изменения в основную ветку, запускается CI.
2. Автотесты. Unit + integration тесты с изолированными средами (Testcontainers, глава XV).
3. Предварительные проверки. Входные/выходные потоки существуют, ACL выданы, новые схемы совместимы (глава III).
4. Остановка, очистка, запуск. Старые экземпляры останавливаются. При необходимости сбрасываются state stores, offsets, internal topics. Разворачивается новый контейнер. Если запуск провалился — откат.
5. Пост-проверки. Consumer lag вернулся к норме, в логах нет аномалий, endpoints отвечают.

VIIIRolling Update: непрерывное обновление

Вместо одновременной остановки всех экземпляров система обновляет их по одному. В каждый момент часть инстансов работает на старой версии, часть — на новой. Это обеспечивает нулевой простой обработки в реальном времени.

Когда это работает

• Добавлены новые поля во входные события, бизнес-логика научилась их обрабатывать.
• Подключены новые входные потоки.
• Исправлены ошибки, не требующие reprocessing.

Когда это опасно

Продвинутые CI/CD-пайплайны автоматически запускают тест совместимости выпуска (release compatibility test), который проверяет, действительно ли обновление может пройти «на лету». Ручная оценка рисков крайне ненадёжна.

IXCanary deployment: 1% трафика

Canary — промежуточный подход между rolling update и blue-green. Новая версия обрабатывает небольшую долю трафика (обычно 1–5%), метрики сравниваются, и только при соответствии — процент увеличивается.

Метрики для canary analysis

• Error rate. Должна быть не выше, чем у старой версии.
• Consumer lag. Новая версия не должна отставать.
• Throughput. Не должна упасть.
• Processing time p99. Должна быть в пределах SLA.
• DLQ rate. Не должна расти.

XBlue-green deployment: где работает и где ломается

Классический приём из мира синхронных микросервисов: рядом со старой («зелёной») разворачивается полная копия новой («синей»). У «синей» — собственный state store, собственная consumer group, собственные сетевые адреса. Она догоняет «зелёную», после чего маршрутизатор плавно переключает трафик.

Где это работает

• Микросервисы, обслуживающие синхронные запросы (REST API), где критически важен нулевой простой.
• Сценарии, где события генерируются исключительно из request-response (конвертация CRUD-операций в события, глава XIII).

Где это ломается

Если вы всё же применяете blue-green, убедитесь, что мониторинг, alerting и autoscaling учитывают наличие двух consumer groups. После переключения «зелёные» экземпляры можно либо сразу отключить, либо оставить в standby для быстрого отката.

XIBreaking schema changes: миграция без боли

Рано или поздно бизнес-модель меняется настолько, что старую схему невозможно эволюционировать инкрементально. Сущность «Клиент» превращается в «Аккаунт», поля переименовываются, типы меняются. В этом случае развёртывание затрагивает не только производителя, но и всех потребителей потока.

Для сущностных событий (бесконечно хранимых, материализуемых в таблицы) синхронизированная миграция почти всегда требует полного пересоздания потока: производитель заново прогоняет исходные данные через новую логику. Для несущностных событий (с TTL) проще — потребители начинают читать новый поток, а старый со временем очистится сам.

XIIFeature flags: отделить деплой от релиза

Feature flags позволяют деплоить код, но не включать новое поведение. Это отделяет deployment (техническое событие) от release (бизнес-событие).

// Пример: feature flag для нового формата события
if (featureFlags.isEnabled("use-new-order-format", userId)) {
    producer.send("orders-v2", newOrderEvent);
} else {
    producer.send("orders", legacyOrderEvent);
}

XIIIRollback strategies: что делать, когда что-то пошло не так

XIVSaga и graceful shutdown

Если у вас есть активные Saga (глава VIII), деплой может их прервать. Что делать?

1. Graceful shutdown. Дать текущим Saga завершиться перед остановкой.
2. Draining mode. Перестать принимать новые Saga, дождаться завершения старых.
3. Saga versioning. Новая версия для новых Saga, старая для активных (глава VIII).
4. Timeout policy. Что делать, если Saga висит слишком долго? Принудительно компенсировать или продлить?

// Graceful shutdown с drain
Runtime.getRuntime().addShutdownHook(new Thread(() -> {
    running = false;
    // Дождаться завершения активных Saga (до N секунд)
    sagaManager.drain(Duration.ofMinutes(5));
    consumer.close(Duration.ofSeconds(10));
}));

XVDeployment monitoring: что смотреть во время деплоя

Инструменты: Prometheus + Grafana, Argo Rollouts dashboards, Confluent Control Center, Datadog APM.

XVICost of deployment: сколько стоит выкатить новую версию

XVIIЧеклисты и связь с циклом

Связь с предыдущими главами

Чеклист развёртывания EDA

• CI/CD pipeline настроен и проходит автоматически
• Schema compatibility check в CI (Backward / Forward / Full)
• Contract testing в CI (Pact, schema validation)
• Testcontainers для integration tests
• Kubernetes operator установлен (Strimzi, Flink K8s Operator)
• StatefulSet + PVC для stateful workloads
• Pod Disruption Budget настроен
• Anti-affinity для распределения по node'ам
• GitOps (Argo CD, Flux) для декларативного деплоя
• Database migrations через Flyway / Liquibase / Expand-Migrate-Contract
• Выбран шаблон: full stop, rolling, canary, blue-green
• Feature flags для отделения деплоя от релиза
• Rollback strategy определена (instant, state, offset, schema, full)
• Graceful shutdown для Saga
• Deployment monitoring настроен (lag, error rate, throughput)
• Cost of deployment оценён и оптимизирован
• SLA учитывает время перестройки state и downstream impact
• Команда-владелец самостоятельно запускает и откатывает релизы

Ключевые выводы главы

1. Развёртывание EDA — это не «залить контейнер». Перестройка state, reprocessing, schema evolution, downstream impact.
2. Принципы: автономия команд, единый стандарт, self-service, учёт reprocessing.
3. CI/CD/CD — три этапа, но для stateful EDA часто останавливаются на CD-delivery.
4. Kubernetes operators — Strimzi, Flink K8s Operator, Confluent for Kubernetes.
5. StatefulSet + PVC — stateful workloads в K8s.
6. GitOps — декларативный деплой, environment promotion через git.
7. Database migrations — Flyway, Liquibase, Expand-Migrate-Contract.
8. Полная остановка — базовый шаблон, работает всегда.
9. Rolling Update — нулевой простой, но не для изменений топологии или state.
10. Canary — 1% → 10% → 50% → 100%, автоматический rollback по метрикам.
11. Blue-green — для синхронных API, не для потоковых производителей.
12. Breaking schema — продолженная (два потока) vs синхронизированная (один поток).
13. Feature flags — отделить деплой от релиза, kill switch.
14. Rollback strategies — instant, state, offset, schema, full.
15. Saga и graceful shutdown — дождаться завершения активных Saga.
16. Deployment monitoring — lag, error rate, throughput, DLQ rate.
17. Cost of deployment — state rebuild, reprocessing, blue-green × 2.

Глава XVI цикла «Событийно-управляемая архитектура». Источники: Kubernetes, Strimzi, Flink Kubernetes Operator, Confluent for Kubernetes, Argo CD, Argo Rollouts, Flagger, Flyway, Liquibase, LaunchDarkly, Unleash, Temporal, Prometheus, практические кейсы production-систем, FinCodeCow experience.