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

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

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

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

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

На этом этапе «АТИМО» обратились в KT.Team.

Им требовалась сервисная шина - программное обеспечение, которое гибко интегрирует разные системы.

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

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

Когда их количество выросло до 10, стало понятно, что шина абсолютно не устойчива к отказу.

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

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

Кроме того, для передачи информации в ESB 1.0 использовался брокер сообщений.

Шина пересылала данные от таксопарка в систему «АТИМО» и обратно как есть, никак их не обрабатывая.

Обмен был не всегда корректным, часть сообщения могла потеряться.

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

Такая архитектура будет более отказоустойчивой.

Чтобы передача данных стала более стабильной, лучше использовать внутреннее хранилище - собственные базы данных шины.

Шина будет получать данные от баз таксопарков и «АТИМО» и сохранять их у себя.

Так передача будет работать быстрее и стабильнее.

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

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

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

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

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

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

Обновление внедрили, и в «АТИМО» сразу заметили улучшение.

Шина работала без сбоев, запросов в техническую поддержку практически не было.

Решение получилось экономичным по потреблению памяти и при этом достаточно стабильным.

На первый взгляд всё было отлично: ESB 2.0 работала стабильно, к ней успешно подключали новые таксопарки.

Проблема была в том, что архитектура ESB осталась неправильной: один сервис последовательно опрашивал все 15 баз данных.

При этом система «АТИМО» продолжала расти, и было понятно, что рано или поздно шина снова начнёт сбоить.

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

Ключевая архитектурная проблема ESB 1.0 сохранилась и в ESB 2.0, поэтому шину пришлось снова дорабатывать.

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

Лучшее решение в подобной ситуации - обсудить с заказчиком реальные сроки разработки.

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

Команда KT.Team уже знала, что нужно изменить, поэтому не стала ждать запроса от «АТИМО» или сбоя ESB и переделала шину по своей инициативе.

В ESB 3.0 мы реализовали архитектуру, от которой отказались в предыдущей версии, - с отдельными сервисами для каждой базы данных.

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

Делайте правильную архитектуру: для каждого подключения свой сервис.

Такая шина устойчива к сбоям в отдельных базах данных.

Чтобы сервисы не тратили много ресурсов сервера, их сделали максимально простыми: убрали все лишние и ресурсоёмкие шаги, такие как логирование исключений.

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

Опрос одного таксопарка теперь требует около 300

Финальную версию сервисной шины выкатили незадолго до наступления 2023 года.

После этого KT.Team до конца января не получила ни одного запроса на оказание технической поддержки. А первый вопрос от «АТИМО» вообще не касался надёжности сервисной шины.

Дело в том, что в ESB 3.0 есть полезная фича: новую точку подключения для таксопарка можно создать простым клонированием из любой существующей.

Затем нужно задать несколько настроек, и ESB сможет получать нужные данные.

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

Команда KT.Team составила пошаговую инструкцию, чтобы сделать процесс понятнее.

Именно с ней был связан первый вопрос от «АТИМО» - описание одного из шагов оказалось не совсем понятным.

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

«АТИМО» успешно интегрирует новые таксопарки с ESB 3.0 без помощи KT.Team.

За первые 3,5 месяца 2023 года команда стартапа добавила 10 новых интеграций самостоятельно, используя документацию.

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

Ограниченные ресурсы сервера «АТИМО» используются экономно: на один запрос уходит всего 300

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

Чаще всего вопрос решается сам собой: таксопарк налаживает работу на своей стороне, и система «АТИМО» получает обновлённые данные. В этой истории команда KT.Team приобрела ценный опыт и отработала процесс внедрения ESB.

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

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