Разместить здесь вашу рекламу


Уже поменяли шину? Наш опыт «переобувания» и разработки интеграционной платформы

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Хабр, привет! На связи Дмитрий Бадулин, я занимаюсь разработкой ПО в компании К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
Схема работы IIB

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

Мы начали разработку и с опорой на микросервисную архитектуру. Добавили ко всему этому шлюз данных — для обеспечения полного цикла работы с api и удобного подключения потребителей. В итоге мы запроектировали оптимальное сочетание всех компромиссов и добились архитектуры со слабой связанностью компонентов.

Схема работы нашей шины
Схема работы нашей шины

Мы выделили такие компоненты, как коннектор (подключается к источнику или адресату), адаптер (отвечает за маппинг, трансформацию и валидацию данных) и маршрутизатор (направляет данные по нужному адресу от адаптера к адаптеру).

Слабая связанность внутренних компонентов системы стала одним из преимуществ при внедрении на реальных проектах. Благодаря ей нам легко конфигурировать каждый модуль отдельно. То есть мы можем перестроить работу шины в случае изменения внешних условий, просто заменив конфигурационные файлы «на горячую». Это позволяет менять работу шины за считанные минуты.

Схема замены компонента
Схема замены компонента

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

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

Результаты

В результате была создана шина, на базе которой мы уже решили задачи ряда клиентов и продолжаем развивать ее. На сегодняшний день создано уже более 50 коннекторов, в том числе универсальные http-rest и специализированные, такие как коннектор к очередям IBM, 1C и так далее.

Микросервисная архитектура оправдала себя в «боевом режиме». Так, например, в одном международном банке наша шина обеспечивает передачу более 100 тыс. платежных транзакций в день между различными системами с временем ожидания отклика не более 0,5 секунды по критическим транзакциям для бизнеса.

В настоящее время мы движемся к тому, чтобы конфигурировать шину в режиме Low-Code, чтобы менять настройки и подключать новые источники могли методологи и аналитики, не обращаясь к программистам. Этот функционал будет реализован весной 2024 года за счет UI поверх конфигурационных файлов. 

Расскажите, а какой у вас опыт перехода с западных привычных шин на российские? Какого функционала не хватает больше всего, и есть ли позитивная практика использования разработок из Реестра российского ПО?

Новые вершины технологий ждут тебя в Telegram-канале К2Тех

Источник: https://habr.com/ru/companies/k2tech/articles/776902/


Интересные статьи

Интересные статьи

Меня зовут Максим Кульгин, и моя компания clickfraud занимается защитой от скликивания контекстной рекламы в «Яндекс.Директ». Мы получили статус резидента Сколково в конце прошлого года, и я...
Pineapple Nano - это хакерское устройство от команды Hak5 для атак на беспроводные сети. Купить его не так просто, поэтому я решил собрать его сам. И эта статья будет как раз о том, как я прошел сквоз...
Всем привет! Меня зовут Анастасия Шарикова, я Technical Lead в Bookmate и веду телеграм канал Yet another QA. Реклама очередных курсов по тестированию и не только сейчас слышна из каждого утюга –...
В одном проекте мы строили новую ИТ-инфраструктуру и консолидировали на нее базы данных Oracle. Базы были разных объемов и степени критичности (вплоть до Business Critical). Казалось бы, штатная задач...
Европа и США — очень понятные страны для переезда. Мы много про них знаем если не из историй экспатов, то хотя бы из фильмов, сериалов и книг....