Как публикация события меняет временную связанность сервисов по сравнению с синхронным вызовом?
Синхронный вызов создаёт временную связанность: вызывающий сервис должен дождаться доступности и ответа вызываемого сервиса. Публикация события разделяет момент выполнения отправителя и обработку получателем: отправитель может завершить свою операцию, пока потребитель недоступен или обрабатывает событие позже.
Это повышает автономность и устойчивость к кратковременным сбоям, но переносит сложность в область асинхронной обработки: появляются задержки, повторная доставка, необходимость отслеживать состояние обработки и принимать согласованность данных с задержкой.
В распределённых системах сетевые задержки, временная недоступность узлов и независимое масштабирование делают постоянное ожидание удалённого ответа дорогим. Синхронная модель удобна для операций, которым нужен немедленный результат, но она связывает жизненный цикл одной операции с доступностью всей цепочки зависимостей.
Событийная интеграция появилась как способ уменьшить эту связанность. Один сервис фиксирует факт изменения и передаёт его через промежуточный механизм доставки, а другие сервисы обрабатывают факт в собственном темпе.
Представим оформление заказа: сервис заказа должен сообщить сервису уведомлений о созданном заказе. При синхронном вызове недоступность уведомлений может задержать или сорвать оформление, хотя сама бизнес-операция заказа не зависит от немедленной отправки сообщения.
При событийной интеграции заказ может быть создан независимо от текущей доступности уведомлений. Однако пользователь или другой сервис некоторое время увидит состояние, в котором заказ уже создан, а уведомление ещё не отправлено. Неверно считать это бесплатным устранением зависимости: непосредственная временная связанность уменьшается, но возникает зависимость от надёжной доставки и корректного контракта события.
При синхронной интеграции отправитель инициирует запрос и удерживает контекст операции до получения результата или ошибки. Поэтому доступность, задержка и ограничения пропускной способности получателя непосредственно влияют на отправителя. Тайм-аут уменьшает время ожидания, но не делает вызов асинхронным: после тайм-аута результат операции может оставаться неизвестным.
При событийной интеграции отправитель публикует событие о уже произошедшем факте, например о создании заказа. Брокер или другой механизм доставки временно хранит сообщение, а потребитель извлекает его позже. Это называется временной развязкой: отправитель и потребитель не обязаны быть одновременно доступны.
Развязка имеет границы. Отправитель всё ещё зависит от доступности компонента, принимающего событие, если публикация выполняется непосредственно в рамках операции. Кроме того, остаются зависимости от формата события, его семантики, правил повторной доставки и срока хранения сообщений.
Потребитель должен быть готов к задержкам и повторной доставке. Обычно обработку делают идемпотентной, а состояние доставки контролируют через идентификатор события, журнал обработанных сообщений или иной механизм, соответствующий требованиям домена. Это не является частью самой временной развязки, но необходимо для практической надёжности событийной схемы.
События подходят, когда получателю достаточно узнать о факте изменения и ответ не требуется немедленно. Синхронный вызов предпочтителен, когда вызывающему нужно получить решение или результат сейчас: например, разрешение операции, проверку лимита или подтверждение доступности ресурса.
Главный компромисс таков: синхронная интеграция проще для немедленного запроса-ответа, но сильнее связывает доступность сервисов; событийная интеграция лучше изолирует сбои и позволяет масштабировать обработку независимо, но усложняет наблюдаемость, обработку ошибок и пользовательское ожидание результата.
Сервис заказов синхронно вызывал сервис аналитики после каждого оформления. При росте нагрузки аналитика стала отвечать медленнее, из-за чего увеличилось время оформления заказа и начали возникать тайм-ауты. Команда рассмотрела три варианта.
Увеличение тайм-аутов сохраняло прежнюю модель и почти не требовало изменений, но ещё дольше удерживало ресурсы сервиса заказов и не решало проблему недоступности аналитики. Полное удаление интеграции устраняло связанность, но лишало аналитическую систему данных.
Публикация события «заказ создан» позволила сервису заказов завершать свою операцию независимо от обработки аналитикой. Потребитель аналитики стал обрабатывать события с собственной скоростью, повторять временно неудачные попытки и отдельно отслеживать отставание очереди.
Выбранное решение было обосновано тем, что аналитика не участвует в принятии решения о создании заказа и ей не нужен немедленный ответ. В результате задержка оформления перестала зависеть от времени ответа аналитики, но команда отдельно приняла допустимую задержку появления данных и добавила контроль необработанных сообщений.
Ответ: Нет. Она устраняет или уменьшает прежде всего временную зависимость, но сохраняет другие виды связанности. Потребитель зависит от контракта события, его семантики и доступности канала доставки. Если отправитель меняет смысл события или публикует его с недостаточной надёжностью, система всё равно ломается, хотя прямого вызова больше нет.
Кроме того, событие может быть частью бизнес-процесса, а значит, его отсутствие или неверная обработка приведут к функциональной ошибке. Поэтому событийная архитектура не означает отсутствия контрактов и координации; она меняет их форму и момент взаимодействия.
Ответ: Отправителю сначала нужно надёжно передать сообщение в очередь. Если публикация выполняется синхронно и брокер недоступен, отправитель может не суметь подтвердить свою бизнес-операцию либо окажется перед выбором между потерей события и задержкой ответа.
Чтобы разделить фиксацию бизнес-изменения и доставку события, применяют устойчивый механизм публикации, например паттерн исходящих сообщений: изменение и запись события для последующей доставки фиксируются согласованно в хранилище отправителя, а отдельный процесс повторяет публикацию. Это уменьшает риск потери события, но добавляет задержку, фоновые процессы и необходимость мониторинга.
Ответ: Это произойдёт, если вызывающему нужен немедленный результат, а команда искусственно превращает запрос в событие. Например, проверку права на операцию нельзя считать завершённой только потому, что событие проверки опубликовано: результат появится позже, а пользовательская операция останется неопределённой.
Проблема также возникает, когда бизнес ожидает мгновенно согласованное состояние, но инфраструктура и интерфейсы не учитывают задержку. Тогда вместо уменьшения связанности появляются сложные обходные механизмы ожидания, корреляции и компенсации. Событийный подход оправдан, когда допустимы асинхронность и отложенная обработка, а не просто потому, что он считается более масштабируемым.