Ремизов Роман

Системный аналитик ГК Юзтех

Привет, мир!

Привет, мир! Меня зовут Роман Ремизов. Я — системный аналитик ГК Юзтех. В рамках цикла статей «Хроники архитектурного дизайна» я поделюсь своей экспертизой о разных автоматизированных банковских системах (АБС) и о том, что нужно знать перед тем, как приступить к архитектурному дизайну.

Системы продуктового слоя. Причём тут Camunda?

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

Принципы взаимодействия АБС схожи с взаимодействием микро-сервисов под управлением популярного оркестратора бизнес-процессов Camunda. Здесь имеется ввиду не cockpit (UI, позволяющий управлять процессами), а логика реализованных в Camunda механик.

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

В роли Camunda выступают АБС-оркестраторы, которые управляют бизнес-логикой продуктовых операций. Через продуктовые процессоры оркестраторы выполняют подготовку продуктовых событий к отражению в бухгалтерском учёте.

СУБО (Системы устойчивых бизнес-операций) по сути являются контроллерами для оркестрантов. Получая из источника, которым является система учёта продуктовых транзакций, инструкцию, они через UI предоставляют пользователю возможность обработать данную инструкцию и, на её основании, сформировать учётное событие.

Основанием для инструкции является транзакция. А учётное событие является конвертом для передачи этой продуктовой инструкции вместе с исходной транзакцией в систему, интерпретирующую такие события в бухгалтерские проводки.

В частном случае, в архитектуре также имеются оркестраторы, обработка инструкций в которых не требует участия пользователя. У таких оркестрантов нет СУБО.

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

Третьим примером экзотической реализации АБС продуктового слоя является ОПС (общий продуктовый сервис), который можно сравнить с монолитным оркестратором, в подчинении которого находится от 5 до 20 продуктовых процессоров. Часто такое встречается, когда в рамках нескольких банковских продуктов требуется выполнить схожие по составу и фактуре операции.

Также стоит отметить, что если рассматривать архитектуру АБС продуктового слоя с использованием legacy-систем, то такие системы представлены Oracle`овыми типовыми монолитными продуктами класса WAY (WAY4), которые объединяют в себе функциональность как продуктового процессора, так и оркестратора, а также предоставляют контроллеры для управления процессами. Такие системы из коробки имеют свой UI, но также могут быть представлены и без него.

Виды взаимодействий систем продуктового слоя.

Взаимодействие между АБС продуктового слоя можно разделить на 3 типа:

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

• Внешний REST API, тип взаимодействия синхронный, использование которого предусматривает обязательное подключение к ЕПА и TYK, а также его размещение в реестре API. По поводу API Gateway (TYK) рассказывала Елизавета Акманова в рамках статьи «Зачем и где нужен API Gateway» в блоке компании Юзтех на Хабре.

• Очереди сообщений, тип взаимодействия асинхронный, с применением шаблонов гарантированной доставки или без них. Традиционно это Kafka, есть Artemis, может быть и Rabbit MQ.

Ранее мы упомянули ЕПА.

ЕПА (Единая платформа авторизации) – один из сервисов банка, который хранит информацию о всех пользователях, в том числе, технических. Внутри ЕПА имеются общие сервисы, которые отвечают за:

• Реестр пользователей.

• Ролевую модель пользователей. Доступ к ресурсам, что естественно, осуществляется согласно роли пользователя.

Также ранее мы упомянули TYK.

Под маркой TYK предлагается целая облачная платформа (сам шлюз), в основе которой лежит проект API Gateway. Это проект с открытым исходных кодом под лицензией MPL v2.0.

Также в банках имеется реестр API. Чтобы API системы было доступно для других АБС, оно должно быть добавлено в этот реестр. Можно сказать, что тиражирование API АБС занимается реестр API.

Системы бухгалтерского слоя и очереди сообщений. Снова немного о Kafka.

Результатом реализации стратегии импортозамещения является полный переход от legacy-систем на целевую микро-сервисную архитектуру. О legacy-системах мы подробнее поговорим в следующей статье, посвящённой главным книгам, где в качестве отправной точки процесса импортозамещения расположены Oracle`овые типовые банковские продукты семейства CFT (ЦФТ).

Другими словами, согласно стратегии импортозамещения, АБС бухгалтерского слоя должны быть представлены в микро-сервисной архитектуре.

Все взаимодействия АБС бухгалтерского слоя класса Accounting Engine, как и взаимодействия между системами продуктового слоя, также можно разделить на три типа:

• Внутренний REST API, тип взаимодействия синхронный, используется внутри АБС, для взаимодействия между микро-сервисами.

• Внешний REST API, тип взаимодействия синхронный, использование которого предусматривает обязательное подключение к ЕПА и TYK.

• Очереди сообщений, тип взаимодействия асинхронный, с применением шаблонов гарантированной доставки или без них. Традиционно это Kafka, при участии Artemis, существенно реже Rabbit MQ.

На очередях сообщений мы остановимся подробнее. В качестве примера возьмём брокер сообщений Kafka.

Для взаимодействия с внешними системами должна использоваться внешняя Kafka (со своим набором топиков), а для взаимодействия между микро-сервисами внутри системы должна использоваться внутренняя Kafka (со своим набором топиков).

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

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

Освежим знания по основным элементам сообщения в топиках Kafka:

• Ключ (Key): Это необязательный элемент, который используется для обработки сообщений. Если он задан, сообщения с одинаковым ключом будут направляться в одну и ту же партицию. Здесь имеются ввиду партиции брокера, а не БД.

• Значение (Value): Основное содержимое сообщения, которое может содержать любые данные, например, текст или бинарные данные. Для обработки бинарных данных используются процессы сериализации и десериализации, которые являются обратными относительно друг друга.

• Заголовки (Headers): Это дополнительные метаданные, которые можно прикрепить к сообщению. Они могут служить для передачи информации о типе данных, версии, времени создания и других характеристиках. Отмечу, что на заголовках мы фокусируемся прямо сейчас, в процессе текущего повествования.

• Таймстамп (Timestamp): Указывает время, когда сообщение было создано. Он может быть установлен автоматически брокером или задан вручную.

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

Во внешней Kafka банка заголовки могут выглядеть следующим образом:

Разберём пример требований к заголовку сообщений во внешней Kafka:

• Согласно п. 1, основной consumer понимает, какой DTO необходимо использовать для парсинга данного сообщения, — и здесь важно понимать, что парсинг это ещё не обработка, а лишь её начало.

• Согласно п. 2, другой consumer забирает данные для своей системы, — в этом случае этой системой является служебный сервис «Биллинг».

• Согласно п. 3, тот же «Биллинг» идентифицирует систему-поставщика сообщения.

При этом, служебному сервису «Биллинг» нет необходимости вычитывать, парсить и обрабатывать всё сообщение. Необходимую для себя информацию он получает из заголовков сообщения, являясь consumer`ом того же топика внешней Kafka, который слушает и читает основной consumer. В нашем случае, это общий сервис генерации проводок, и «основным» я назвал его потому, что именно он обрабатывает сообщения. То есть, обеспечивает основную функциональность.

Предварительное заключение.

В текущей статье мы определили, что, как для АБС продуктового слоя, так и для АБС бухгалтерского слоя, характерны:

• Микро-сервисная архитектура.

• Использование трёх типов взаимодействия:

  • Внутренний REST API.

  • Внешний REST API.

  • Очереди сообщений.

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

• Шаблоны гарантированной доставки.

• Концепцию share nothing.

• Транзакционность и уровни изолирования записи данных в БД.

• Кэширование данных, полученных из смежных систем.