Привет, Хабр! Меня зовут Саша Петраки, два года я занимаюсь разработкой интеграционных решений в К2Тех. И сегодня хочу рассказать, почему мы с командой снова задались вопросом: “Как связать воедино все информационные системы компании?” Казалось бы, ответ очевиден — настроить интеграции между ними. Но если раньше для решения этой задачи можно было использовать готовые импортные продукты, то сейчас необходим другой подход, причем сделать это, как правило, требуется максимально быстро.

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

Давайте начнем по порядку. А для этого нужно рассказать, почему ребята из ДВА пришли к нам с таким запросом:

Чтобы решить проблемы коллег из ДВА, которые вы видите на картинке, нам необходимо было: 

• Реализовать инструмент создания интеграций — как внешних, так и внутренних; 

• Найти  возможность удобного использования EIP для обеспечения необходимого уровня надежности обмена данными;

• Избежать повторения одних и те же рутинных обязательных шагов для реализации каждого интеграционного проекта: 

  • Настраивать инструменты логирования и мониторинга; 

  • Готовить инфраструктуру для наблюдения за интеграцией; 

  • Настраивать и поддерживать тестовый контур и т.д;

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

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

Было понятно, что проще всего взять что-то практически готовое — то есть OpenSource — и развить на базе набора инструментов настоящую платформу интеграции. Выбор встал между  решениями: nifi, Kafka connect и Apache Camel Karavan. И именно сравнение их характеристик (а также для сравнения IBM Integration Toolkit, с которым коллеги из ДВА уже работали ранее) приведено в таблице ниже:

Таблица 1. Сравнение наборов инструментов для интеграции с открытым исходным кодом

Учитывая, что мы видели четкую потребность самостоятельно дорабатывать систему и влиять на трек ее развития, команда изначально склонялась к использованию Karavan. Кроме этого, мы хотели получить высокий уровень изоляции сервисов, чтобы они существовали в отрыве от платформы. Вместе еще с парочкой второстепенных критериев все это сыграло в пользу Apache Camel Karavan.

Почему RIT— намного больше, чем Karavan

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

• Схемы взаимодействие со сторонним/проприетарным ПО;

• Рамки кастомизации и способы поддержки;

• Необходимый объем документации о функционировании интеграции и ее поддержка в актуальном состоянии;

• Типовые, прозрачные для понимания схемы интеграций;

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

И началась разработка. За 6 месяцев работы над проектом работы мы добавили:

• Поддержку Docker and Kubernetes;

• Расширенные возможности для работы с файлами проекта:

  • Инструментарий сравнения версий и файлов проекта;

  • Выбор файлов для комита в репозитории;

  • Откат изменений в незакомиченных файлах;

• Поддержку java агентов и бинарных файлов;

• Поддержку индивидуальных камлетов для проекта;

• Скрипты развертывания и возможность их конфигурирования;

• Средства мониторинга, логирования и трейсинга;

• Механизмы аутентификации и авторизации;

• Русифицированный интерфейс и документацию;

• Локальный Nexus-репозиторий (реестр maven-зависимостей, реестр docker‑изображений и dev-mode image).

Таким образом, на базе Apache Camel Karavan была создана платформа Roc Integration Toolkit, которая включает в себя возможности low-code и pro-code компонентов для построения интеграций. Причем со сборкой и запуском в один клик.

Таблица 2. Сравнение возможностей RIT и Karavan

Архитектура и технологический стек инструмента 

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

• Конструктор интеграционных взаимодействий - центральный интерфейс платформы, позволяющий разработчикам создавать и управлять своими интеграционными проектами с использованием low-code и pro-code инструментов. Стек: Java 21 + React + Apache Camel;

• Для кэширования файлов интеграционных проектов используется платформа Hazelcast;

• В качестве провайдера идентификации используется Keycloak;

• Для хранения файлов проектов используется Gitea (система для управления Git-репозиториями);

• В качестве репозитория для хранения и управления артефактами выступает Nexus. Но при желании его можно заменить на связку artifactory + registry, если это удобнее для какого-либо конкретного проекта;

• Стандартный стек мониторинга, логирования и трейсинга построен на базе Prometheus, Grafana, Loki, Tempo;

• Результатом создания интеграционного взаимодействия является Docker-контейнер (микросервис) - исполняемый экземпляр интеграционного взаимодействия (проекта), запущенный в dev/test/prod среде и решающий задачи подключения интегрируемых систем, преобразования протоколов обмена и форматов, передачу сообщений, отслеживания и фиксации ошибок.

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

Практические кейсы

Параллельно с развитием инструмента мы реализовали ряд проектов на базе Roc Integration Toolkit. Интересный кейс получился у клиента, которому нужно было обеспечить сбор геоданных от носимых устройств. Мы настроили передачу этих данных через mqtt сервер. На базе RIT была реализована трансформация этих данных с учетом требований системы-получателя и отправка в kafka очередь для последующей обработки в системе геопозиционирования, а также была добавлена глобальная обработка ошибок, передача сообщений, упавших с ошибками в "Dead letter queue".

В результате интеграция была обеспечена за 2 дня и протестирована в виде докер-контейнера. После этого мы сохранили ее в Git, сделали product-ready контейнер и оставили на нагрузочное тестирование на сутки. Метрики, которые получились по итогу, укладывались в заданные рамки. После этого были сгенерированы манифесты Kubernetes, артефакты были отданы в команду DevOps, которая развернула подготовленные контейнеры в кластере. 

Второй пример предоставила нам команда ДВА. При помощи платформы они реализовали промежуточный интеграционный сервис для своей ETL платформы. В данный сервис через REST-эндпоинт передается сообщение и команда, которую необходимо выполнить. Сервис получает из СУБД конфигурацию действий, которые необходимо выполнить, а также необходимые авторизационные токены. Сервис унифицирует процесс аудита и обработки ошибок.

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

Изменение подхода к разработке

С использованием RIT наша команда естественным путем пришла к изменению подхода к разработке интеграционных проектов благодаря следующим особенностям системы: 

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

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

• Теперь мы стараемся интегрировать документацию в саму интеграцию благодаря интерактивной схеме. Можно расписать, что делает каждый шаг интеграции. Это создает возможность участия в разработке  людей, которые не обязательно являются экспертами в программировании, но могут быть экспертами в области, для которой создается ПО;

• Так как сами интеграции — небольшие, а изменения в них — достаточно гранулярные, мы перешли на trunk-based работу с гитом. Эта схема хорошо сочетается с уже существующими CI тестами и позволила ускорить процесс выкатки обновлений интеграций;

• Приложения, создаваемые на платформе, нативно подходят под конфигурацию через CI (все настройки синхронизируются в docker-compose спецификации и в манифестах kubernetes), что улучшило наше взаимодействие с devOps командой, т.к. они видят:

  • весь список конфигурационных параметров, необходимых для запуска интеграционных сервисов; 

  • историю метрик приложения, что позволяет понять, сколько потребуется ресурсов для масштабирования; 

  • открытые эндпоинты и порты;

  • запросы секретов из внешнего хранилища;

• Механизм Camel Traces дал нам наглядные примеры преобразования  данных на каждом шаге интеграции. Это позволило нам самим создавать понятные цепочки преобразования  структуры данных в интеграции;

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

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

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

Однако у платформы есть и свои ограничения, обусловленные как природой Apache Camel, так и тем фактом, что платформа – это веб-приложение:

• Несмотря на большое количество технологий, предоставляемых Apache Camel из коробки, возможности low-code не позволяют покрыть все появляющиеся при разработке кейсы. Код все равно приходится писать руками. Благо платформа позволяет встраивать вызовы методов бинов в low-code маршрут;

• Интеграции реализуются на основе Apache Camel 4.8.0 (на момент написания этой статьи). Соответственно, необходимо понимание этого фреймворка;

• Приложение, реализованное в RIT, можно конвертировать в стандартный maven-проект при помощи camel-jbang export или, например, встроить в Spring Boot приложение в виде отдельного процесса (взаимодействующего с контекстом Spring). Однако если вам потребуется полностью переписывать приложение на ванильную java, нужно будет потратить на это некоторое время;

• Платформа ориентирована на создание микросервисов. Если на ней пытаться реализовать монолит,  вы получите излишне перегруженный интерфейс.

Заключение

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

Roc Integration Toolkit (RIT) — интеграционная low-code платформа (не путать с интеграционной шиной!). Ее основная задача – упрощать и ускорять (примерно в 2-3 раза в сравнении с кастомной реализацией) проектирование и реализацию интеграционных взаимодействий при помощи low-code и pro-code инструментов. RIT обеспечивает бесшовное подключение между различными приложениями:  связывает широкий перечень систем/СУБД/сервисов как напрямую в формате точка-точка, так и с использованием интеграционных шин/ брокеров.  

Термином low-code называют метод разработки, при котором к программированию «вручную» прибегают минимально. Вместо кода для моделирования приложений используются визуальные конструкторы, а для решения типовых задач — готовые скрипты.

Pro-code (programmatic tools) — тип предлагаемых разработчиком программного обеспечения инструментов для доработки приложения. Инструменты pro-code позволяют разработчикам создавать функциональность любой сложности, используя стандартные инструменты разработки.