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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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