Нужно определить, какая архитектура подойдет в конкретном проекте, найти эффективный способ передачи данных, понять, как лучше реализовать сервисы внутри шины.
В 2022 году наша команда на собственном опыте убедилась: если не следовать процессам и не задавать себе и заказчику правильные вопросы на этапе аналитики, даже понятные интеграции можно сделать неправильно. Мы быстро запустили первую версию шины для стартапа, а затем дважды её переделывали. Рассказываем, почему так случилось, чему мы научились и как не повторять наши ошибки.
Немного контекста
В прошлом году наша компания внедрила сервисную шину для стартапа «АТИМО», который создал приложение для автоматического получения путевых листов для водителей. «АТИМО» работает с таксопарками и автопарками, которые не хотят держать в штате механика и медика. Такие компании пользуются автоматизированными пунктами проверки технического состояния машин и здоровья водителей: технический специалист и врач проводят в них осмотры и загружают результаты в систему «АТИМО» для обработки. Таксопарк отправляет в «АТИМО» информацию о водителях и машинах, а в ответ получает готовый путевой лист в приложении.
Пока таксопарков было только два, каждый из них подключался к системе напрямую, но будущее масштабирование заставило «АТИМО» задуматься об изменении архитектуры своего IT-решения. Им требовалась сервисная шина — программное обеспечение, которое гибко интегрирует разные системы. Шина должна была взять на себя обмен данными между таксопарком, пунктами технического и медицинского осмотра и базами «АТИМО», не перегружая сервер.
Первая ошибка: построить архитектуру шины по аналогии с прямой интеграцией
Что сделали?
Архитектуру шины выстроили по аналогии с прямым подключением: создали сервис, который каждые 20 минут запрашивал данные у каждой базы по очереди.
Так делать не надо: архитектура с одним сервисом на все подключения
У такой архитектуры был большой плюс — она требовала почти в 10 раз меньше ресурсов сервера. Если при прямом подключении каждый запрос съедал до 4 Гб памяти, то в версии ESB 1.0 – около 500 Мб.
В чем ошибка?
На старте внедрения к шине нужно было подключить только два таксопарка, поэтому было решено пойти по простому пути. ESB 1.0 проработала полгода, в течение которых к системе «АТИМО» начали подключать новые таксопарки. Когда их количество выросло до 10, стало понятно, что шина абсолютно неустойчива к отказу.
Сотрудники АТИМО постоянно обращались за помощью к KT.Team
Причиной проблем была изначально неверная архитектура шины: чем больше баз к ней подключено, тем выше риск сбоя. Опрос баз данных проходил последовательно, и если одна не отвечала или обрывала соединение, шина переставала работать. То есть, если сбой произошел при подключении к самому первому таксопарку, все остальные таксопарки тоже оставались без путевых листов.
Кроме того, для передачи информации в ESB 1.0 использовался брокер сообщений. Шина пересылала данные от таксопарка в систему «АТИМО» и обратно как есть, никак их не обрабатывая. Обмен был не всегда корректным, часть сообщения могла потеряться.
Как надо было сделать?
Использование отдельных сервисов для каждого подключения сделает архитектуру менее связанной: сбой одной базы не повлияет на обмен данными с другими. Такая архитектура будет более отказоустойчивой.
Чтобы передача данных стала более стабильной, лучше использовать внутреннее хранилище — собственные базы данных шины. Шина будет получать данные от баз таксопарков и «АТИМО» и сохранять их у себя. Так передача будет работать не только стабильнее, но и быстрее.
Вторая ошибка: бороться с симптомами, а не решать главную проблему
Что сделали?
Наша команда планировала использовать в ESB 2.0 несколько сервисов для сбора данных вместо одного и две внутренние базы данных вместо брокера сообщений. В итоге реализовали промежуточное решение: оставили один сервис для всех таксопарков, но полностью поменяли логику обмена данными. Брокер сообщений заменили на базы данных: одна — для информации о машинах и водителях, другая — для готовых путевых листов. И уже из этих баз шина передавала данные по запросу в систему «АТИМО» или таксопарку.
Такое решение приняли по двум причинам. Во-первых, новая версия шины требовала больше ресурсов, ведь все таксопарки нужно обрабатывать одновременно, а не по очереди. Во-вторых, приоритетом заказчика было быстрое внедрение изменений, а на полную переработку архитектуры понадобилось бы какое-то время.
Дополнительно «АТИМО» попросили сделать опросы таксопарков более частыми — с загрузкой новых данных каждую минуту. Это пожелание проектная команда также выполнила: технически шина может работать даже быстрее. Правда, с такой скоростью не справлялись уже базы данных таксопарков. Для одной особенно медленной базы пришлось даже искусственно ограничить число запросов, поскольку ежеминутные подключения она воспринимала как DDoS-атаку и блокировала шину.
Обновление внедрили, и в «АТИМО» сразу заметили улучшение. Шина работала без сбоев, запросов в техническую поддержку практически не было. Решение получилось экономичным по потреблению памяти и при этом достаточно стабильным.
В чем ошибка?
На первый взгляд, всё было отлично: ESB 2.0 работала стабильно, к ней успешно подключали новые таксопарки. Примерно через месяц их было уже 15.
Проблема была в том, что архитектура ESB осталась неправильной: один сервис последовательно опрашивал все 15 баз данных. При этом система «АТИМО» продолжала расти, и было понятно, что рано или поздно шина снова начнет сбоить.
Ошибка этой версии заключалась в том, что проектная команда сфокусировалась на экономии ресурсов сервера и сокращении времени разработки. Ключевая архитектурная проблема ESB 1.0 сохранилась и в ESB 2.0, поэтому шину пришлось снова дорабатывать.
Как надо было сделать?
Чтобы ESB была действительно отказоустойчивой, нужно реализовать правильную архитектуру. Лучшее решение в подобной ситуации — обсудить с заказчиком реальные сроки разработки. Полное обновление требует времени, но при этом позволяет получить масштабируемую и надежную шину данных.
Мы уже знали, что нужно изменить, поэтому не стали ждать запроса от «АТИМО» или сбоя ESB и переделали шину по своей инициативе.
Финальная ESB: надежная, стабильная, быстрая
Что сделали?
В ESB 3.0 мы реализовали архитектуру, от которой отказались в предыдущей версии, — с отдельными сервисами для каждой базы данных. Все сервисы работают одинаково:
подключаются к базе данных таксопарка;
скачивают из нее данные;
приводят их к формату, который использует система «АТИМО» (для этого настроили правила маппинга);
записывают новые данные в хранилище;
удаляют неактуальные данные.
Делайте правильную архитектуру: для каждого подключения свой сервис. Такая шина устойчива к сбоям в отдельных базах данных
Чтобы сервисы не тратили много ресурсов сервера, их максимально упростили: убрали все лишние и ресурсоемкие шаги, такие как логирование исключений. Вместо этого данные в хранилище перезаписываются при каждом успешном подключении к базе таксопарка. Опрос одного таксопарка теперь требует около 300 Мб памяти – вместо 4 Гб на старте проекта.
Финальную версию сервисной шины выкатили незадолго до наступления 2023 года. После этого до конца января мы не получили ни одного запроса на оказание технической поддержки. А первый вопрос от «АТИМО» вообще не касался надежности сервисной шины.
Дело в том, что в ESB 3.0 есть полезная фича: новую точку подключения для таксопарка можно создать простым клонированием из любой существующей. Затем нужно задать несколько настроек, и ESB сможет получать нужные данные. Это решение сделало шину масштабируемой — «АТИМО» не нужно обращаться в техподдержку, чтобы добавить таксопарк.
Компания составила пошаговую инструкцию, чтобы сделать процесс понятнее. Именно с ней был связан первый вопрос от «АТИМО» — описание одного из шагов оказалось не совсем понятным. На вопрос ответили, текст подправили, и теперь добавление нового таксопарка занимает всего пару часов вместо нескольких дней, как было раньше.
Что получилось в итоге?
«АТИМО» успешно интегрирует новые таксопарки с ESB 3.0 без помощи KT.Team. За первые 3,5 месяца 2023 года команда стартапа добавила 10 новых интеграций самостоятельно, используя документацию. Сейчас в системе уже 20 таксопарков, а баз данных, из которых шина забирает информацию о водителях и машинах, вдвое больше.
Ограниченные ресурсы сервера «АТИМО» используются экономно: на один запрос уходит всего 300 Мб памяти вместо 4 Гб при прямом подключении. Сократить потребление удалось благодаря очень простой схеме сервиса, который опрашивает базу данных таксопарка.
В чате техподдержки тихо: шина выполняет свои функции, а редкие вопросы связаны с небольшими локальными сбоями на стороне отдельных баз данных. Чаще всего ситуация решается сама собой: таксопарк налаживает работу на своей стороне и система «АТИМО» получает обновленные данные.
* * *
В этой истории наша команда приобрела ценный опыт и отработала процесс внедрения ESB. Важно сразу учесть и будущий рост, и возможные точки отказа в системе, проводя внедрение правильно. Поэтому лучше всего подобную шину реализовать через отдельные сервисы для каждого подключения, даже если пока их всего два.