# Как правильно внедрить ESB: лучшие практики и рекомендации

Canonical: https://www.kt-team.ru/blog/how-to-properly-implement-an-esb

Source: https://www.kt-team.ru/blog/how-to-properly-implement-an-esb

Canonical URL: https://www.kt-team.ru/blog/how-to-properly-implement-an-esb

Original URI: /blog/how-to-properly-implement-an-esb

## SEO / GEO Metadata

- Title: Как правильно внедрить ESB: лучшие практики и рекомендации
- Description: С чего начать и как правильно внедрить Enterprise Service Bus (ESB): архитектурные подходы, этапы внедрения, типовые ошибки и советы по интеграции
- Canonical: https://www.kt-team.ru/blog/how-to-properly-implement-an-esb
- Robots: not specified
- Open Graph tags: 4
- Twitter tags: 4
- JSON-LD blocks: 2

## Layout Blocks

<!-- blockType: navigation; selector: div -->

### ИИ / AI

AI решения инструменты кейсы карьера +7 (495) 204-14-33 Стать клиентом

---

<!-- blockType: hero; selector: div -->

### Как правильно внедрить ESB-слой с первой попытки

Как правильно внедрить ESB-слой с первой попытки путь ошибок и инсайтов от ИТ-интегратора 11.5.2023 Немного контекста Первая ошибка: построить архитектуру шины по аналогии с прямой интеграцией Вторая ошибка: бороться с симптомами, а не решать главную проблему Финальная ESB : надёжная, стабильная и быстрая Что получилось в итоге ‍ Статья опубликована в журнале IT-world Время на прочтение: 7 мин. Внедрение сервисной шины предприятия ( ESB , сокр. от англ. enterprise service bus) — непростая задача даже для интеграторов, которые развёртывали десятки похожих решений. Нужно определить, какая архитектура подойдёт в конкретном проекте, найти эффективный способ передачи данных, понять, как лучше реализовать сервисы внутри шины. В 2022 году команда KT.Team на собственном опыте убедилась: если не следовать процессам и не задавать себе и заказчику правильные вопросы на этапе аналитики, даже понятные интеграции можно сделать неправильно. Мы быстро запустили первую версию шины для стартапа, а затем дважды её переделывали. Рассказываем, почему так случилось, чему мы научились и как не повторять наши ошибки. Немного контекста В прошлом году KT.Team внедрила сервисную шину для стартапа «АТИМО», который создал приложение для автоматического получения путевых листов для водителей. «АТИМО» работает с таксопарками и автопарками, которые не хотят держать в штате механика и медика. Такие компании пользуются автоматизированными пунктами проверки технического состояния машин и здоровья водителей. В этих пунктах технический специалист и врач проводят осмотры и загружают результаты в систему «АТИМО» для обработки. Таксопарк отправляет в «АТИМО» информацию о водителях и машинах, а в ответ получает готовый путевой лист в приложении. Пока таксопарков было только два, каждый из них подключался к системе напрямую, но будущее масштабирование заставило «АТИМО» задуматься об изменении архитектуры своего IT-решения. На этом этапе «АТИМО» обратились в KT.Team. Им требовалась сервисная шина — программное обеспечение, которое гибко интегрирует разные системы. Шина должна была взять на себя обмен данными между таксопарком, пунктами технического и медицинского осмотра и базами «АТИМО», не перегружая сервер. Первая ошибка: построить архитектуру шины по аналогии с прямой интеграцией Что сделали Архитектуру шины выстроили по аналогии с прямым подключением: создали сервис, который каждые 20 минут запрашивал данные у каждой базы по очереди. Так делать не надо: архитектура с одним сервисом на все подключения У такой архитектуры был большой плюс — она требовала почти в 10 раз меньше ресурсов сервера. Если при прямом подключении каждый запрос «съедал» до 4 Гб памяти, то в версии ESB 1.0 на один запрос уходило около 500 Мб. Пришлем вам необходимые материалы или КП Напишите нам: clients@kt.team Ответим в течение 30 минут! В чём ошибка На старте внедрения к шине нужно было подключить только два таксопарка, поэтому команда KT.Team решила пойти по достаточно простому пути. ESB 1.0 проработала полгода, в течение которых к системе «АТИМО» начали подключать новые таксопарки. Когда их количество выросло до 10, стало понятно, что шина абсолютно не устойчива к отказу. Причиной проблем была изначально неверная архитектура шины: чем больше баз к ней подключено, тем выше риск сбоя. Опрос баз данных проходил последовательно, и если одна не отвечала или обрывала соединение, шина переставала работать, т. е. если сбой произошёл при подключении к самому первому таксопарку, все остальные таксопарки тоже оставались без путевых листов. Кроме того, для передачи информации в ESB 1.0 использовался брокер сообщений. Шина пересылала данные от таксопарка в систему «АТИМО» и обратно как есть, никак их не обрабатывая. Обмен был не всегда корректным, часть сообщения могла потеряться. Как надо было сделать Использование отдельных сервисов для каждого подключения сделает архитектуру менее связанной: сбой одной базы не повлияет на обмен данными с другими. Такая архитектура будет более отказоустойчивой. Чтобы передача данных стала более стабильной, лучше использовать внутреннее хранилище — собственные базы данных шины. Шина будет получать данные от баз таксопарков и «АТИМО» и сохранять их у себя. Так передача будет работать быстрее и стабильнее. Вторая ошибка: бороться с симптомами, а не решать главную проблему Что сделали Команда KT.Team планировала использовать в ESB 2.0 несколько сервисов для сбора данных вместо одного и две внутренние базы данных вместо брокера сообщений. В итоге реализовали промежуточное решение: оставили один сервис для всех таксопарков, но полностью поменяли логику обмена данными. Брокер сообщений заменили на базы данных: одна — для информации о машинах и водителях, другая — для готовых путевых листов. И уже из этих баз шина передавала данные по запросу в систему «АТИМО» или таксопарку. Такое решение приняли по двум причинам. Во-первых, новая версия шины требовала больше ресурсов, ведь все таксопарки нужно обрабатывать одновременно, а не по очереди. Во-вторых, приоритетом заказчика было быстрое внедрение изменений, а на полную переработку архитектуры понадобилось бы какое-то время. Дополнительно «АТИМО» попросили сделать опрос таксопарков более частым — с загрузкой новых данных каждую минуту. Это требование проектная команда также выполнила: технически шина может работать даже быстрее. Правда, с такой скоростью не справлялись уже базы данных таксопарков. Для одной особенно медленной базы пришлось искусственно ограничить число запросов, т. к. ежеминутные подключения она воспринимала как DDoS-атаку — и блокировала шину. Обновление внедрили, и в «АТИМО» сразу заметили улучшение. Шина работала без сбоев, запросов в техническую поддержку практически не было. Решение получилось экономичным по потреблению памяти и при этом достаточно стабильным. В чём ошибка На первый взгляд всё было отлично: ESB 2.0 работала стабильно, к ней успешно подключали новые таксопарки. Примерно через месяц их было уже 15. Проблема была в том, что архитектура ESB осталась неправильной: один сервис последовательно опрашивал все 15 баз данных. При этом система «АТИМО» продолжала расти, и было понятно, что рано или поздно шина снова начнёт сбоить. Ошибка этой версии заключалась в том, что проектная команда сфокусировалась на экономии ресурсов сервера и сокращении времени разработки. Ключевая архитектурная проблема ESB 1.0 сохранилась и в ESB 2.0, поэтому шину пришлось снова дорабатывать. Как надо было сделать Чтобы ESB была действительно отказоустойчивой, нужно реализовать правильную архитектуру. Лучшее решение в подобной ситуации — обсудить с заказчиком реальные сроки разработки. Полное обновление требует времени, но при этом позволяет получить масштабируемую и надёжную шину данных. Команда KT.Team уже знала, что нужно изменить, поэтому не стала ждать запроса от «АТИМО» или сбоя ESB и переделала шину по своей инициативе. Финальная ESB: надёжная, стабильная и быстрая Что сделали В ESB 3.0 мы реализовали архитектуру, от которой отказались в предыдущей версии, — с отдельными сервисами для каждой базы данных. Все сервисы работают одинаково: подключаются к базе данных таксопарка; скачивают из неё данные; приводят их к формату, который использует система «АТИМО» (для этого настроили правила маппинга); записывают новые данные в хранилище; удаляют неактуальные данные. Делайте правильную архитектуру: для каждого подключения свой сервис. Такая шина устойчива к сбоям в отдельных базах данных Чтобы сервисы не тратили много ресурсов сервера, их сделали максимально простыми: убрали все лишние и ресурсоёмкие шаги, такие как логирование исключений. Вместо этого данные в хранилище перезаписываются при каждом успешном подключении к базе таксопарка. Опрос одного таксопарка теперь требует около 300 Мб памяти (вместо 4 Гб на старте проекта). Финальную версию сервисной шины выкатили незадолго до наступления 2023 года. После этого KT.Team до конца января не получила ни одного запроса на оказание технической поддержки. А первый вопрос от «АТИМО» вообще не касался надёжности сервисной шины. Дело в том, что в ESB 3.0 есть полезная фича: новую точку подключения для таксопарка можно создать простым клонированием из любой существующей. Затем нужно задать несколько настроек, и ESB сможет получать нужные данные. Это решение сделало шину масштабируемой — «АТИМО» не нужно обращаться в техподдержку, чтобы добавить таксопарк. Команда KT.Team составила пошаговую инструкцию, чтобы сделать процесс понятнее. Именно с ней был связан первый вопрос от «АТИМО» — описание одного из шагов оказалось не совсем понятным. На вопрос ответили, текст подправили, и теперь добавление нового таксопарка занимает всего пару часов вместо нескольких дней, как было раньше. Что получилось в итоге «АТИМО» успешно интегрирует новые таксопарки с ESB 3.0 без помощи KT.Team. За первые 3,5 месяца 2023 года команда стартапа добавила 10 новых интеграций самостоятельно, используя документацию. Сейчас в системе уже 20 таксопарков, а баз данных, из которых шина забирает информацию о водителях и машинах, вдвое больше. Ограниченные ресурсы сервера «АТИМО» используются экономно: на один запрос уходит всего 300 Мб памяти вместо 4 Гб при прямом подключении. Сократить потребление удалось благодаря очень простой схеме сервиса, который опрашивает базу данных таксопарка. В чате техподдержки тихо: шина выполняет свои функции, а редкие вопросы связаны с небольшими локальными сбоями на стороне отдельных баз данных. Чаще всего вопрос решается сам собой: таксопарк налаживает работу на своей стороне, и система «АТИМО» получает обновлённые данные. В этой истории команда KT.Team приобрела ценный опыт и отработала процесс внедрения ESB . Важно сразу учесть и будущий рост, и возможные точки отказа в системе, проводя внедрение правильно. Поэтому лучше всего подобную шину реализовать через отдельные сервисы для каждого подключения, даже если пока их всего два. Пришлем вам необходимые материалы или КП Напишите нам: clients@kt.team Ответим в течение 30 минут! Оглавление Немного контекста Первая ошибка: построить архитектуру шины по аналогии с прямой интеграцией Вторая ошибка: бороться с симптомами, а не решать главную проблему Финальная ESB: надёжная, стабильная и быстрая Что получилось в итоге Другие статьи Смотреть все ESB и конкуренты: выбираем правильное интеграционное решение для вашего проекта 21/11/2024 Подробнее Автоматизация документооборота: выбор СЭД, ключевые преимущества, ROI и кейсы внедрения 12/11/2025 Подробнее 10 функций B2B-портала для дистрибьюторов, которые экономят время, снижают ошибки и повышают оборот 28/10/2025 Подробнее Мы используем файлы cookie, чтобы предоставить наилучшие возможности сайта Ок Давайте обсудим ваш проект С вами свяжутся персональные менеджеры clients@kt.team Email: @kt_team_it Telegram: О нас Услуги Кейсы Блог Карьера Основы ценообразования Бизнес-стажировка Отзывы PIM/MDM-системы ESB-интеграции DevOps Low-code Микросервисы B2B-порталы и e-commerce PWA Magento Калькулятор проекта Unit-экономика © 2026 ООО «КТ Групп» ООО «КОМПЛИЦЕРТЕ ТЕХ» Komplizierte Technologien, GmbH Россия Тольятти, ул. 40 лет Победы, 41 Москва, Романов переулок, 2с1, пространство Noodome clients@kt.team +7 (495) 204-14-33 Положение о работе с персональными данными →

![Как правильно внедрить ESB-слой с первой попытки](/assets/original/kak-pravilno-vnedrit-esb-sloj-s-pervoj-popytki-ebe4a8d9fb.avif)
![image](/assets/original/6847c6ccde444378c5d5c0f667610d000a25c97a4d67cd6eesb-d315b1e874.avif)

---

<!-- blockType: footer; selector: footer -->

О нас Услуги Кейсы Блог Карьера Основы ценообразования Бизнес-стажировка Отзывы PIM/MDM-системы ESB-интеграции DevOps Low-code Микросервисы B2B-порталы и e-commerce PWA Magento Калькулятор проекта Unit-экономика © 2026 ООО «КТ Групп» ООО «КОМПЛИЦЕРТЕ ТЕХ» Komplizierte Technologien, GmbH Россия Тольятти, ул. 40 лет Победы, 41 Москва, Романов переулок, 2с1, пространство Noodome clients@kt.team +7 (495) 204-14-33 Положение о работе с персональными данными →
