Комментарии 5
взяли IBM Integration Bus. Она представляет собой систему микросервисов ...
ЭЭЭ, не уверен... Скорее наоборот :) , но у IBM-ой шины есть куча коннекторов которые на первый взгляд выглядят как микросервисы ))). Или когда вы делаете какой-нибудь сервис для посылки запросов и приемов JSON-ов в ответ, это не значит что сама шина имеет микросервисную архитектуру. Сообщения внутри/между очередями MQ передаются без всяких микросервисов, иначе бы они не смогли работать быстро.
100 тыс. платежных транзакций в день
не так уж много
Главная проблема такого рода решений - количество внедрений
Все просто, упомянутая IIB внедрена наверное в десятках тысяч компаний. Каждый клиент использовал ее по разному, находя много косяков, которые оперативно (и не очень) исправлялись
У вас одно внедрение и как бы вы не хотели - полусырой продукт. Либо малофункциональный.
Плюс отлаженная процедура миграций и патчинга ядра (а это боль, когда у клиентов 100500 версий)
--------------
Так, например, в одном международном банке наша шина обеспечивает передачу более 100 тыс. платежных транзакций в день между различными системами с временем ожидания отклика не более 0,5 секунды по критическим транзакциям для бизнеса.
Ну такое, передает и передает. Ценность шины чуток в другом (в этом тоже, но если она и это не может делать - грош ей цена):
насколько она сохраняет сообщения в случае отказа/disaster
не допускает ли повтороных обработок
позволяет ли относительно лекго выполнять распределенные транзакции
как себя ведет общая производительность при падении части систем
...п
Понятно, что опыт полезный и все такое.
------------
И да, как указали выше, IIB, как минимум 10-ка и 11-ка не такая уж и микросервисная. Скорее как среда для выполнения приложений, но не микросервисов.
Внедрений у нас больше, но понятно, что не так много, как у IBM или SAP. Да ведь и ни у кого сейчас нет. С запуска шины мы уже выпустили несколько релизов, ускорили написания адаптера, провели улучшения ядра, так что работа идет)
А если про ценности, то:
Сообщения сохраняются в очереди, если есть требования к катастрофоусточивости - есть вариант с сохранением в промежуточный кластер БД (в этом случае начинает падать производительность).
Повторные обработки исключаются настройкой очередей. Про транзакции вопрос немного холиварный - проблема в том, что сами системы должны иметь возможность поддержки транзакций. RI в этом плане готова, а вот интегрируемые системы зачастую нет, поэтому вместо отката транзакции чаще всего используется механизм компенсации.
«Как себя ведет общая производительность при падении части систем» – тут стоит чуть конкретизировать вопрос. Все же интеграционный слой производительности не зависит от смежных систем. Если же вопрос про то, что кусок middleware отвалился - то тут смотря какой, это может быть как недоступность UI и на транспорт не будет эффекта, а может отключиться один из адаптеров - и тогда один из интеграционных маршрутов будет недоступен
Да ведь и ни у кого сейчас нет.
Ну, на стабильность кода влияет кол-во внедрений по всему миру :)
Сообщения сохраняются в очереди, если есть требования к катастрофоусточивости - есть вариант с сохранением в промежуточный кластер БД (в этом случае начинает падать производительность).
Из опыта, просто очередей может быть недостаточно. Банально, есть момент disaster с отказом площадки. Растягивание менеджера очередей на несколько сайтов - как минимум не самая тривиальная задача
Второе - для интеграционной шины иметь сценарии отработки восстановления на случай, если разные системы восстановились на разную точку. Понятно это больше к бизнес логике вопрос, но для прохождения реального теста "отказа" площадки стоит его рассматривать. Как минимум - что делать процедурно.
ут стоит чуть конкретизировать вопрос. Все же интеграционный слой производительности не зависит от смежных систем.
Да просто. У вас несколько систем, которые участвуют в запросах. И тут одной из них поплохело. Понятно чуда нет, и от нее толку не дождешься. Но вот остальные сценарии по хорошему в работе проседать не должны, а могут теоретически
--------------
Но это такое :) Понятно платформа не "чудотворец" и всего не заменит.
Но, если честно, в открытом тендере понятно самописное решение вряд ли пройдет даже квалификацию :)
Добрый день
В целом интересная статья, как на базе opensource технологий начать строить решения, сравнимые с коммерческими аналогами.
Хороший старт.
Так, например, в одном международном банке наша шина обеспечивает
передачу более 100 тыс. платежных транзакций в день между различными
системами с временем ожидания отклика не более 0,5 секунды по
критическим транзакциям для бизнеса.
Так например, в одном не самом крупном российском банке на шине, построенной на похожих opensouce технологиях, обеспечивается передача 3000 вызовов в секунду с задержкой от 0,3 до 0,5 секунд. И это не предел желаний по нагрузке.
Оправдала себя не микросервисная архитектура и low code, а работа с эффективным использованием вычислительных мощностей, обеспечением доступности кластеров, DR с гео резервированием, мониторинг, трассировка и другая observability. До выполнения этих требований про low code заказчик даже не хотел слушать.
Мы выделили такие компоненты, как коннектор (подключается к источнику
или адресату), адаптер (отвечает за маппинг, трансформацию и валидацию
данных)
Для ИТ-ландшафта с необходимостью интеграции коробочных/вендорских систем это адекватный подход.
В случае, если развитие интегрируемых систем и разработка интеграций на шине управляется заказчиком, то мы дошли до ровно обратного подхода
Транспортный протокол каждого интеграционного взаимодействия выбирается на основе нефункциональных требований. К интеграционному потоку все системы подключаются по одному протоколу. "Адаптеры протоколов - это не есть хорошо".
Если системы не могут договориться и обеспечить для интеграционного потока обмен в едином формате, то шина как посредник только усложняет дело. "Почтальон (шина) в конверт (в передаваемые данные) не лезет".
Для http взаимодействий шина не приносит значимого value, при этом создает еще один участок задержек и потенциальных сбоев. "Шина без value - деньги на ветер".
Расскажите, а какой у вас опыт перехода с западных привычных шин на
российские? Какого функционала не хватает больше всего, и есть ли
позитивная практика использования разработок из Реестра российского ПО?
Общение с потенциальными вендорами замирало на "кто конкретно и в каких финансовых объемах готов нести ответственность за отсутствие сбоев в проде".
С собственной разработкой опыт положительный. Сошлись на формулировке "если без сбоев работает, то всем премию. Если сбоит - без нытья шагаете за ворота".
Уже поменяли шину? Наш опыт «переобувания» и разработки интеграционной платформы