Если первая глава отвечала на вопрос «почему» бизнесу нужны событийно-управляемые микросервисы, то теперь пришло время разобрать «как» они устроены под капотом. Событийно-управляемая архитектура (EDA) — это не просто очередь сообщений, скрытая за красивым API. Это принципиально иная парадигма работы с данными, где каждый факт становится неизменяемой частью истории, а сервисы выступают в роли независимых наблюдателей и преобразователей этой истории.

IДва уровня топологии: внутренняя кухня и бизнес-карта

В мире EDM термин «топология» используется для описания архитектуры на двух совершенно разных уровнях. Понимание разницы между ними критически важно для проектирования.

Топология микросервиса — это «внутренняя кухня» одного конкретного сервиса. Она описывает, как входящие события фильтруются, трансформируются, обогащаются и в конечном итоге публикуются в исходящие потоки. Это граф операций, управляемых данными, где узлами выступают стандартные преобразования:

Бизнес-топология — это «карта города». Она показывает, как множество независимых микросервисов, потоков событий и REST API взаимодействуют друг с другом для выполнения сложных сквозных бизнес-процессов. Здесь микросервисы — это узлы, а потоки событий — дороги между ними.

Принципиальное отличие бизнес-топологии EDA от обычной диаграммы REST-вызовов заключается в модели распространения данных. В REST-сети каждый вызов — это «точка-точка»: сервис А вызывает сервис Б, и больше никто об этом не знает. В событийной топологии один поток могут одновременно читать десятки независимых потребителей в режиме pub-sub: сервис уведомлений, сервис аналитики, сервис биллинга и поисковый индексатор — все подписаны на один и тот же поток OrderEvents, и ни один из них не знает о существовании остальных.

IIАнатомия события: больше, чем просто сообщение

Событие — это констатация факта. В отличие от классических систем передачи сообщений, где сообщение — это команда «сделай что-то», событие говорит: «вот что уже произошло». События всегда называются в прошедшем времени (OrderPlaced, PaymentProcessed, CustomerRegistered), а не в повелительном наклонении — это не случайно, а чтобы подчеркнуть их природу: факт уже свершён и не может быть отменён.

В практике EDA события принято классифицировать не по наличию ключа, а по семантике — тому, какой объём информации они несут и как потребители должны с ними работать.

Domain Events — значимые бизнес-факты, о которых заботятся эксперты предметной области. Например, OrderPlaced включает ID заказа, ID клиента, список позиций, сумму и временную метку. Это «богатые» события, которые несут в себе полноценный контекст произошедшего изменения.

Event Notification Events — лёгкие сигналы, которые лишь сообщают, что что-то произошло, не передавая подробностей. Например, CustomerProfileUpdated может содержать только ID клиента и секцию, которая изменилась (ADDRESS), заставляя потребителя запросить актуальное состояние через API.

Event-Carried State Transfer Events — события, которые несут внутри себя snapshot или delta состояния сущности, позволяя потребителям обновлять свои локальные проекции без обращения к источнику. Именно этот тип событий лежит в основе материализованных проекций и CQRS.

Независимо от семантического типа, событие обычно содержит ключ — идентификатор сущности, к которой оно относится. Ключ определяет, в какую партицию потока попадёт событие, и гарантирует, что все события, относящиеся к одному объекту или пользователю, будут обрабатываться в строгом порядке.

IIIМагия дуальности «Таблица-Поток»

Одна из самых мощных концепций в EDM — это возможность материализовать поток событий в таблицу состояний (просто применяя события по порядку) и, наоборот, превращать изменения в таблице обратно в поток событий. Поток — это история изменений; таблица — это текущее состояние, вычисленное из этой истории. Это две формы одних и тех же данных, и переход между ними — чистая функция.

Практическое применение этой дуальности — паттерн CQRS (Command Query Responsibility Segregation). Сервис подписывается на поток событий (например, OrderEvents), материализует из него локальную таблицу-проекцию (read model) и отдаёт её через REST API. Запись и чтение разделены: команды изменяют состояние через события, а запросы читают из оптимизированных проекций.

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

Если сущность удаляется, в поток отправляется специальное событие — tombstone (метка об удалении). Потребители, материализовавшие проекции из этого потока, при получении tombstone очищают соответствующие записи в своих локальных хранилищах. В Kafka для этого существует режим log compaction: брокер сохраняет только последнее значение для каждого ключа, удаляя промежуточные записи, что превращает поток в компактный snapshot текущего состояния.

IVБрокер событий vs брокер сообщений

Многие разработчики по привычке путают брокеры событий (Event Brokers, например, Apache Kafka, Redpanda) с классическими брокерами сообщений (Message Brokers, например, RabbitMQ, ActiveMQ). Разница между ними фундаментальна.

Ключевые требования к современному брокеру событий:

1. Партиционирование — разделение потоков на подпотоки (партиции) для параллельной обработки. Количество партиций задаёт верхнюю границу параллелизма: если в потоке 6 партиций, то максимум 6 потребителей в группе смогут обрабатывать события одновременно.
2. Строгая упорядоченность — внутри одной партиции события всегда идут в том же порядке, в котором были опубликованы. Глобального порядка между партициями не существует.
3. Неизменяемость — опубликованное событие нельзя изменить. Можно только добавить новое.
4. Бесконечное хранение и воспроизводимость — возможность прочитать данные в любой момент времени, с любого offset.

VСравнение брокеров: что выбрать

Выбор брокера — не религиозный вопрос, а инженерный. Ниже — сравнение основных игроков рынка.

Практическое правило: если нужна очередь задач — RabbitMQ или SQS. Если нужен поток фактов — Kafka, Redpanda, Pulsar или EventStoreDB. Смешивать роли в одном инструменте — путь к distributed big ball of mud.

VIПаттерны потребления: потоки против очередей

Брокер событий предоставляет данные потребителям двумя основными способами, в зависимости от бизнес-задачи.

Потребление в качестве потока событий (Event Stream)

Каждый потребитель сам управляет своим «смещением» (offset) — указателем на то, какое событие он прочитал последним. Несколько независимых групп потребителей (consumer groups) могут читать один и тот же поток, не мешая друг другу: каждая группа поддерживает собственный offset и движется в своём темпе.

Например, сервис инвентаризации и сервис уведомлений могут быть двумя разными consumer groups, читающими один и тот же топик OrderEvents. Сервис инвентаризации обрабатывает события синхронно и держит offset близко к «хвосту» потока. Сервис уведомлений может отставать на часы при пиковых нагрузках — и это нормально, события не потеряются.

Потребление в форме очереди (Queue)

Событие обрабатывается только одним экземпляром потребителя из пула. В Kafka это достигается через consumer group: все консьюмеры с одинаковым group.id делят партиции топика между собой. Если потребителей больше, чем партиций, «лишние» простаивают. Если потребитель падает, его партиции перераспределяются — этот процесс называется rebalance.

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

Управление offset

Offset — это позиция потребителя в партиции. Kafka не отслеживает прогресс потребителя автоматически — это ответственность самого потребителя. Потребитель регулярно коммитит offset, отмечая, какие события он успешно обработал.

При rebalance потребитель, потерявший партицию до коммита, передаёт её новому владельцу, который начнёт с последнего закоммиченного offset — и события, уже обработанные, но не закоммиченные, будут обработаны повторно. Это нормально для at-least-once, но означает, что потребители должны быть идемпотентными.

VIIИдемпотентность: почему одно и то же событие придёт дважды

В распределённых системах дубликаты — это не баг, а норма. Потребитель упал до коммита offset, произошёл rebalance, сообщение обработалось заново. Сетевой сбой вызвал ретрай продюсера, и брокер записал событие дважды. Результат: потребитель увидит одно и то же событие как минимум дважды за время жизни системы.

Защита от дубликатов строится на нескольких уровнях:

1. Idempotent Producer — Kafka присваивает каждому продюсеру уникальный PID (Producer ID) и sequence number для каждой записи. Брокер отслеживает последовательность и отбрасывает дубликаты на уровне партиции. Включается настройкой enable.idempotence=true (с Kafka 3.0 — по умолчанию).
2. Idempotent Consumer — потребитель сам отслеживает, какие события уже обработал, по уникальному идентификатору (event ID, хеш payload, комбинация ключа и версии). Реализуется через таблицу дедупликации в БД, upsert-семантику или окно дедупликации.
3. Exactly-Once Semantics (EOS) — Kafka предоставляет транзакционный механизм: продюсер и потребитель координируются через transactional.id, обработка и коммит offset происходят атомарно.

Пример идемпотентного потребителя с таблицей дедупликации:

BEGIN TRANSACTION;

IF EXISTS (SELECT 1 FROM processed_events WHERE event_id = :id) THEN
    COMMIT;
    RETURN;
END IF;

INSERT INTO processed_events (event_id, processed_at)
VALUES (:id, NOW());

UPDATE balances SET amount = amount + :delta
WHERE account_id = :account_id;

COMMIT;

Практическое правило: at-least-once + идемпотентный потребитель = effectively exactly-once. Это проще и надёжнее, чем транзакционный EOS, для большинства сценариев.

VIIIOut-of-order delivery: sequence numbers и коррекция

Даже при строгой упорядоченности внутри партиции, потребитель может столкнуться с нарушением порядка на нескольких уровнях:

• При rebalance партиции перераспределяются, и новый владелец может начать с позиции, предшествующей тому, где остановился предыдущий.
• При параллельной обработке внутри одного потребителя события из одной партиции могут быть обработаны не по порядку.
• При кросс-партиционном чтении глобальный порядок не гарантируется: событие из партиции 1 может быть обработано раньше события из партиции 0.

Защита — встраивание sequence number в payload события. Потребитель сравнивает полученный номер с ожидаемым и:

Sequence number может быть:

• Монотонным счётчиком на сущность — генерируется продюсером, хранится в БД рядом с сущностью. Надёжно, но требует транзакционной записи.
• Версией агрегата — в event sourcing каждая версия агрегата имеет номер, который увеличивается на 1 при каждом событии.
• Timestamp + tiebreaker — слабее, но проще. Подходит для нестрогих сценариев, где допустимы мелкие нарушения порядка.

Для критичных сценариев (финансовые транзакции, инвентаризация) это необходимая мера. Для аналитики и уведомлений — как правило, избыточная.

IXSchema Registry: контракты событий как публичный API

Событие, пересекающее границу сервиса, — это публичный контракт. У него есть потребители, которых вы часто не контролируете и не всегда знаете. И как любой API, контракт события придётся менять: добавлять поля, переименовывать, дробить. Без формализованного управления схемами эволюция событий превращается в хаос — один производитель добавит поле, а десяток потребителей тихо упадёт при десериализации.

Schema Registry — централизованное хранилище схем событий (Confluent Schema Registry, Apicurio Registry, AWS Glue Schema Registry). Продюсер регистрирует схему, консьюмер по идентификатору в сообщении получает нужную версию.

Это даёт:

• Проверку совместимости при публикации — registry отклонит несовместимое изменение схемы ещё на этапе деплоя, а не в продакшене у потребителя.
• Компактность — в сообщении передаётся ID схемы, а не вся схема.
• Единый источник правды о форматах событий.

Для систем с event sourcing и долгим хранением критически важны transitive-режимы: они гарантируют, что новая версия схемы совместима со всеми предыдущими. Без этого потребитель, читающий события годовой давности, может не справиться с десериализацией.

XConsumer lag и DLQ: здоровье потока и обработка ошибок

Consumer lag — главная метрика здоровья EDA

Consumer lag — это разница между последним опубликованным событием в партиции (log-end-offset) и последним обработанным событием потребителя (current-offset). Если lag растёт — потребитель не успевает. Если lag стабилен и близок к нулю — система здорова.

lag = log-end-offset - current-offset

Инструменты мониторинга:

• Burrow — специализированный мониторинг lag от LinkedIn, оценивает здоровье потребителей по sliding window.
• Kafka Lag Exporter — экспорт метрик lag в Prometheus.
• Confluent Control Center — коммерческий мониторинг с алертами.
• Kafka Exporter — open-source экспортёр для Prometheus + Grafana.

Пороги зависят от сценария:

Dead Letter Queue — куда девать «ядовитые» события

Рано или поздно потребитель получит событие, которое не может обработать: битая схема, логическая ошибка, отсутствующая сущность. Если такое событие блокирует партицию, весь поток встаёт. Решение — Dead Letter Queue (DLQ).

Как это работает:

1. Потребитель получает событие и пытается его обработать.
2. Обработка падает. Событие уходит в retry topic с задержкой (например, 5 минут, 30 минут, 2 часа).
3. После N попыток событие отправляется в DLQ — отдельный топик для ручного разбора.
4. Потребитель продолжает обрабатывать следующие события — поток не блокируется.

Что важно в дизайне DLQ:

• Метаданные — сохраняйте не только payload, но и причину ошибки, offset, timestamp, ID потребителя.
• Алертинг — любое событие в DLQ должно порождать алерт. Если в DLQ тихо, а вы об этом не знаете — вы уже проиграли.
• Replay-механизм — должна быть возможность вернуть событие из DLQ в исходный поток после исправления бага или данных.
• Политика retention — DLQ должна хранить данные долго (месяцы), чтобы успеть разобраться.

XIИнфраструктурный фундамент и «налог на микросервисы»

Событийно-управляемые микросервисы не живут в вакууме. Им нужна инфраструктура. Сегодня стандартом де-факто для упаковки и оркестрации этих сервисов являются контейнеры (Docker) и системы управления контейнерами (Kubernetes). Они позволяют сервисам масштабироваться, восстанавливаться после сбоев и изолироваться друг от друга.

Но контейнеризация — лишь верхушка айсберга. Полноценная EDM-инфраструктура включает:

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

XIIСинтез: связь с первой главой и фундамент для следующих

Вторая глава закладывает техническую базу для всего дальнейшего путешествия. Но она также углубляет связь с первой главой — организационной.

В первой статье мы говорили о законе Конвея и о том, что архитектура отражает структуру команд. Теперь мы можем увидеть это на конкретном уровне:

Микросервисы в EDM — это не просто изолированные куски кода, а узлы в графе потоков событий. Брокер событий — не просто «труба» для передачи данных, а надёжное хранилище истины, которое позволяет развязать сервисы во времени и пространстве.

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

1. Топология EDA работает на двух уровнях: внутреннем (граф операций над событиями) и бизнесовом (сеть pub-sub-подписок, принципиально отличная от REST-сетки вызовов).
2. События классифицируются по семантике: domain events (богатые факты), notification events (лёгкие сигналы), event-carried state transfer (события с полным состоянием). Выбор типа влияет на связанность и нагрузку.
3. Дуальность «таблица-поток» — основа CQRS и материализованных проекций: сервисы делятся состоянием исключительно через потоки, без прямых обращений к чужим базам.
4. Брокер событий принципиально отличается от брокера сообщений: неизменяемый журнал фактов, а не диспетчер с уничтожением после прочтения.
5. Партиционирование задаёт предел параллелизма: количество партиций — это потолок для активных потребителей в группе.
6. Идемпотентность потребителей — не опция, а необходимость: at-least-once — реальность, и потребитель должен быть готов к дубликатам.
7. Schema Registry превращает хаотичную эволюцию событий в управляемый процесс с проверкой совместимости на этапе деплоя.
8. Consumer lag и DLQ — обязательные элементы production-системы. Без мониторинга lag вы не знаете, что происходит. Без DLQ — теряете события, которые не смогли обработать.
9. Инфраструктурный налог включает не только брокер, но и registry, CDC, observability и CI/CD со схемами. Для малых команд модульный монолит — разумная стартовая точка.

Глава II цикла «Событийно-управляемая архитектура». Источники: Confluent, Redpanda, Conduktor, Architecture Weekly, Microsoft Azure Architecture Center, практические кейсы production-систем.