ESB (сервисная шина предприятия): что это такое

Начинается всё с интеграции точка-точка: две системы договорились о формате и обмениваются напрямую. Это нормально и правильно, пока систем мало.

Проблема в арифметике. Каждая новая система связывается не с одной, а со многими: при десяти системах попарных связей может быть до сорока пяти. Каждая — со своим форматом, своим расписанием, своим способом обработки ошибок и своим автором, который помнит, как это работает. Такой ландшафт не столько плохо работает, сколько плохо меняется: замена одной системы задевает десяток обменов.

ESB предлагает другую топологию: все подключаются к шине, а шина знает, кому что переслать и в каком виде. Вместо сорока пяти связей — десять подключений и правила внутри. Плюс появляется то, чего в точке-точке не бывает: единый лог обменов, повторная доставка при сбоях и возможность посмотреть, что вообще происходит между системами.

Типовой пример — производственный контур. Заказ создаётся в CRM, попадает в учётную систему, оттуда задание уходит в производство и на склад, статусы возвращаются обратно в CRM и в личный кабинет клиента. Без шины это пять-шесть самостоятельных обменов, каждый со своей логикой ретраев.

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

Адаптеры и подключения. Шина умеет говорить с системами на их языке: REST, SOAP, файловый обмен, очередь, прямое подключение к базе, специализированные протоколы вроде OPC UA на производстве. Для 1С обычно используют веб-сервисы или обмен через промежуточный слой.

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

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

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

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

Здесь чаще всего и происходит подмена: под задачу «навести порядок в интеграциях» покупают то, что решает другую задачу.

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

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

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

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

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

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

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

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

Раздел, который отличает работающую интеграцию от той, что «вроде настроена». Все эти ситуации случаются на любом более-менее живом ландшафте.

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

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

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

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

Если вы читаете про интеграции в 2026 году, обязательно встретите мнение, что ESB устарела. Уточним, в чём здесь правда.

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

В микросервисной архитектуре, где вы владеете всеми сервисами, ESB становится лишним центром: сервисы обмениваются событиями через брокер, внешний доступ закрывает API Gateway, а бизнес-логику маршрутов держат в самих сервисах. Шина в такой картине превращается в единую точку отказа и в место, где копится логика, которой там быть не должно, — это и называют анти-паттерном.

Практический вывод: класс системы выбирается не по моде, а по тому, чем вы владеете. Готовые системы вокруг — шина или интеграционный слой. Свои сервисы — события и брокер. Гибрид, который встречается чаще всего: внутри событийная архитектура, наружу к внешним системам — интеграционный слой.

С рынка ушли решения, на которых у многих всё и держалось: IBM Integration Bus, Oracle SOA Suite, ограничен доступ к MuleSoft и TIBCO. Обновлений нет, поддержки нет, а обмены работают, — типичная ситуация, с которой приходят.

Что есть сейчас. DATAREON ESB — в реестре российского ПО (запись №9907), с лицензией ФСТЭК. 1С:Шина и 1С:Интеграция КОРП — логичный выбор там, где ландшафт уже вокруг 1С. Также на рынке Factor-ESB, Entaxy ION, «Интегра», Compo ESB. Из открытых решений живут Apache Camel, WSO2 и Apache NiFi — лицензий не требуют, но требуют команды.

На что смотреть при выборе:

• Реестр отечественного ПО — обязателен для госкомпаний, объектов КИИ и закупок с этим требованием.
• Адаптеры под ваш парк — 1С, ваша учётная система, промышленные протоколы, устаревшие системы без API.
• Модель лицензирования — за поток, за подключения, за ядра; на объёмах разница существенная.
• Кто эксплуатирует — есть ли у вас люди на шину или нужна внешняя поддержка; в open source этот вопрос решается только своей командой.
• Стратегия миграции — старые обмены переносятся не одним движением, нужен период, когда работают и старые связи, и новые.

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

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

Шаг 1. Карта обменов. Все системы, все текущие обмены, форматы, расписания, объёмы и владельцы. Обычно на этом шаге и обнаруживается, что часть обменов дублируется, а часть работает «на честном слове» одного человека.

Шаг 2. Приоритет по боли. Выбрать один-два обмена, которые чаще всего ломаются или дороже всего стоят при сбое. Начинать с самого сложного или самого редкого — плохая идея.

Шаг 3. Каноническая модель ключевых сущностей. Договориться с бизнесом, что такое клиент, заказ, товар. Здесь же — вопрос единых идентификаторов и справочников.

Шаг 4. Первый поток целиком. Один обмен, доведённый до продакшена: адаптеры, преобразование, обработка ошибок, мониторинг, документация. Дальше он становится образцом.

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

Шаг 6. Эксплуатация. Дежурство, алерты, регламент разбора инцидентов, кто вносит изменения в маршруты. Без этого шага проект деградирует за полгода.

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

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

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

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

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

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

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