На связи Сергей Скирдин, технический директор ИТ-интегратора «Белый код». Недавно получил такой комментарий к одному из обзоров ESB: «Я считаю, что интеграционные платформы больше не нужны», а спустя время в Телеграм-сообществе «Шины не для машины» развернулась дискуссия на тему «Паттерн ESB безнадежно устарел». Решил собрать в одной статье популярные вопросы по теме и ответить на них.
Привожу самый первый комментарий, с которого все началось, в полном виде, орфография и пунктуация автора сохранены.
«Я считаю, что интеграционные платформы больше не нужны.
Положить в Кафку / получить из Кафки сообщение, я могу практически любой системой, включая 1С.
Разработка кастомных коннекторов понадобится любому крупному и сложному бизнесу, а другим такие платформы совсем не нужны.
В итоге:
Стоимость интеграции увеличивается.
Скорость интеграции увеличивается
А вендор, при всем уважении, продавая "мультитул", который позволяет все, подсаживает клиента на аутсорс по настройке своей платформы.
Закрытость кода, может привести к не интерпретируемым ошибкам в логах (как в Датареоне с кастомными коннекторами).
Возможно я не прав, но вы же не дадите демку. И документацию до покупки наверное тоже.
Один программист на GO быстро может организовать подключение к любой системе по любому протоколу, включая самые современные, а Кафка со своей отказоустойчивостью обеспечит гарантированную доставку сообщений».
Уже год я делаю обзоры на отечественные продукты, которые относятся к классу ESB: интеграционные шины, платформы и т. д. В реестре отечественного ПО таких решений больше 40. На деле тех, кто активно развивает и продвигает продукт, все же меньше. Я общаюсь с вендорами, прошу показать их разработку, а потом создаю обзор, который поможет тем, кто выбирает для своего проекта шину. Тема меня захватила так, что я даже создал Телеграм-сообщество «Шины не для машины».
При этом периодически в комментариях или даже на встречах с заказчиками звучат такие доводы, что, мол, для интеграций компании не нужна шина данных, будет достаточно брокера сообщений. Сегодня хочу встать на сторону тех продуктов, которые относятся к классу ESB. Возможно, для кого-то это будет звучать, как реклама отечественных шин данных, однако никаких названий давать не буду. Но как технический директор могу сказать, что изобретать велосипеды компаниям выходит гораздо накладнее. Ведь часто интеграцию можно настроить так, что управлять ею будет просто и удобно, а выйдет это даже дешевле, если сравнить затраты на кастомные разработки. Но обо всем по порядку.
Собрал самые популярные аргументы против ESB и подобных продуктов:
Зачем нужна шина данных, у нас есть RabbitMQ или Apache Kafka.
У нас своя самописная система, которая отлично работает.
Мы не уверены, что нам нужна шина, ведь закрытость кода может привести к непонятным ошибкам в логах.
ESB — устаревший паттерн.
Последовательно отвечу на каждый аргумент.
Зачем нужна шина данных, ведь есть RabbitMQ или Apache Kafka
Open source продукты, в отличие от проприетарных, всегда решают достаточно узкую задачу. Брокеры сообщений типа Kafka — хороший инструмент, чтобы передавать сообщения. Однако обычно у компаний стоит больше задач, которые они хотят решить с помощью интеграций. Преобразование данных, последовательность выполнения действий и т. д. Редко когда получается решить конечную задачу, используя один продукт. Обычно это целый набор: отдельно веб-сервер, отдельно брокер сообщений, отдельно система мониторинга и т. д. Все эти компоненты нужно изучить, протестировать, подружить между собой. Это как взять на разборке двигатель, навесное оборудование, проводку и мастерить автомобиль. Компоненты бесплатные, но нужна команда, чтобы все это грамотно собрать. Плюс есть риски багов, с которыми придется что-то делать. Безусловно, на open source можно собрать свою шину данных, большинство отечественных вендоров так и сделали, вопрос, сколько времени нужно потратить на сборку, тестирование. Вряд ли с первого раза получится хорошая система. Поэтому, даже если вам нравится какой-либо open source продукт (мне, например, нравится Apache NiFi), я все равно рекомендую обратиться к вендору, который умеет настраивать этот продукт, имеет компетенции по исправлению багов.
Вообще, тема «Брокеры VS ESB» достаточно глубокая, возможно, руки дойдут написать отдельную статью на эту тему.
У нас своя самописная система, которая отлично работает
Однажды мы попали на проект с самописной шиной на базе 1С. Стандартная история, надо было соединить несколько баз, сделали для этого отдельную базу, создали справочник информационных систем и пошло поехало. Тут опцию надо добавить, тут файлы надо гонять, тут еще что-то. Архитектуру решения особо не проектировали, требования не собирали, делается же для себя, если что подпилим. Потом наступил кадровый голод, допиливать некому, обратились к нам. Мы вдвоем с ведущим разработчиком два дня изучали эту систему. Задача вроде не сложная была, но чтобы понять, как оно работает, нужно потратить много времени.
Недавно в нашем сообществе, посвященном российским ESB, обсуждали самописные системы. Вот несколько комментариев от экспертов со стороны вендоров:
«Ни разу нормальных самописных клиентских шин не видел, потому что всегда идут от текущих потребностей, без оглядки на архитектуру и методологию, а с расширением функционала неизбежно утыкаются в архитектурные проблемы и начинают костылить»
«типичная ситуация: клиент выращивает шину у себя в контуре; потом её содержит в одно лицо; потом все страдают потому , что концов с концами не свести, устаёт это делать; и наконец выпиливает сие коллективное творчество и ставит нормальное коммерческое решение»
К сожалению, так это в большинстве случаев и работает: систему создает команда, которая может поменяться, тогда начинаются вопросы. Хотя они могут возникнуть и раньше, потому что поддерживать такой продукт довольно сложно. К тому же в компании, которая не специализируется на ИТ, ресурс на разработку выделить объективно сложнее. И в пересчете, так ли дорого выйдет решение от вендора?
Закрытость кода может привести к непонятным ошибкам в логах
Да, баги случаются, это нужно честно признать. Они не могут не случаться просто из-за маленького рынка и, как следствие, небольшого количества внедрений и малого количества обратной связи от потребителя к производителю. К слову, кроме ESB мы занимаемся разработкой аналитических витрин, в сегменте BI наблюдаю примерно ту же ситуацию.
Важно, как быстро вендор реагирует на баги, есть ли практика хотфиксов или нужно ждать следующий релиз для исправления.
ESB — устаревший паттерн
Недавно в нашем Телеграм-сообществе «Шины не для машины» обсуждали мнение, что ESB (паттерн Enterprise Service Bus) — это легаси, пережиток 2000-х, который не соответствует модным микросервисным подходам. Но если вникнуть в суть, сам паттерн ESB остается актуальным, просто сегодня он должен строиться иначе.
Где ESB все еще незаменим
Сложные интеграционные цепочки: если вам надо варить кашу из XML, JSON, SOAP, CSV, шифровать, подписывать и логировать по гостам — ESB сильнее самописных решений.
B2B-интеграции и регуляторы: когда диктуются протоколы и форматы, быстрее и дешевле обернуть интеграцию в ESB.
Легаси и коробки: если на одном конце интеграции старая инфраструктура или коробочные системы с неудобными API (читай: все учетные системы), удобнее и быстрее воспользоваться ESB, чем писать свое решение.
Почему впечатление о старении ESB ложное
Образ монолитной централизованной шины действительно устарел. Но сегодня ESB может работать как сеть легковесных модулей, запущенных в микросервисной среде.
Современные ESB-платформы ставят на self-service для команд, CI/CD, обзорность и стандарты, а не на централизованную фабрику интеграций.
Сам паттерн обмена, обработки и маршрутизации данных никуда не делся, он просто эволюционировал.
Вывод
Паттерн ESB не утратил своей актуальности, но, как и любой инструмент, требует грамотного применения и эволюции в соответствии с современными архитектурными подходами. Там, где интеграция сложна или стандарты диктуются извне, ESB по-прежнему остается эффективным выбором.
Приглашаю в сообщество «Шины не для машины», там обсуждаем насущные вопросы рынка ESB.
Комментарии (13)
foxsoft2005
01.07.2025 07:43Честно говоря, не совсем понял этот посыл про Open Source с этими всеми картинками про "open source автомобиль" и тд и тп.
Особенно, с учетом того, что рассматриваемая в исходном обзоре система (с которого, собственно, началось - https://habr.com/ru/companies/w_code/articles/896448/), базируется, собственно на том самом Open Source.
Или "это другое"? Т.е. когда комания сама пишет себе "нечто" на Open Source - это "криво и нестабильно", а если коммерческая компания продает свое, написанное с использованием Open Source - это уже "прямо и стабильно"?
vdudouyt
01.07.2025 07:43Так и не увидел разгрома вот этого тезиса:
А вендор, при всем уважении, продавая "мультитул", который позволяет все, подсаживает клиента на аутсорс по настройке своей платформы.
И, видимо, и не увижу.
blacksan
01.07.2025 07:43Гладко было на бумаге, да вот только зачастую нет альтернативе шине или чему-то мидлварному вроде нее. В больших компаниях, ну например банках, оч много АБС которые в силу разных причин проще связать с другой такой неповоротливой АБС, шиной, нежели вкручивать в эти АБС коннекторы к кафке. Ну например, АБС поставляет вендор для которого компания оплачивает N доработок в месяц за K рублей, и на квартал вендору поставлены уже более приоритетные задачи, а расширять договор - не бюджет и вообще долго и сложно. А еще, стоимость этих доработок у вендора, как правило: оверпрайс. А еще, иногда нужно синтегрироваться с системой на которой работают 2-3 человека которые не в ресурсе затащить коннектор в проект, но сваять вызов апи на корп шине коробочными средствами - вполне. В общем, жизнь - она сильно сложнее, чем слабая, маркетинговая статья на хабре.
coder1cv8
01.07.2025 07:43Я как "шинник" могу сказать про ESB ПО следующее: суть шины в централизации. Вместо того чтобы размазывать интеграционный код ровным слоем по всем языкам и платформам, которые имеются в более-менее крупной компании, мы стремимся централизовать его. Понятно, для того чтобы извлекать стандартные плюсы централизации: гибкость к изменениям, шире возможности в оперировании (при расследованнии инцидентов в передаче данных), ниже стоимость, выше скорость разработки. Понятно, что на 100% этой цели достичь невозможно, все-равно останутся какие-то "хвосты" в каких-то системах. Но даже приближение дает огромное преимущество над ситуацией когда выгрузки-загрузки написаны непонятно кем, на чем и кто в лес, кто по дрова ("лоскутная интеграция").
Очевидно, что если кто-то использует "Кафка" и "гарантированная доставка" в одном предложении - он не совсем в теме. Кафка вообще не про гарантированную доставку. Представим, что мы выгружаем какие-то документы в 1С через Кафку. Что произойдет если при загрузке части документов случится конфликт блокировок (потому что база сильно нагружена в текущий момент). Ничего хорошего. Сообщения прочитаны, офсет сдвинут - до свидания. Что произойдет на шине:
залогируются сообщение в 1С и ответ 1С для анализа проблемы
полетят алерты отвественным сотрудникам
без вмешательства человека шина попытается доставить эти документы позднее (в соответствие с настроенной политикой: увеличивающиеся интервалы, до истечения времени жизни сообщения/кол-ва попыток и т.д.)
И это не требует ни строчки кода в 1С! Так как шина использует коннектор к OData 1С (всю интеграционную логику мы уже централизовали).
К тому же, современная ESB - это идеальная платформа для "корпоративного API": она уже имеет доступ ко всем данным всех систем нашего ИТ ландшафта, имеет кластеризацию "из коробки", широкие инструменты настройки и контроля доступа к данным, спецификации, документацию, API разворачивается "по нажатию одной кнопки" и т.д. Если, конечно, это "правильно приготовленная" ESB.
Вот то что этот паттерн недооценен и многие просто даже не думают о том чтобы решать вопросы интеграции приложений стратегически - это да...
scarab
01.07.2025 07:43Ничего не имею против шин, но что касается 1С и кафки: а что мешает выключить автокоммит и не сдвигать оффсет, пока 1С внутри себя точно не прожуёт очередной документ?
Vamp
01.07.2025 07:43Потому что один застрявший документ остановит весь поток. Это нормально сработает только если 1С не принимает документ из-за каких-либо временных проблем: перегружена база, сеть барахлит и т.п. А если проблема перманентная, например, невалидный с точки зрения 1С документ, то на этом документе весь поток и встанет. А ретрай механизмов у кафки нет, что вынуждает городить костыли.
scarab
01.07.2025 07:43Так это касается не только 1С, а вообще любого консьюмера. Если в архитектуре используется кафка - то изначально предполагается, что сервисы умеют сами разбираться со своими проблемами. Не прочитал - никуда информация не денется, прочитал и кинул коммит - сам разбирайся, что с этим делать.
В ActiveMQ или в кролике есть встроенные механизмы DLQ, но и свои проблемы тоже есть.
Vamp
01.07.2025 07:43Так это касается не только 1С, а вообще любого консьюмера.
Вопрос был в контексте 1С, и я подумал, что ответ в этом же контексте будет смотреться органичнее. Но вы верно подметили - ответ применим не только к 1С.
Если в архитектуре используется кафка - то изначально предполагается, что сервисы умеют сами разбираться со своими проблемами.
Сервис не может предусмотреть все возможные проблемы. И не важно, кафка там у него или нет. Поэтому ошибки делятся на два типа - которые мы знаем как обработать и все остальные. С первым типом всё понятно, а вот со вторым уже не очень.
Допустим, встретилась ошибка сети. Очевидно, что коммитить оффсет нет смысла, так как все последующие сообщения так же упадут с этой же ошибкой и лучше ретраить текущее сообщение до победного, либо до изменения ошибки на какую-то другую.
А если возникла ошибка, которую никто никогда не видел? Можем ли мы блокировать чтение топика, отправив сообщение в "ретрай до победного"?
Типичным вариантом обработки всех подобных неизвестных ошибок является изъятие проблемного сообщения из топика и отправка его в отдельную независимую ретрай схему с увеличивающимся интервалом между попытками. И в системах на кафке такая схема делается либо очень сложно, либо с привлечением сторонних инструментов.
ruslan_sverchkov
01.07.2025 07:43И в системах на кафке такая схема делается либо очень сложно
В чем конкретно сложность и что такого фундаментально другого в этом плане могут другие инструменты предложить? Вот экспоненциальный бэкофф в кафке действительно неудобно делать)
coder1cv8
01.07.2025 07:43Да, спасибо! Гарантированная доставка так или иначе крутится вокруг ретраев. Поэтому Кафка, хороший, там где это уместно, инструмент - не про гарантированную доставку.
Я, на самом деле, на шине использую аналогичный Кафке алгоритм, только вместо офсета - ID обработанных сообщений (с привязкой к консьюмеру). Что позволяет, спокойно пропускать "проблемные" сообщения и возвращаться к ним позднее. Это не годится только для потоков данных где критична последовательность сообщений в рамках топика. На практике, такое бывает крайне редко. В этом случае, просто тормозим поток до ручного разбора инцидента.
Kitta
01.07.2025 07:43Честно говоря, кажется тема как-то не до конца раскрыта и хотелось бы чуть более развернутой аргументации.
Open source компоненты надо изучать, тестировать и командой поддерживать, а ESB-продукты почему-то не надо? Почему - не понятно.
Самописная шина, которую писали для конкретной организации, обычно криво написана, а вот, получается, ESB все пишутся сразу прямо и для любой организации сразу подходят. Кажется, что это не всегда так и все равно придется многое докручивать и ещё в довесок будет куча ненужного функционала.
ESB шаблон не устаревший, но реализуется теперь как набор self-hosted легковесных модулей. Чем это отличается от набора open source компонент поднятых как цепочка микросервисов не очень понятно.
Или здесь имеются ввиду какие-то вполне конкретные ESB продукты и для понимания аргументации следует сначала с ними познакомиться?
panzerfaust
Я последний раз работал с кондовой ESB на Apache Camel в 2018 году. Типичная "интеграция" там выглядела так: система А хочет общаться с системой Б, поэтому давайте запилим адаптер на шине. И 9 разрабов пилили эти адаптеры и изображали из себя очень важных спецов.
А единственный резон существования шины был в том, что системы А и Б - это проприетарные закрытые серые ящики, которые невозможно по-человечески дорабатывать. То есть шина это просто костыль.
Потом костыли перестали быть актуальными не потому, что он не модные, а потому что хромота прошла - написали свое вместо серых ящиков.
Wicort
Это очень круто, когда у вас есть система А и система Б, которые нужно подружить. Тут даже как костыль шина не нужна - проще написать свой маленький адаптер, который свяжет эти две системы. А если этих систем у вас целый алфавит от разных вендоров? Да еще и двух/трехбуквенные сочетания используются! Тут явно не одна команда должна заниматься интеграцией всего со всем. А ведь каждая команда пишет как умеет - кто-то сделал на Go, кто-то написал на Java. А кому-то вообще было нечем заняться и он решил запилить всё на Ассемблере, производительность же... Написал и уволился, так как стало скучно. Как потом всё это поддерживать? Как разобраться в этом зоопарке? На мой взгляд, именно эти задачи в первую очередь решает корпоративная шина - единообразие и стандартизация при создании интеграционных решений.