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

путь ошибок и инсайтов от ИТ-интегратора

11.5.2023

Содержание

  • Немного контекста
  • Первая ошибка: построить архитектуру шины по аналогии с прямой интеграцией
  • Вторая ошибка: бороться с симптомами, а не решать главную проблему
  • Финальная ESB: надёжная, стабильная и быстрая
  • Что получилось в итоге

Статья опубликована в журнале IT-world

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

Другие статьи

Смотреть все

От «спагетти» до гибкой архитектуры за 5 шагов: этапы внедрения ESB-слоя

Подробнее

Impact Mapping, юнит-экономика и PDCA: грамотное управление разработкой e-Commerce

Подробнее

Смена платформы и омниканальность: кейс Accent Group по апгрейду интернет-магазина

Подробнее

Смотреть все

Мы используем файлы cookie, чтобы предоставить наилучшие возможности сайта

Ок

Ваша заявка отправлена успешно

Отправить снова

Давайте обсудим ваш проект

С вами свяжутся персональные менеджеры

Форма для связи

Что-то пошло не так! Пожалуйста, попробуйте еще раз.
Ваша заявка отправлена успешно!

Отправить снова

Что-то пошло не так! Пожалуйста, попробуйте еще раз.

Контакты

+7 917 125-96-34

Whats App:

@kt_team_it

Telegram:

+7 495 204-14-33

Телефон:

Назначить встречу

Забронировать время встречи с помощью Google Calendar