![от ESB-монолита к целой линейке систем от ESB-монолита к целой линейке систем](https://habrastorage.org/getpro/habr/upload_files/74b/d97/d98/74bd97d98633c926a531a6f62f83d73c.jpeg)
Меня зовут Александр, я работаю в Московском Кредитном Банке (МКБ) с 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 шаблонов):
![шаблон шаблон](https://habrastorage.org/getpro/habr/upload_files/9a4/133/198/9a4133198a3fe917d073877e50273883.png)
![шаблон шаблон](https://habrastorage.org/getpro/habr/upload_files/0c8/57b/7d6/0c857b7d682cfaffff3f5f9cd47ff86d.png)
![И вот как может выглядеть итоговая схема И вот как может выглядеть итоговая схема](https://habrastorage.org/getpro/habr/upload_files/99f/fa3/dda/99ffa3dda4fd55fc0a68d2b067f000c6.png)
ВАЖНО! Мое подразделение занимается конкретно межсистемной интеграцией. Кому-то такие шаблоны покажутся уж очень банальными и очевидными, но наша задача и состоит в том, чтобы интеграция была простой, надежной и гибкой (при необходимости без проблем поменять системы источников, потребителей или же сам интеграционный слой).
Ну и конечно, чтобы каждый мог сделать правильный выбор шаблона, мы написали небольшую методичку. Ее мы сделали как можно проще, по факту там требуется ответить на 3 основных вопроса:
![та самая методичка та самая методичка](https://habrastorage.org/getpro/habr/upload_files/c4a/7c9/e2d/c4a7c9e2d460ecb10d803cc302dcc5ad.png)
Поехали!
Первыми нашими серьезными проектами, которые позволили подтвердить правильность наших выборов описанных выше, были:
замена АБС (Автоматизированная банковская система) системы в банке;
первый этап замены 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 году планируется запуск по нескольких пилотным проектам, после чего будем распространять данную практику по всем необходимым направлениям.
![Результаты первых тестов. Результаты первых тестов.](https://habrastorage.org/getpro/habr/upload_files/6ce/c7f/824/6cec7f8249a288d3f67a83d91e68cd4d.png)
FormIT (Informatica PWX)
Это еще один инструмент для CDC-процессов, который уже внедрен в реестр отечественного программного обеспечения (ПО). На нем будут строиться в основном интеграции для передачи данных из всех систем в хранилище, на базе которого строятся практически вся отчетность банка.
Преимущество этого решения, по сравнению с предыдущим, в том, что в банке уже накопилась хорошая экспертиза по продуктам от данного производителя, плюс есть официальная поддержка системы.
Api Manager
Как я писал ранее, в банке внедряется и запускается система API-менеджер. Собирается список уже существующих API, которые можно будет вывести на портал с минимальными доработками. Также собирается список продуктов и операций, которые мы в итоге хотим опубликовать в виде открытых API. Ниже – первая версия портала, но в 2024 году планируется его сделать полностью функциональным.
![](https://habrastorage.org/getpro/habr/upload_files/c94/557/cb0/c94557cb0705b0c6e312633d3203d8c6.png)
Ошибки, которых можно было бы избежать
Естественно на протяжении всего нашего пути развития мы допускали ошибки. Но, как говорится, не ошибается только тот, кто ничего не делает. Ниже я привел несколько моментов, на которых необходимо обращать внимание при развитие своего направления.
При необходимости, дорабатывали смежные системы.
Описание: Иногда приходилось самим писать хранимые процедуры на базах других систем и создавать там некую структуру, необходимую по процессу. Как итог: у сотрудников должно было быть хорошее знание SQL, иначе не оптимально написанные запросы могли дать ненужную нагрузку на систему.
Решение: Отказались от написания SQL в любом виде. Переложили данные задачи на подразделения, где SQL — основное направление. Во-первых, это снизило технические требования к разработчикам в подразделение, во-вторых, мы полностью сняли с себя ответственность за код, написанный в рамках других систем, что облегчило поддержку.-
ESB-монолит.
Описание: В начале у нас была платная версия, из-за чего существовало ограничение по количеству экземпляров, которые мы могли использовать. Это накладывало большие проблемы в плане разграничения сервисов по критичности и влиянию их друг на друга.Решение: Распил шины на несколько экземпляров, но это стало возможно только после перехода на Open Source-версию.
Поддержка своими силами.
Описание: Практически по каждой проблеме, связанной с интеграцией, приходилось подключать разработчика в нерабочие часы. Это, во-первых, создавало проблемы в рамках мотивации разработчиков, во-вторых, могли сдвигаться сроки по задачам, из-за необходимости присутствия сотрудников на разборах инцидентов.
Решение: Передача системы на поддержку. Да, этот процесс очень трудоемкий, требующий написание большого количества документации. Но в итоге — все в выигрыше.
dyadyaSerezha
Вот прям "как я"? Или "как мы"?
Точно из скоупа? Может, автор не знает значение этого слова, но зачем-то использует совершено ненужный здесь (и неверно примененный) англицизм?
drKlos Автор
Конечно же развитием интеграции занимаюсь не только я. Но хотелось рассказать именно свою историю, а когда долгое время являешься руководителем подразделения, история подразделения становится твоей историей. Я горжусь тем, что у нас в итоге получилось и какой вклад в это внёс я.
Согласен, некорректно выразился. Спасибо за замечание, буду исправляться.