Чем больше систем в контуре организации, тем дороже обходятся прямые связи между ними. Десять систем – это потенциально сорок пять интеграций «точка-точка», каждую из которых кто-то пишет, версионирует и чинит при любом изменении формата. В крупном банке, ведомстве или производстве такая схема превращается в неуправляемый клубок. Шина данных и событийная архитектура решают эту задачу по-разному, и выбор между ними определяет стоимость владения на годы вперёд.

ESB: единая точка обмена

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

ESB хорошо ложится на сценарии «запрос-ответ»: проверить контрагента в реестре, получить выписку, синхронизировать справочник. Шина даёт прозрачность – видно, кто, что и когда передал. Для госсектора это критично: требования к протоколированию и юридической значимости обмена тут жёстче, чем в коммерции.

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

Событийная архитектура: реагируем на факты

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

Это даёт устойчивость к нагрузке и сбоям – события копятся в брокере (Apache Kafka, RabbitMQ) и обрабатываются по мере готовности. Подход выигрывает там, где потоки большие и асинхронные: телеметрия, транзакции, обработка обращений граждан в реальном времени.

Платить приходится сложностью. Согласованность становится «в конечном счёте», отладка распределённых цепочек труднее, а гарантии доставки и идемпотентность нужно проектировать с самого начала, а не дописывать потом.

Что выбрать на практике

Противопоставлять их не обязательно. Зрелые контуры комбинируют: ESB закрывает синхронные запросы к мастер-системам и реестрам, событийная шина обслуживает асинхронные потоки и уведомления. Стартовая точка – карта систем и классификация обмена по критичности, объёму и требованиям к согласованности.

Для российских заказчиков добавляется ещё один фактор – технологический стек. Курс на импортозамещение в реестре отечественного ПО и задачи, заданные паспортом нацпрограммы «Цифровая экономика», смещают выбор в сторону открытых брокеров и решений из реестра. Как показал 2018 год, запросы на межведомственную и межсистемную интеграцию только растут, и закладывать архитектуру стоит с прицелом на смену поставщиков без переписывания связей.

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

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