Как гарантировать доставку сообщений между системами: брокер и шина данных

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

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

Здесь упоминается:

Digital Q.MessageBroker

Подробнее

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

Здесь упоминается:

Digital Q.Integration

Подробнее

Материал будет полезен ИТ-директорам, CIO, CTO, архитекторам, системным и интеграционным аналитикам, руководителям разработки и бизнес-заказчикам интеграционных проектов. Для такой архитектуры в экосистеме Digital Q представлены интеграционная шина данных Digital Q.Integration и брокер сообщений Digital Q.MessageBroker.

Что такое гарантированная доставка сообщений

Речь идёт об обязательстве между компонентами системы: при временном сбое событие сохраняется и после восстановления доступности должно оказаться у получателя. Пока получатель не подтвердил приём, сообщение не считается обработанным, и потребитель сможет прочитать его повторно.

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

Гарантированная и надежная доставка: в чем разница

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

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

Почему обычный HTTP-вызов не всегда подходит для надежной интеграции

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

Как только приёмник перегружен или недоступен, операция обрывается, а инициатор не понимает, выполнилась ли она. Для критичных процессов этого недостаточно.

Какие проблемы возникают при прямой интеграции

Основные риски синхронной связки удобно перечислить списком:

• Жесткая зависимость от доступности приёмника: он упал — операция не проходит;
• Неопределенность при таймауте: запрос ушёл, но ответ не вернулся, и статус неясен;
• Дубли при повторной отправке: повторный заказ, платёж или заявка;
• Потеря запроса при обрыве сети без возможности восстановления;
• Каскадные отказы, когда медленный сервис тормозит всю цепочку.

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

Где нужна гарантированная доставка сообщений между системами

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

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

Асинхронная доставка сообщений как основа надежной интеграции

Асинхронная доставка сообщений — это способ обмена, при котором отправитель не ждет немедленного ответа. Он публикует событие в промежуточное хранилище и продолжает работу.

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

При прямом вызове недоступность приёмника обрывает операцию, при асинхронной схеме событие сохраняется и доставляется после восстановления

Как работает асинхронная доставка сообщений

Логика проста и повторяема. Между приложениями появляется посредник, который держит поток событий.

1. Приложение-источник публикует событие в очередь или топик;
2. Посредник подтверждает прием и сохраняет запись;
3. Приложение-получатель читает событие в своем темпе;
4. Получатель подтверждает обработку, после чего запись фиксируется как завершенная.

Почему асинхронная доставка повышает надежность

Промежуточное хранилище выступает буфером. Если приёмник временно недоступен, события накапливаются и обрабатываются после восстановления, а не пропадают.

Такой буфер работает и как хранилище истории: по умолчанию Apache Kafka хранит сообщения 168 часов (семь суток), поэтому отставший потребитель успевает обработать накопленные события, а не теряет их сразу после чтения.

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

Доставка сообщений через брокер

Центральный элемент асинхронной схемы — брокер. Он выступает надёжным посредником между источником и приёмником.

Именно на нём лежит хранение потока событий и организация повторов при неудачах.

Роль брокера

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

Реализация гарантированной доставки через брокер сообщений опирается на механизм синхронных реплик и подтверждений. Промежуточное звено поддерживает набор актуальных копий — ISR (In-Sync Replicas): в него входят только реплики, чьи журналы не отстают от лидера более допустимого порога. Данные считаются зафиксированными и доступными потребителям, когда они сохранены на лидере и на всех репликах ISR. Это исключает ситуацию, при которой источник получил подтверждение публикации, а информация исчезла после смены лидера. В экосистеме Digital Q такую роль выполняет решение на базе Apache Kafka и ActiveMQ Artemis с локализацией и промышленной доработкой.

Свежий операционный контекст для Kafka важен при проектировании новых контуров: Apache Kafka 4.0.0, выпущенная в марте 2025 года, полностью перешла на KRaft и больше не поддерживает ZooKeeper, а KIP-996 добавил механизм Pre-Vote для снижения числа лишних выборов лидера в кворуме метаданных. Это подтверждает что отказоустойчивость теперь зависит не только от репликации данных, но и от корректной архитектуры управляющего слоя кластера.

Как брокер гарантирует доставку сообщений

Разберём, как брокер сообщений гарантирует доставку сообщений на уровне механики. Работают несколько встроенных приемов одновременно.

• Подтверждение публикации: источник узнает, что событие принято и сохранено;
• Хранение на диске и репликация копий на несколько узлов;
• Ожидание подтверждения обработки от потребителя;
• Повтор передачи, если подтверждение не пришло.

На заметку: уровень подтверждения задаётся параметром acks. При значении acks=all источник получает ответ только после фиксации на всех репликах ISR — максимальная надёжность. При acks=1 подтверждает лишь лидер: операция завершается быстрее, но при его отказе до репликации данные могут потеряться. При acks=0 отправитель не ждет никакого ответа — наивысшая скорость ценой возможных потерь. Для критичных интеграций рекомендуется сочетать acks=all с ограничением минимального числа синхронных реплик (параметр min.insync.replicas).

Типовая отправная конфигурация — фактор репликации 3 и min.insync.replicas равный 2: как указано в документации, при ней запись продолжается, если недоступна одна из ведомых реплик. Начиная с Apache Kafka 3.0 продюсер по умолчанию использует более строгие гарантии — acks=all с включённой идемпотентностью.

При планировании жизненного цикла кластера нужно учитывать и поддержку версий: в июне 2026 года Apache Kafka 4.3.1 исправила несколько критичных ошибок, в том числе утечку нативной памяти RocksDB в Kafka Streams. Для промышленной интеграции это аргумент в пользу регулярного обновления стендов, а не однократной настройки промежуточного звена на годы вперёд.

Типовой сценарий доставки через брокер

Покажем путь события пошагово на абстрактном примере передачи от сервиса-источника к приёмнику.

1. Источник формирует событие и публикует его в топик;
2. Посредник записывает запись, реплицирует её и возвращает подтверждение источнику;
3. Потребитель читает событие со своего смещения;
4. Потребитель выполняет бизнес-логику и фиксирует смещение;
5. Если потребитель упал до подтверждения, после перезапуска он прочитает запись снова.

Разбор ключевых сценариев сбоев поясняет, почему каждый шаг принципиален. Если брокер принял публикацию, но упал до отправки подтверждения источнику — источник не знает об успешной записи и повторит отправку после восстановления, что порождает два экземпляра одной записи в топике. Если потребитель зафиксировал смещение до завершения обработки и затем упал — запись останется необработанной — потребитель считает её пройденной, а реальная обработка не состоялась. Если же смещение зафиксировано строго после успешной обработки, но потребитель упал до фиксации — при перезапуске он прочитает ту же запись повторно. Именно поэтому режим «минимум один раз» требует дедупликации на стороне получателя, а не только корректных настроек транспорта.

Как шина данных участвует в гарантированной доставке сообщений

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

Она превращает набор очередей в управляемые интеграционные потоки с правилами и контролем.

Роль шины данных

Шина данных управляет обменом между приложениями: определяет маршруты, применяет бизнес-правила и приводит форматы к нужному виду. По сути это единая система обмена для сложного ландшафта.

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

Виктор Овчинников, руководитель продукта Digital Q.Integration компании «Диасофт»

В экосистеме для разработчиков Digital Q эту роль играет Digital Q.Integration — интеграционная платформа класса ESB, которая в 2025 году возглавила первый рейтинг российских ESB-решений по версии CNewsMarket.

Российский рынок ESB оценивали и независимые аналитики: в исследовании, которое Фонд «Сколково» и Tadviser представили в 2025 году, сравнили 12 отечественных продуктов, а референтная модель оценки включала 465 критериев. Для заказчика это означает, что при выборе шины нужно проверять не только наличие маршрутизации, но и масштабирование, безопасность, мониторинг, поддержку отечественной инфраструктуры и эксплуатационные ограничения.

Что добавляет шина данных поверх брокера

Поверх транспорта шина дает прикладную логику интеграции. Перечислим её вклад:

• Маршрутизацию событий между приёмниками по правилам;
• Преобразование форматов и структур между разными приложениями;
• Обогащение данных из смежных сервисов;
• Контроль ошибок и обработку отказов внешних вызовов;
• Аудит и мониторинг прохождения потоков.

Связка брокера и шины данных в архитектуре

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

Мировой рынок также смещается к платформенной интеграции: Gartner в опубликованном в 2025 году анализе оценивает рост рынка iPaaS за 2024 год на 23,4%, до 8,5 млрд долларов. Этот показатель отражает практический запрос бизнеса на управляемую интеграцию приложений, данных и событий, а не на набор разрозненных точечных соединений.

Такая пара разделяет ответственность и упрощает развитие ландшафта.

Общая схема взаимодействия

Логику удобно представить как цепочку. Источник публикует событие в промежуточное звено, шина забирает его, маршрутизирует и приводит к формату приёмника.

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

Зоны ответственности брокера и шины данных

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

Почему связка надежнее прямой интеграции

Прямой вызов не оставляет запаса прочности: сбой на любом участке рвёт операцию. Связка же хранит событие и повторяет отправку до успеха.

Итог для бизнеса: меньше потерь, управляемые повторы, прозрачный контроль обмена и быстрый разбор ошибок.

Протокол гарантированной доставки сообщений: из каких механизмов он состоит

Многие ищут единую настройку «включить надёжность». На практике её не существует.

Протокол гарантированной доставки сообщений — это не одна опция, а согласованный набор архитектурных приёмов на всех уровнях.

Почему это не один протокол, а набор архитектурных механизмов

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

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

Александр Сахаров, директор по работе с партнерами,член правления компании «Диасофт»

Поэтому корректнее говорить о совокупности правил, а не о единственном стандарте.

Основные элементы гарантированной доставки

В набор входят взаимодополняющие приёмы. Кратко перечислим их:

• Модели передачи: at-most-once, at-least-once, exactly-once;
• Подтверждения (ack) и повторы (retry);
• Очередь недоставленных событий (DLQ);
• Дедупликация и идемпотентная обработка;
• Transactional Outbox и мониторинг.

Модели доставки: at-most-once, at-least-once, exactly-once

Модель определяет поведение системы при сбоях и компромисс между скоростью и надежностью. Более строгая гарантия обычно снижает производительность.

Выбор зависит от требований конкретного бизнес-процесса.

Чем строже модель, тем выше накладные расходы: at-most-once допускает потери, at-least-once — дубли, exactly-once требует идемпотентности и дедупликации

At-most-once: не более одного раза

Принцип «отправил и забыл»: повторы не выполняются. Событие приходит один раз либо теряется при сбое.

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

At-least-once: минимум один раз

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

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

Exactly-once: ровно один раз

Строжайшая модель: событие обрабатывается ровно один раз в пределах поддерживаемого контура, без потерь и повторного эффекта. Достигается сочетанием идемпотентного отправителя и транзакций на стороне инфраструктуры и кода; для бизнес-логики всё равно нужны дедупликация и идемпотентность.

В Apache Kafka семантика exactly-once для операций с топиками поддерживается двумя встроенными механизмами. Идемпотентный производитель получает от посредника уникальный идентификатор, а с каждой записью передает порядковый номер — по этому номеру брокер отклоняет дубликаты. Транзакции Kafka позволяют атомарно зафиксировать записи сразу в нескольких топиках: либо все становятся видимы потребителям после завершения транзакции, либо ни одна. Потребители с режимом read_committed получают только записи из успешно завершенных транзакций, не видя промежуточных состояний.

Механизм exactly-once появился в Apache Kafka версии 0.11 и опирается на уникальный transactional.id: при подключении нового экземпляра производителя с тем же идентификатором брокер блокирует предыдущий «зомби-экземпляр», исключая параллельную запись от устаревшей сессии.

В новых версиях Kafka развиваются и очередные сценарии поверх событийной модели: в Kafka 4.0.0 механизм Share Groups, связанный с KIP-932, добавил возможность нескольким потребителям совместно читать один топик как очередь. Релизные заметки при этом предупреждают: функция вышла в режиме раннего доступа, её разработка продолжается, и на промышленных кластерах включать её нельзя. Такая модель не отменяет и требования к идемпотентной обработке: несколько экземпляров потребителя повышают пропускную способность, но бизнес-дедупликация всё равно остаётся обязательной.

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

Почему гарантированная доставка не исключает дубли

Гарантия чаще всего обеспечивает режим «минимум один раз». А значит, при повторах один и тот же факт может прийти дважды.

Важно: защита от дублей — зона приёмника. Без дедупликации и идемпотентности повтор превратится в лишний платёж или заказ.

Механизмы надежной доставки: ack, retry, DLQ, дедупликация

Рассмотрим базовые приёмы, из которых собирается устойчивый обмен. Их поддерживают и брокер, и шина.

Каждый закрывает свой класс сбоев.

Acknowledgement: подтверждение обработки

Ack — сигнал о приёме или обработке события. Если подтверждение обработки не получено, потребитель может прочитать запись снова в рамках настроенного хранения.

Ключевое правило: подтверждать факт только после реального выполнения работы, а не до неё.

Retry: повторная доставка сообщений

Retry — автоматический повтор при временных отказах: обрыв сети, недоступность приёмника, ошибка внешнего сервиса. Обычно применяются интервалы между попытками и их ограничение.

Без ограничения повторы могут стать бесконечными и перегрузить приёмник.

Dead Letter Queue

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

Команда разбирает содержимое DLQ вручную или автоматически, а затем возвращает событие в обработку.

Дедупликация сообщений

Дедупликация отсекает повторы по уникальному идентификатору события. Приёмник проверяет, обрабатывалась ли запись, и игнорирует дубль.

Часто для этого хранят таблицу принятых идентификаторов и запрещают повторную запись.

Что должен сделать разработчик для гарантированной доставки сообщений

Инфраструктура даёт транспорт, но итоговая корректность зависит от кода. Здесь важна гарантированная доставка на уровне разработки.

Разработчик закрывает согласованность данных и защиту от дублей.

Transactional Outbox

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

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

Альтернативный прием — отслеживание журнала транзакций (Transaction Log Tailing). Специализированный компонент, например Debezium, прослушивает внутренний журнал изменений базы данных и транслирует записи OUTBOX в брокер практически в реальном времени — без периодического опроса и без дополнительной нагрузки на хранилище. Важный нюанс: журнал транзакций фиксирует все изменения в базе, поэтому транслятор должен фильтровать только нужные таблицы, чтобы исключить публикацию внутренних данных во внешние системы.

Idempotent Consumer

Идемпотентный потребитель обрабатывает повтор без изменения итогового состояния. Результат первого и десятого повтора одинаков.

Реализуется через проверку идентификатора либо через операции вида UPSERT, устойчивые к повтору.

Transactional Inbox

Transactional Inbox — зеркальный паттерн к Transactional Outbox, применяемый на стороне получателя. В базе данных сервиса-получателя создается служебная таблица INBOX. При поступлении записи от посредника сервис сохраняет её в INBOX, одновременно проверяя уникальность идентификатора: дублирующие записи отклоняются на этом шаге без повторной обработки. Последующий обработчик извлекает принятые данные из INBOX и выполняет бизнес-логику в единой транзакции с фиксацией результата в целевых таблицах.

Совместное применение Transactional Outbox на стороне отправителя и Transactional Inbox на стороне получателя образует полный контур: OUTBOX сохраняет запись до публикации, а повторно доставленные дубликаты блокируются на этапе приёма. Это позволяет реализовать обработку без повторного изменения состояния в рамках базы получателя, хотя сам брокер работает в режиме «минимум один раз».

Транзакции и согласованность данных

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

В распределенной среде чаще применяют отложенную согласованность: состояния сходятся не мгновенно, но гарантированно.

Мониторинг и аудит доставки

Без наблюдаемости надёжность не проверить. Нужны метрики задержек, размера очередей, числа повторов и объёма DLQ.

На заметку: аудит фиксирует путь каждого события и упрощает разбор инцидентов и претензий.

Пример архитектуры доставки сообщений между системами

Соберём приёмы в реальный кейс. Он показывает гарантированную доставку сообщений в интеграции нескольких приложений.

Пример типичен для торговых и сервисных компаний.

Сценарий: заказ из интернет-магазина передается в ERP, склад и CRM

Покупатель оформил заказ. Дальше событие проходит путь по шагам.

1. Магазин сохраняет заказ и кладёт событие в таблицу OUTBOX в одной транзакции;
2. Публикатор отправляет событие «заказ создан» в брокер;
3. Шина маршрутизирует событие сразу в ERP, склад и CRM, приводя форматы к нужным;
4. Каждый приёмник обрабатывает событие и подтверждает результат;
5. При отказе одного приёмника событие повторяется только для него, остальные уже завершили работу.

Одно событие о заказе доходит до трёх систем: OUTBOX защищает от потери при публикации, брокер обеспечивает хранение и повторы, шина — маршрутизацию, INBOX на стороне приёмников отсекает дубли, а необработанные записи уходят в DLQ

Что обеспечивает брокер в этом сценарии

Он хранит событие в соответствии с политикой хранения, а каждый приёмник ведёт собственное смещение и подтверждает обработку отдельно. Если склад недоступен, его потребитель не фиксирует смещение, поэтому после восстановления сможет прочитать событие снова.

Он же обеспечивает повторы и репликацию, чтобы факт заказа не пропал при отказе узла.

Что обеспечивает шина данных в этом сценарии

Шина раскладывает одно событие на трёх получателей и переводит форматы под ERP, склад и CRM. Она же обрабатывает ошибки внешних вызовов.

Дополнительно шина ведёт журнал прохождения и отправляет проблемные записи в DLQ.

Типовые ошибки при проектировании гарантированной доставки

Даже с правильными инструментами команды повторяют одни и те же промахи. Разберем частые из них.

Их знание экономит месяцы разбирательств в промышленной эксплуатации.

Считать, что брокер сам гарантирует весь бизнес-процесс

Инфраструктура доводит событие до приёмника, но не отвечает за бизнес-корректность. Согласованность и защита от дублей остаются на коде.

Ставка только на настройки посредника оставляет процесс уязвимым.

Не учитывать повторную доставку и дубли

Режим «минимум один раз» почти всегда порождает повторы. Без дедупликации это ведёт к двойным платежам и заказам.

Проектировать приемник нужно с расчётом на повтор изначально.

Подтверждать сообщение до завершения обработки

Ранний ack — прямой путь к потере. Если приёмник упадёт после подтверждения, но до выполнения работы, событие исчезнет навсегда.

Правильно — фиксировать смещение строго после успешной обработки.

Не использовать DLQ и мониторинг

Без DLQ проблемная запись либо теряется, либо бесконечно повторяется и блокирует поток. Без метрик команда узнаёт о сбое от недовольного клиента.

Наблюдаемость и очередь недоставленных должны быть заложены с самого начала.

Как гарантировать доставку сообщений: практический чек-лист

Ниже — сжатый ответ на вопрос, как гарантировать доставку сообщений на практике. Чек-лист разбит по уровням ответственности.

Он помогает быстро проверить готовность интеграции.

На уровне брокера сообщений

Инфраструктурный слой настраивают в первую очередь. Минимальный набор проверок:

• Включена репликация и подтверждение записи на все синхронные копии;
• Настроены повторы и ограничение попыток;
• Заданы политики хранения и объем буфера;
• Подключён мониторинг узлов и очередей.

На уровне шины данных

Далее проверяют интеграционную логику. Здесь важны маршруты и обработка отказов:

• Описаны маршруты и правила преобразования форматов;
• Настроена обработка ошибок и DLQ;
• Ведется аудит прохождения потоков;
• Есть оповещения о сбоях интеграции.

На уровне разработки

Финальный слой закрывает бизнес-корректность. Что проверить в коде:

• Реализован Transactional Outbox у источника;
• Реализован Transactional Inbox у получателя для дедупликации на входе;
• Приёмник идемпотентен;
• Подтверждение идёт после обработки;
• Логируется путь каждого события.

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

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

Разберём три типовые ситуации.

Когда достаточно брокера сообщений

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

Это частый вариант для микросервисов внутри одного продукта.

Когда нужна шина данных

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

Она же даёт единый аудит сложного обмена.

Когда нужна связка брокера и шины данных

Для критичных процессов с множеством разнородных приёмников оптимальна пара. Транспорт отвечает за устойчивость, шина — за логику и контроль.

Такое сочетание закрывает и потери, и повторы, и наблюдаемость одновременно.

Заключение

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

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

При этом без участия разработки надёжности не достичь: нужны дедупликация, идемпотентность, Transactional Outbox и Transactional Inbox, корректные подтверждения и наблюдаемость. Именно код защищает бизнес от дублей и рассогласований.

Для критичных интеграций связка брокера и шины снижает риск потерь, делает повторы управляемыми и обеспечивает прозрачный обмен между приложениями. В экосистеме Digital Q для такого контура представлены Digital Q.Integration — интеграционная платформа класса ESB — и Digital Q.MessageBroker — локализованный брокер сообщений на базе Apache Kafka и ActiveMQ Artemis. Их выбор и конфигурацию следует соотносить с ландшафтом систем, требованиями к нагрузке, отказоустойчивости и мониторингу.