Уже поменяли шину? Наш опыт «переобувания» и разработки интеграционной платформы
Хабр, привет! На связи Дмитрий Бадулин, я занимаюсь разработкой ПО в компании К2Тех.
Корпоративная сервисная шина, или как это по-другому называется, интеграционная платформа — это отдельная боль для множества компаний. И сегодня в условиях, когда некоторые middleware-решения класса ESB перестали нормально работать в России, возникает новая волна спроса на проектирование системы обмена данными между множеством ИС. В их числе, разумеется, есть как красивые и удобные, которые легко интегрировать, так и кошмар интегратора, которые никак не хотят нормально работать.
В этой статье я расскажу о том, почему нам все-таки пришлось создавать нашу собственную корпоративную шину, как мы ее делали, а также поделюсь примерами ее использования.
Давайте возьмем шину у соседа
Мы в К2Тех, конечно, не мазохисты. И изготавливать заново велосипед из древесины голыми руками не хотели. Поэтому мы сначала решили выбрать одну из разработок, которые по-прежнему можно использовать в России. Но на первых же проектах столкнулись с тем, что имеющиеся продукты не позволяют красиво решить задачи, стоящие перед заказчиками.
Сначала хотели использовать одну из наиболее популярных шин из представленных на рынке. Хотелось взять добротный проект, который хорошо интегрируется с целым рядом ИС. Однако на практике мы столкнулись с двумя сложностями. Одному из заказчиков нужна была возможность посылать алерты не только на email, но и в Telegram (особенно на первых этапах реализации проекта, когда нужно четко следить за всем, что происходит на ESB).
Другой заказчик — компания из сферы коммуникаций, вел очень активную и неравномерную маркетинговую деятельность. То есть шину нужно было масштабировать по требованию, а монолитная структура шины не позволила нам сделать выгодное ценовое предложение — то есть нужно было либо жечь кучу ресурсов постоянно, либо не соответствовать требованиям одного из функциональных заказчиков. В итоге мы вообще пришли к выводу, что шина-монолит в эпоху всеобщей распределенности не очень подходит под какой-никакой хайлоад в принципе.
В качестве альтернативы мы также нашли и рассмотрели другую, уже не монолитную, а очень даже микросервисную шину. Но даже при широкой инсталляционной базе готовая интеграционная платформа не позволяла нам закрыть задачи, в которых требуется форматно-логический контроль вводимых данных. То есть использование источников данных, которые нужно еще проверять и контролировать, подразумевало кучу новой работы и внедрения каких-то дополнительных решений. А модификация шины требовала намного больше времени, чем хотелось бы. К тому же заказчики (особенно переходящие с западных решений) в один голос говорили про noCode, Self-Service и нулевую головную боль при работе с новой шиной, какой бы она не была. Поэтому от готовых решений пришлось отказаться полностью.
Стек технологий
В итоге шину пришлось разрабатывать. Для этого мы выбрали:
Java, Spring Framework и ActiveMQ/Kafka/RabbitMQ. Транспортов специально поддерживаем много, потому что каждый хорош для своих задач. Например, транзакции с java legacy удобней делать на ActiveMQ, а сотни тысяч сообщений лучше прогонять через Kafka. Благодаря этому получилось совместить лучшие фреймворки для интеграционных взаимодействий и обработки данных.
Prometheus и Grafana — ну это вообще не обсуждается, так как мы просто берем международный стандарт для мониторинга и отображения информации
Apache Camel — опенсорсный интеграционный фреймворк с реализацией, пожалуй, всех паттернов интеграции. Годная вещь. Мы взяли его для повышения скорости создания маршрутов интеграции и различных адаптеров
Микросервисная архитектура и правильные фреймворки
В качестве примера, которым вдохновилась команда, взяли IBM Integration Bus. Она представляет собой систему микросервисов, способную адаптироваться к конкретным кейсам использования.
Схема работы IIB
Далее нужно было решить главную дилемму и выбрать правильный подход к архитектуре, чтобы обеспечить необходимую производительность и гибкость, но при этом не допустить компромиссов в вопросах надежности — это касается и работы платформы, и доставки сообщений.
Мы начали разработку и с опорой на микросервисную архитектуру. Добавили ко всему этому шлюз данных — для обеспечения полного цикла работы с api и удобного подключения потребителей. В итоге мы запроектировали оптимальное сочетание всех компромиссов и добились архитектуры со слабой связанностью компонентов.
Схема работы нашей шины
Мы выделили такие компоненты, как коннектор (подключается к источнику или адресату), адаптер (отвечает за маппинг, трансформацию и валидацию данных) и маршрутизатор (направляет данные по нужному адресу от адаптера к адаптеру).
Слабая связанность внутренних компонентов системы стала одним из преимуществ при внедрении на реальных проектах. Благодаря ей нам легко конфигурировать каждый модуль отдельно. То есть мы можем перестроить работу шины в случае изменения внешних условий, просто заменив конфигурационные файлы «на горячую». Это позволяет менять работу шины за считанные минуты.
Схема замены компонента
Вопросы безопасности решили методом внедрения TLS между компонентами, с размещением секретов в хранилище секретов и четким ограничением доступа.
Благодаря тому, что все секреты находятся в отдельном защищенном хранилище, шина может работать в соответствии со всеми строгими требованиями к ИБ и не допускать взаимодействия с не доверенными системами.
Результаты
В результате была создана шина, на базе которой мы уже решили задачи ряда клиентов и продолжаем развивать ее. На сегодняшний день создано уже более 50 коннекторов, в том числе универсальные http-rest и специализированные, такие как коннектор к очередям IBM, 1C и так далее.
Микросервисная архитектура оправдала себя в «боевом режиме». Так, например, в одном международном банке наша шина обеспечивает передачу более 100 тыс. платежных транзакций в день между различными системами с временем ожидания отклика не более 0,5 секунды по критическим транзакциям для бизнеса.
В настоящее время мы движемся к тому, чтобы конфигурировать шину в режиме Low-Code, чтобы менять настройки и подключать новые источники могли методологи и аналитики, не обращаясь к программистам. Этот функционал будет реализован весной 2024 года за счет UI поверх конфигурационных файлов.
Расскажите, а какой у вас опыт перехода с западных привычных шин на российские? Какого функционала не хватает больше всего, и есть ли позитивная практика использования разработок из Реестра российского ПО?
Новые вершины технологий ждут тебя в Telegram-канале К2Тех
