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

Внедрение сервисной шины предприятия (ESB, сокр. от англ. enterprise service bus) — непростая задача даже для интеграторов, которые развёртывали десятки похожих решений. Нужно определить, какая архитектура подойдёт в конкретном проекте, найти эффективный способ передачи данных, понять, как лучше реализовать сервисы внутри шины.

В 2022 году команда KT.Team на собственном опыте убедилась: если не следовать процессам  и не задавать себе и заказчику правильные вопросы на этапе аналитики, даже понятные интеграции можно сделать неправильно. Мы быстро запустили первую версию шины для стартапа, а затем дважды её переделывали. Рассказываем, почему так случилось, чему мы научились и как не повторять наши ошибки.

Немного контекста

В прошлом году KT.Team внедрила сервисную шину для стартапа «АТИМО», который создал приложение для автоматического получения путевых листов для водителей.

«АТИМО» работает с таксопарками и автопарками, которые не хотят держать в штате механика и медика. Такие компании пользуются автоматизированными пунктами проверки технического состояния машин и здоровья водителей. В этих пунктах технический специалист и врач проводят осмотры и загружают результаты в систему «АТИМО» для обработки. Таксопарк отправляет в «АТИМО» информацию о водителях и машинах, а в ответ получает готовый путевой лист в приложении.

Пока таксопарков было только два, каждый из них подключался к системе напрямую, но будущее масштабирование заставило «АТИМО» задуматься об изменении архитектуры своего IT-решения.

На этом этапе «АТИМО» обратились в KT.Team. Им требовалась сервисная шина — программное обеспечение, которое гибко интегрирует разные системы. Шина должна была взять на себя обмен данными между таксопарком, пунктами технического и медицинского осмотра и базами «АТИМО», не перегружая сервер.

Первая ошибка: построить архитектуру шины по аналогии с прямой интеграцией

Что сделали

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

У такой архитектуры был большой плюс — она требовала почти в 10 раз меньше ресурсов сервера. Если при прямом подключении каждый запрос «съедал» до 4 Гб памяти, то в версии ESB 1.0 на один запрос уходило около 500 Мб.

В чём ошибка

На старте внедрения к шине нужно было подключить только два таксопарка, поэтому команда 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. Важно сразу учесть и будущий рост, и возможные точки отказа в системе, проводя внедрение правильно. Поэтому лучше всего подобную шину реализовать через отдельные сервисы для каждого подключения, даже если пока их всего два.

‍