В последняя статья Я рассказал о том, как мы с командой запустили проект по перестройке ядра бухгалтерского учета и внедрению новой главной книги.
На этот раз я расскажу вам об одной из самых актуальных проблем любой архитектуры, о которой приходится думать при решении любой архитектурной задачи практического характера — интеграциях.
Рис.
1. Краткое содержание предыдущего эпизода Итак, на старте проекта мы имеем один концентрированный монолит. При такой компоновке банковского ядра, когда продукты, ядра учета и отчетности находятся в одном экземпляре, вам не придется много думать об интеграциях, а большинство внешних взаимодействий можно решить, запустив любой внешний источник непосредственно в монолитную базу данных с помощью RPC, DBLink, ODBC. Большая часть логики такой системы обычно хранится в СУБД, что, в свою очередь, с каждым новым подключением источника и потребителя способствует еще большей «кристаллизации» взаимодействий между системами и приводит к большому количеству зависимостей между ними.
что в будущем не позволит не только разбить этот монолит на куски, но и приблизиться к нему.
Рис.
2. Пример «сварки» систем в монолиты.
Следует учитывать, что технологическая монолитизация приводит к тому, что процессы банка также становятся зависимыми друг от друга, а это уже очень сильно влияет на организационную структуру и взаимодействие между подразделениями.
Во всем этом во многом виноваты недействительные, отсутствующие или избыточные «жесткие» интеграции между системами.
Рис.
3. Зависимости от жестких интеграций накапливаются как снежный ком.
На старте проекта по выведению Главной книги и бухгалтерского учета в отдельную систему мы, в первую очередь, начали изучать возможности перехода на событийный обмен, ведь это самый простой и очевидный способ «вырезать» up» монолита, сохраняя при этом возможность использования выделенных функций монолита при необходимости.
Рис.
4. Предлагаемый вариант интеграции для внедрения новой Главной книги Банка.
Для обмена событиями в качестве основного элемента обмена был выбран KAFKA, поскольку в будущей архитектуре мы видим не только обмен событиями, но и адаптацию ядра учета с DataLake, которое должно легко интегрироваться в HDFS. Также KAFKA позволяет нам при необходимости восстанавливать последовательности событий, делая в будущем потоки событий между системами общедоступными.
Рис.
5. Обеспечение транзита больших данных во внешние системы При использовании KAFKA заранее были определены два разных принципа взаимодействия через темы: ThinTopics (тонкие темы) и FatTopics (толстые темы).
Для проектирования взаимодействия продуктовых платформ с механизмом учета был выбран принцип тонких тем.
Этот принцип потребует большей мощности узла KAFKA, но это позволит значительно сократить затраты человеческого времени на локализацию и администрирование проблемы, которое непропорционально превышает стоимость оборудования в среднесрочной и долгосрочной перспективе.
Рис.
6. Принцип «тонких» тем KAFKA 
Рис.
7. Принцип «толстого» топа KAFKA 
Рис.
8. Комбинированный способ работы с темами KAFKA С помощью этого решения мы ставим перед собой цель сократить время доставки данных из продуктовых систем в систему учета и из системы учета в системы аналитики и отчетности, а также сократить время анализа и время восстановления в случае возникновения проблем.
несчастных случаев.
Основные проблемы, с которыми мы столкнулись в результате анализа
- Ранее разработанные монолитные процедуры хранят состояние транзакции в течение одного пользовательского сеанса; внутренние интеграции не могут выходить за пределы экземпляра.
Процесс отката таких транзакций в монолите не сложен, «просто делайте ROLLBACK», нет необходимости хранить состояние транзакции в «длинной» памяти.
Для работы в отдельной сервис-ориентированной и микросервисной среде вам потребуется хранить состояние каждого элемента транзакции в разных системах и заранее решать, кто и какими инструментами будет организовывать такие транзакции, либо задавать правила хореографии в начале процесса.
такие сделки.
Эта проблема решается правильной интеграцией систем и передачей правильных наборов данных с мероприятием.
- Компетенции команды, разрабатывающей новое учетное ядро, и разработчиков, возглавляющих нынешний монолит, сильно различаются.
Иногда рабочие встречи заканчивались полным провалом только потому, что эти команды не могли достичь между собой привычных договоренностей об использовании тех или иных методов интеграции.
Необходимо минимизировать этот риск на самом начальном этапе проектов такого типа, даже на этапах PreStudy и Study, чего в нашем случае сделано не было, поэтому в дальнейшем нам пришлось немало потрудиться, чтобы самостоятельно привлечь эти команды.
к общему знаменателю.
- Аналогичная проблема, описанная в пункте 2, ждет и на этапе интеграции продуктовых платформ.
Эту часть можно решить, заранее описав требования механизма учета по отношению к продуктовым платформам («установить правила игры»).
Сразу необходимо подготовиться к тому, что такие требования будут постоянно тестироваться как внутри команд, строящих систему учета, так и внутри команд, разрабатывающих продуктовые платформы, поэтому данный документ требует детальной проработки и должен быть заранее согласован между всеми участниками с возможность внесения нескольких незначительных доработок на этапах анализа и разработки.
Количество спорных вопросов меняется каждый день, и интересные наблюдения я постараюсь разместить в этом блоге.
В следующей статье я постараюсь рассказать о том, как мы переработали процедуры закрытия банковского дня в рамках преобразований в Банке.
Кстати, 9 декабря я буду выступать на онлайн-встреча по архитектуре , расскажу об основах автоматизации процессов управления архитектурой.
Еще будут ребята из «Крок Код», они поделятся, как оценивать модернизацию архитектуры, и «Леруа Мерлен» выступит на тему использования Composable Architecture. Регистрация на встречу здесь .
Теги: #инфраструктура #архитектура #Системный анализ и проектирование #kafka #Apache #проектирование системы #проектирование и рефакторинг #монолит #интеграции #темы
-
Открытый Урок «Uml-Диаграммы»
19 Oct, 24 -
Посмертное Происшествие Для Новичков
19 Oct, 24 -
Обзор Мобильных Антифрод-Систем
19 Oct, 24 -
Как Же Обойтись Без 1С?
19 Oct, 24
