Толстые проблемы интеграций и их тонкие решения

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

В прошлой статье я рассказывал о том, как мы с командой запустили проект по перестройке бухгалтерского ядра и внедрению новой главной книги. 

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

Рис. 1. Краткое содержание предыдущей серии
Рис. 1. Краткое содержание предыдущей серии

Итак, на старте проекта мы имеем один сконцентрированный монолит. При такой компоновке банковского ядра, когда продуктовое, бухгалтерское и отчетное ядро находятся на одном инстансе, много задумываться об интеграциях не приходится, а большинство внешних взаимодействий можно решить, запустив с помощью RPC, DBLink, ODBC любой внешний источник прямо в базу монолита. Большая часть логики такой системы обычно хранится в СУБД, что, в свою очередь, с каждым новым подключенным источником и потребителем способствует ещё большей «кристаллизации» взаимодействий между системами и приводит к большому количеству зависимостей между ними, которые в будущем не позволят не только разбить этот монолит на куски, но и близко к нему подойти. 

Рис. 2. Пример "спайки" систем в монолиты.
Рис. 2. Пример "спайки" систем в монолиты.

Следует учитывать, что технологическая монолитизация приводит к тому, что процессы банка также становятся зависимыми между собой, а это уже оказывает очень сильное влияние на оргструктуру и взаимодействия между подразделениями. 

Во всё этом, по большей части, виноваты неправильные, отсутствующие или избыточные "жёсткие" интеграции между системами. 

Рис. 3. Зависимости от жестких интеграций копятся как снежный ком.
Рис. 3. Зависимости от жестких интеграций копятся как снежный ком.

На старте проекта по выводу Главной Книги и Бухгалтерского движка в отдельную систему, мы, в первую очередь, начали исследовать возможности перехода на событийный обмен, потому как это самый простой и очевидный способ, с помощью которого можно "распилить" монолит, при этом сохранив возможность использовать выделенные функции монолита в случае необходимости. 

Рис. 4. Предложенный вариант интеграций при внедрении новой Главной Книги Банка
Рис. 4. Предложенный вариант интеграций при внедрении новой Главной Книги Банка

Для событийного обмена как основной элемент обмена была выбрана KAFKA, т.к. в будущей архитектуре мы видим не только событийный обмен, но и адаптацию работы бухгалтерского ядра с DataLake, который должен быть легко интегрирован в HDFS. Также KAFKA позволяет нам в случае необходимости восстанавливать последовательности событий,Потоки событий между системами сделать в будущем общедоступными. 

Рис. 5. Обеспечение транзита больших данных во внешние системы
Рис. 5. Обеспечение транзита больших данных во внешние системы

 

При использовании KAFKA заранее были выделены два различающихся принципа взаимодействия через топики: ThinTopics (тонкие топики) и FatTopics (толстые топики). Для проектирования взаимодействия продуктовых платформ с бухгалтерским движком был выбран принцип тонких топиков. Такой принцип потребует больше мощностей для узла KAFKA, но это существенно сократит человеческие затраты времени на локализацию проблем и администрирование, что несоразмерно больше стоимости оборудования в среднесрочной и долгосрочной перспективе.

Рис. 6. Принцип "тонких" топиков KAFKA
Рис. 6. Принцип "тонких" топиков KAFKA
Рис. 7. Принцип "толстых" топиков KAFKA
Рис. 7. Принцип "толстых" топиков KAFKA
Рис. 8. Комбинированный способ работы с топиками KAFKA
Рис. 8. Комбинированный способ работы с топиками KAFKA

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

Основные проблемы, с которыми мы столкнулись в результате анализа

  1. Ранее спроектированные процедуры монолита хранят состояние транзакции в рамках одной пользовательской сессии, внутренние интеграции могут не выходить за границы инстанса. Процесс отката таких транзакций в монолите не сложен, "просто делаем ROLLBACK", хранить состояние транзакции в "долгой" памяти не требуется. Для работы в разделенной сервисно-ориентированной и микро-сервисной среде потребуется уже хранить состояние каждого элемента транзакции в разных системах и заранее решать то, кто будет оркестировать такими транзакциями и с помощью каких инструментов, либо задавать правила хореографии на старте таких транзакций. Эта задача решается правильной интеграцией систем и передачей правильных наборов данных с событием.

  2. Сильно отличаются компетенции команды разработки нового бухгалтерского ядра и разработчиков, ведущих текущий монолит. Иногда рабочие встречи заканчивались полным провалом только по причине того, что эти команды не могли достигнуть между собой обычных договоренностей в использовании тех или иных способов интеграции. Митигировать данный риск требуется на самом начальном этапе проектов подобного типа, ещё на этапах pre-Study и Study, что в нашем случае сделано не было, поэтому в дальнейшем пришлось изрядно попотеть, чтобы самостоятельно привести эти команды к общему знаменателю. 

  3. Аналогичная проблема, описанная в пункте 2, ожидает также на этапе интеграции продуктовых платформ. Данную часть можно решить, описав заранее требования бухгалтерского движка по отношению к продуктовым платформам ("задать правила игры"). Сразу необходимо готовиться к тому, что такие требования будут постоянно подвергаться испытаниям как внутри команд, строящих бухгалтерский движок, так и внутри команд, занимающихся разработкой продуктовых платформ, поэтому данный документ требует детальной проработки и должен быть заранее согласован между всеми участниками с возможностью нескольких незначительных пересмотров на этапах анализа и разработки.

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

В следующей статье я постараюсь рассказать о том, как мы перепроектировали процедуры закрытия банковского дня в рамках трансформаций в Банке.


Кстати, 9 декабря я буду выступать на онлайн-митапе по архитектуре, расскажу про основы автоматизации процессов управления архитектурой. Также будут ребята из Croc Code, они поделятся тем, как оценить модернизацию архитектуры, и Leroy Merlin выступят с темой про использование Composable Architecture. Регистрация на митап тут.

Источник: https://habr.com/ru/company/rosbank/blog/590255/

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

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

Уже пару лет мы присматриваемся к технологиям внедрения элементов ИИ (или AI – artificial intelligence) в маркетинговые процессы. Эта тема особенно интересна нам, потому что мы занимаемся автоматизаци...
Возможность организации работы SCTP поверх UDP (известная ещё как инкапсуляция SCTP-пакетов в UDP-пакеты) определена в RFC 6951 и реализована в пространстве ядра Linux начиная с версии ядра 5.11.0. По...
К 2021 году прогнозируется, что около 16 млрд из приблизительно 28 млрд подключенных устройств по всему миру, будут так или иначе связаны в рамках концепции интернета вещей. Интернет уходит в вещность...
Всем привет. Если вы когда-либо работали с универсальными списками в Битрикс24, то, наверное, в курсе, что страница детального просмотра элемента полностью идентична странице редак...
Те, кто собираются открывать интернет-магазин, предварительно начитавшись в интернете о важности уникального контента, о фильтрах, накладываемых поисковиками за копирование материалов с других ресурсо...