Меня зовут Александр, я работаю в Московском Кредитном Банке (МКБ) с 2013 года. Когда я пришел на работу разработчиком интеграции на IBM ESB (Enterprise Service Bus), МКБ был не очень крупным. И интеграция тоже была не очень развита: большая часть взаимодействий строилась напрямую между системами. Плюс имелся большой монолит из скоупа разных систем. Сейчас я  — руководитель центра компетенций интеграционных решений. И за 10 лет мы добились того, что нами написано более тысячи разнообразных интеграций на Open Source-решениях, с доступностью 99,9% времени в течение года. Под катом я вкратце расскажу, как это получилось сделать и как я в этом участвовал, каких принципов наша команда придерживается при разработке интеграции, о типах систем, которые нам необходимы, как это все развивалось с течением времени.

А 10 лет — большой срок. Поэтому, если вы в своей компании тоже занимаетесь межсистемной интеграцией, заходите почитать. На каком бы этапе эта интеграция ни находилась, надеюсь, почерпнете для себя полезную информацию.

Что было в начале

Моя карьера в МКБ началась в 2013 году. Банк на тот момент был еще не очень крупным. Большая часть взаимодействий строилась напрямую между системами. Плюс, был большой монолит из скоупа разных систем.

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

С очередями брокеров на тот момент еще никто не работал. Мы в своих сервисах  использовали только JMS-очереди, расположенные на самом сервере шины, для своих внутренних целей по асинхронным потокам. Способами взаимодействия через ESB по синхронным вызовам были SOAP- и REST-протоколы. Они выступали интерфейсом для других систем. Для асинхронного взаимодействия создавали шедулеры на шине или использовали один из встроенных механизмов событий IBM ESB с EventStore-таблицей.

Поговорим об Eventstore

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

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

 У этого решения есть явные преимущества. Можно:

• Использовать его с любой реляционной БД;

• Гибко настроить контроль за доставкой 

- настроить гарантированную доставку 

- сделать мониторинг статуса доставки с возможностью ручной переотправки);

• Использовать EventStore как очередь Брокера сообщений: в таблице с данными будет лежать уже готовая XML для передачи во все системы. Это позволяет дорабатывать формат сообщения, не залезая на интеграционный слой.

• Мы у себя используем не все возможности этого подхода. И вообще несколько переработали его для своего удобства. Подробнее о способе можно почитать в документации IBM здесь. 

Пробиваем потолок

В 2017-2018 годах произошло сразу два события, которые нас заставили пересмотреть инструмент для интеграции:

•  Мы поняли, что текущих мощностей интеграционной шины нам начало не хватать.

• IBM объявило об окончание поддержки и развития системы IBM ESB. 

Так как одним из основных требований было внедрить недорогое решение, то для первичного сравнения было выбрано четыре варианта:

• Talend ESB;

• Mule ESB;

• WSO2 Integrator;

• Написание сервисов на .NET.

После верхнеуровневой оценки я остановился на WSO2 Integrator и .NET для проведения пилота данных решениях. Mule и Talend я отсеял, так как данные ESB ограничены в функционале при бесплатных версиях.

В итоге нами было выбрано решение WSO2 Integrator, так как при равных результатах нагрузочного тестирование и доступного функционала, скорость и простота разработки на WSO2 была лучше.

Вызов принят!

Следующим вызовом для меня стало новое правило в нашем ИТ, в котором говорилось о том, что высоко критичным системам запрещено взаимодействовать напрямую. В следствие этого появились две новые задачи:

• Справляться с увеличенным количеством задач (в 3-4 раза) по интеграции с тем же количеством разработчиков.

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

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

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

Примеры таких шаблонов (на данный момент всего зафиксировано 13 шаблонов):

ВАЖНО! Мое подразделение занимается конкретно межсистемной интеграцией.  Кому-то такие шаблоны покажутся уж очень банальными и очевидными, но наша задача и состоит в том, чтобы интеграция была простой, надежной и гибкой (при необходимости без проблем поменять системы источников, потребителей или же сам интеграционный слой).

Ну и конечно, чтобы каждый мог сделать правильный выбор шаблона, мы написали небольшую методичку. Ее мы сделали как можно проще, по факту там требуется ответить на 3 основных вопроса:

Поехали!

Первыми нашими серьезными проектами, которые позволили подтвердить правильность наших выборов описанных выше, были: 

• замена АБС (Автоматизированная банковская система) системы в банке;

• первый этап замены AML (Anti Money Laundering) системы.

Решение о замене АБС-системы было очень масштабным, требовалось проработать более сотни новых интеграций. Но нам повезло, так как для интеграции с АБС было придумано 3 способа взаимодействия, которые были для нас минимально трудозатратными. Например, на разработку нового синхронного HTTP-сервиса уходило 2-4 часа именно по шине. По асинхронному взаимодействию в обе стороны — примерно 3-5 часов. Это была победа, так как мы успевали делать сервисы тремя разработчиками для всех необходимых систем, которые взаимодействовали с АБС банка.

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

Пополняем список инструментов

Появление новой системы для ETL-потоков

Как я писал ранее, в банке уже имелся инструмент для создание такого типа интеграции. Но в связи с успешным стартом интеграционной шины без поддержки вендора захотелось получить идентичный «бесплатный» инструмент по ETL для выполнения простых задач (самый простой вариант — перелив таблицы из одной БД в другую, раз в день) в небольших командах. Так как мы уже работали с продуктом WSO2 Integrator, я решил внедрить систему WSO2 Stream Processor (на данный момент продукт называется Streaming Integration). Данная система оказалась проста в использование, даже с учетом того, что пришлось немного освоить язык siddhi.

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

Внедрение API Manager-системы

Внедрение данного типа системы связано с тем, что появилась необходимость стандартизировать внешние АПИ, которые банк предоставляет своим партнерам и клиентам. Это позволит привлекать новых партнеров на работу через АПИ без отдельных доработок на стороне банковских систем.

Изначально в 2019 году банком было выбрано решение от компании IBM. Но так как проект был в низком приоритете, запуск данной системы постоянно откладывался. В середине 2021 года его реанимировали и к началу 2022 года уже были развернуты все необходимые контуры для системы и реализовано два пилотных API, планируемых к запуску. Но появилась новость, что IBM уходит из России и пришлось в срочном порядке менять внедряемую систему. За три недели мы развернули и перенесли пилотный АПИ на аналогичную систему от WSO2.

На текущий момент в прод-контуре запущено несколько АПИ по работе с продуктами банка, и мы готовим портал разработчика для общего доступа.

Внедрение Kafka

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

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

В 2022 году началось самое интересное. Мы решили на базе Kafka и Debezium построить CDC-процесс по распространению данных из критичных систем, но об этом я расскажу чуть позже.

Обновление интеграционных шаблонов и реестр сервисов

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

К 2022 году в банке уже насчитывалось больше 100 разных систем и написаны первые 1000 интеграционных сервисов на WSO2 Integrator. В связи с этим:

• Мы решили обновить интеграционные шаблоны так как появились новые, перспективные способы взаимодействия.

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

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

Влияние общей зрелости ИТ в компании на межсистемную интеграцию

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

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

Архитектура и информационная безопасность

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

Тестирование

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

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

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

Одним из последних ключевых вкладов в ИТ в МКБ было создание отдельного нагрузочного контура, включающего в себя основные core-системы. Данный шаг позволил нам определять узкие места в интеграционных потоках раньше, чем мы ловили проблемы на ПРОД контуре.

Поддержка

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

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

На чем остановились сейчас и какие планы на будущее

ESB в Kubernetes

Сейчас мы начали тестировать новую версию используемой шины, которую возможно разворачивать в Kubernetes. Отлаживаем данную версию на пилотных проектах, в 2023 году планируем разработать план по выносу некоторых конкретных нагруженных сервисов в кластер Kubernetes и провести пилотный проект. Отмечу, что к данной активности мы готовились давно, разбивая сервисы по некоторым параметрам (направления, критичность и т.д.).

CDC-процессы

Kafka и Debezium

Большие надежды у нас возлагаются на проект по внедрению Kafka и Debezium. Это позволит нам делать меньше запросов в мастер-системы и собирать информацию из отдельных слоев данных, что снизит общую нагрузку на ключевые системы.

Например, когда мы это тестировали на контуре разработки, скорость вычитки записей из таблицы в топик Kafka была примерно 60 000 в секунду. Запись была медленнее (10 000 - 20 000 в секунду), в зависимости от сложности конечных таблиц.

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

FormIT (Informatica PWX)

Это еще один инструмент для CDC-процессов, который уже внедрен в реестр отечественного программного обеспечения (ПО). На нем будут строиться в основном интеграции для передачи данных из всех систем в хранилище, на базе которого строятся практически вся отчетность банка.

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

Api Manager

 Как я писал ранее, в банке внедряется и запускается система API-менеджер. Собирается список уже существующих API, которые можно будет вывести на портал с минимальными доработками. Также собирается список продуктов и операций, которые мы в итоге хотим опубликовать в виде открытых API. Ниже – первая версия портала, но в 2024 году планируется его сделать полностью функциональным.

Ошибки, которых можно было бы избежать

Естественно на протяжении всего нашего пути развития мы допускали ошибки. Но, как говорится, не ошибается только тот, кто ничего не делает. Ниже я привел несколько моментов, на которых необходимо обращать внимание при развитие своего направления.

• При необходимости, дорабатывали смежные системы.
  
  Описание:  Иногда приходилось самим писать хранимые процедуры на базах других систем и создавать там некую структуру, необходимую по процессу. Как итог: у сотрудников должно было быть хорошее знание SQL, иначе не оптимально написанные запросы могли дать ненужную нагрузку на систему.
    Решение: Отказались от написания SQL в любом виде. Переложили данные задачи на подразделения, где SQL — основное направление. Во-первых, это снизило технические требования к разработчикам в подразделение, во-вторых, мы полностью сняли с себя ответственность за код, написанный в рамках других систем, что облегчило поддержку.

• ESB-монолит.
  
  Описание: В начале у нас была платная версия, из-за чего существовало ограничение по количеству экземпляров, которые мы могли использовать. Это накладывало большие проблемы в плане разграничения сервисов по критичности и влиянию их друг на друга.

  Решение: Распил шины на несколько экземпляров, но это стало возможно только после перехода на Open Source-версию.
   

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