Хабр, привет! На связи Дмитрий Бадулин, я занимаюсь разработкой ПО в компании К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. Она представляет собой систему микросервисов, способную адаптироваться к конкретным кейсам использования.
Далее нужно было решить главную дилемму и выбрать правильный подход к архитектуре, чтобы обеспечить необходимую производительность и гибкость, но при этом не допустить компромиссов в вопросах надежности — это касается и работы платформы, и доставки сообщений.
Мы начали разработку и с опорой на микросервисную архитектуру. Добавили ко всему этому шлюз данных — для обеспечения полного цикла работы с api и удобного подключения потребителей. В итоге мы запроектировали оптимальное сочетание всех компромиссов и добились архитектуры со слабой связанностью компонентов.
Мы выделили такие компоненты, как коннектор (подключается к источнику или адресату), адаптер (отвечает за маппинг, трансформацию и валидацию данных) и маршрутизатор (направляет данные по нужному адресу от адаптера к адаптеру).
Слабая связанность внутренних компонентов системы стала одним из преимуществ при внедрении на реальных проектах. Благодаря ей нам легко конфигурировать каждый модуль отдельно. То есть мы можем перестроить работу шины в случае изменения внешних условий, просто заменив конфигурационные файлы «на горячую». Это позволяет менять работу шины за считанные минуты.
Вопросы безопасности решили методом внедрения TLS между компонентами, с размещением секретов в хранилище секретов и четким ограничением доступа.
Благодаря тому, что все секреты находятся в отдельном защищенном хранилище, шина может работать в соответствии со всеми строгими требованиями к ИБ и не допускать взаимодействия с не доверенными системами.
Результаты
В результате была создана шина, на базе которой мы уже решили задачи ряда клиентов и продолжаем развивать ее. На сегодняшний день создано уже более 50 коннекторов, в том числе универсальные http-rest и специализированные, такие как коннектор к очередям IBM, 1C и так далее.
Микросервисная архитектура оправдала себя в «боевом режиме». Так, например, в одном международном банке наша шина обеспечивает передачу более 100 тыс. платежных транзакций в день между различными системами с временем ожидания отклика не более 0,5 секунды по критическим транзакциям для бизнеса.
В настоящее время мы движемся к тому, чтобы конфигурировать шину в режиме Low-Code, чтобы менять настройки и подключать новые источники могли методологи и аналитики, не обращаясь к программистам. Этот функционал будет реализован весной 2024 года за счет UI поверх конфигурационных файлов.
Расскажите, а какой у вас опыт перехода с западных привычных шин на российские? Какого функционала не хватает больше всего, и есть ли позитивная практика использования разработок из Реестра российского ПО?
Новые вершины технологий ждут тебя в Telegram-канале К2Тех
Комментарии (5)
Batalmv
28.11.2023 09:56Главная проблема такого рода решений - количество внедрений
Все просто, упомянутая IIB внедрена наверное в десятках тысяч компаний. Каждый клиент использовал ее по разному, находя много косяков, которые оперативно (и не очень) исправлялись
У вас одно внедрение и как бы вы не хотели - полусырой продукт. Либо малофункциональный.
Плюс отлаженная процедура миграций и патчинга ядра (а это боль, когда у клиентов 100500 версий)
--------------
Так, например, в одном международном банке наша шина обеспечивает передачу более 100 тыс. платежных транзакций в день между различными системами с временем ожидания отклика не более 0,5 секунды по критическим транзакциям для бизнеса.
Ну такое, передает и передает. Ценность шины чуток в другом (в этом тоже, но если она и это не может делать - грош ей цена):
насколько она сохраняет сообщения в случае отказа/disaster
не допускает ли повтороных обработок
позволяет ли относительно лекго выполнять распределенные транзакции
как себя ведет общая производительность при падении части систем
...п
Понятно, что опыт полезный и все такое.
------------
И да, как указали выше, IIB, как минимум 10-ка и 11-ка не такая уж и микросервисная. Скорее как среда для выполнения приложений, но не микросервисов.
DimaBadulin Автор
28.11.2023 09:56Внедрений у нас больше, но понятно, что не так много, как у IBM или SAP. Да ведь и ни у кого сейчас нет. С запуска шины мы уже выпустили несколько релизов, ускорили написания адаптера, провели улучшения ядра, так что работа идет)
А если про ценности, то:
Сообщения сохраняются в очереди, если есть требования к катастрофоусточивости - есть вариант с сохранением в промежуточный кластер БД (в этом случае начинает падать производительность).
Повторные обработки исключаются настройкой очередей. Про транзакции вопрос немного холиварный - проблема в том, что сами системы должны иметь возможность поддержки транзакций. RI в этом плане готова, а вот интегрируемые системы зачастую нет, поэтому вместо отката транзакции чаще всего используется механизм компенсации.
«Как себя ведет общая производительность при падении части систем» – тут стоит чуть конкретизировать вопрос. Все же интеграционный слой производительности не зависит от смежных систем. Если же вопрос про то, что кусок middleware отвалился - то тут смотря какой, это может быть как недоступность UI и на транспорт не будет эффекта, а может отключиться один из адаптеров - и тогда один из интеграционных маршрутов будет недоступен
Batalmv
28.11.2023 09:56Да ведь и ни у кого сейчас нет.
Ну, на стабильность кода влияет кол-во внедрений по всему миру :)
Сообщения сохраняются в очереди, если есть требования к катастрофоусточивости - есть вариант с сохранением в промежуточный кластер БД (в этом случае начинает падать производительность).
Из опыта, просто очередей может быть недостаточно. Банально, есть момент disaster с отказом площадки. Растягивание менеджера очередей на несколько сайтов - как минимум не самая тривиальная задача
Второе - для интеграционной шины иметь сценарии отработки восстановления на случай, если разные системы восстановились на разную точку. Понятно это больше к бизнес логике вопрос, но для прохождения реального теста "отказа" площадки стоит его рассматривать. Как минимум - что делать процедурно.
ут стоит чуть конкретизировать вопрос. Все же интеграционный слой производительности не зависит от смежных систем.
Да просто. У вас несколько систем, которые участвуют в запросах. И тут одной из них поплохело. Понятно чуда нет, и от нее толку не дождешься. Но вот остальные сценарии по хорошему в работе проседать не должны, а могут теоретически
--------------
Но это такое :) Понятно платформа не "чудотворец" и всего не заменит.
Но, если честно, в открытом тендере понятно самописное решение вряд ли пройдет даже квалификацию :)
mikeGolovanov
28.11.2023 09:56Добрый день
В целом интересная статья, как на базе opensource технологий начать строить решения, сравнимые с коммерческими аналогами.
Хороший старт.
Так, например, в одном международном банке наша шина обеспечивает
передачу более 100 тыс. платежных транзакций в день между различными
системами с временем ожидания отклика не более 0,5 секунды по
критическим транзакциям для бизнеса.Так например, в одном не самом крупном российском банке на шине, построенной на похожих opensouce технологиях, обеспечивается передача 3000 вызовов в секунду с задержкой от 0,3 до 0,5 секунд. И это не предел желаний по нагрузке.
Оправдала себя не микросервисная архитектура и low code, а работа с эффективным использованием вычислительных мощностей, обеспечением доступности кластеров, DR с гео резервированием, мониторинг, трассировка и другая observability. До выполнения этих требований про low code заказчик даже не хотел слушать.
Мы выделили такие компоненты, как коннектор (подключается к источнику
или адресату), адаптер (отвечает за маппинг, трансформацию и валидацию
данных)Для ИТ-ландшафта с необходимостью интеграции коробочных/вендорских систем это адекватный подход.
В случае, если развитие интегрируемых систем и разработка интеграций на шине управляется заказчиком, то мы дошли до ровно обратного подхода
Транспортный протокол каждого интеграционного взаимодействия выбирается на основе нефункциональных требований. К интеграционному потоку все системы подключаются по одному протоколу. "Адаптеры протоколов - это не есть хорошо".
Если системы не могут договориться и обеспечить для интеграционного потока обмен в едином формате, то шина как посредник только усложняет дело. "Почтальон (шина) в конверт (в передаваемые данные) не лезет".
Для http взаимодействий шина не приносит значимого value, при этом создает еще один участок задержек и потенциальных сбоев. "Шина без value - деньги на ветер".
Расскажите, а какой у вас опыт перехода с западных привычных шин на
российские? Какого функционала не хватает больше всего, и есть ли
позитивная практика использования разработок из Реестра российского ПО?Общение с потенциальными вендорами замирало на "кто конкретно и в каких финансовых объемах готов нести ответственность за отсутствие сбоев в проде".
С собственной разработкой опыт положительный. Сошлись на формулировке "если без сбоев работает, то всем премию. Если сбоит - без нытья шагаете за ворота".
sergeyns
ЭЭЭ, не уверен... Скорее наоборот :) , но у IBM-ой шины есть куча коннекторов которые на первый взгляд выглядят как микросервисы ))). Или когда вы делаете какой-нибудь сервис для посылки запросов и приемов JSON-ов в ответ, это не значит что сама шина имеет микросервисную архитектуру. Сообщения внутри/между очередями MQ передаются без всяких микросервисов, иначе бы они не смогли работать быстро.
не так уж много