30.06.2026 10:32
Wicort 0 4200 Источник

Привет, Хабр. Меня зовут Виктор Овчинников, я руковожу разработкой интеграционной платформы Digital Q.Integration в компании Диасофт.

Про то, как интеграционный слой убивает ИИ-проекты, я уже писал здесь и здесь. Про историю появления платформы — тридцать лет проектной боли и зоопарк западных ESB написал Дмитрий Гаврин в отдельной статье. Рекомендую прочитать, если не читали.

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

Почему не классический ESB

Коротко, потому что Дмитрий уже написал развёрнуто.

Классическая ESB — это монолитное ядро. Масштабирование только вертикальное. И при падении падает всё. Но самое болезненное для эксплуатации это то, что со временем шина становится местом, куда стекается вся прикладная логика. Через несколько лет она знает о бизнесе компании больше, чем любая из систем, которые к ней подключены. Разобраться в этом — отдельная задача. Это то нас и подтолкнуло к собственному подходу.

Мы сформулировали для себя так: возьмём лучшее из point-to-point и из ESB. Независимые сервисы — без централизованной бизнес-логики. Общий транспорт, общий мониторинг, общий инструментарий — как в ESB.

Концепция называется «умные сервисы и надёжные каналы».

Архитектура: каждая система — отдельный микросервис

Предлагаю посмотреть, как это работает. Для каждой интегрируемой системы создаётся независимый микросервис-коннектор. Он содержит ровно ту логику, которая нужна для взаимодействия с этой системой — и ничего лишнего. Адаптеры общаются через транспортный уровень, который отвечает за доставку и надежность.

Что это даёт:

  • Обновил один маршрут — задеплоил только один коннектор, всё остальное продолжает работать.

  • Нагрузка выросла на одном направлении — поднимаем дополнительные инстансы конкретного коннектора.

  • Один коннектор упал — остальные продолжают работать, очередь накапливается и обрабатывается после восстановления.

  • Чёткое разделение интеграционной и бизнес-логики обработки сообщений.

Каждый коннектор — это Spring Boot микросервис. Деплоится в Docker-контейнере, оркестрируется через Kubernetes. Добавлять узлы можно без остановки работающих сервисов.

Исполнительный движок: Apache Camel

Выбор фреймворка был принципиальным. Писать свой исполнительный движок с нуля — значит вместо решения прикладных задач годами поддерживать инфраструктурный код. Apache Camel — open source фреймворк с пятнадцатилетней историей, более 300 готовых компонентов, зрелое сообщество, активная разработка.

Компоненты покрывают практически всё, с чем встречается разработчик в реальных проектах: HTTP, JMS, Kafka, AMQP, SFTP, SQL, SOAP, REST, файловая система, облачные сервисы. Интеграция с Spring, Quarkus, MicroProfile — встраивается в любой современный микросервис без боли.

Camel мы взяли как основу и надстроили над ней то, чего не хватало для наших задач.

Camel DSL и визуальный дизайнер

Camel позволяет описывать интеграционные маршруты на своём Domain Specific Language. Это набор конструкций: откуда пришло сообщение, что с ним сделать, куда отправить. Читается почти как текст, пишется как код.

from("kafka:orders?brokers=localhost:9092&groupId=integration")
    .unmarshal().json(OrderDto.class)
    .choice()
        .when(simple("${body.amount} < 100000"))
            .to("jms:queue:auto-approve")
        .otherwise()
            .to("jms:queue:manual-review")
    .end();

Но разработчики в проектах — люди с разным уровнем погружения. Мы сделали визуальный дизайнер, где маршрут собирается из компонентов на схеме. Источник — Kafka-топик, задаёшь bootstrap.servers, topic, group.id. Трансформация — выбираешь паттерн из библиотеки. Назначение — очередь Artemis, REST-endpoint, файл, база данных.

По кнопке генерируется исполняемый микросервис — конфигурация Camel DSL + Dockerfile + манифест для Kubernetes.

Честно про low-code: это не «без кода вообще». Типичные задачи решаются визуально. Нестандартная логика — Java-класс через компонент Bean, скриптовые выражения (Groovy, MVEL, OGNL) прямо в маршруте, собственные компоненты с кастомной логикой. Никаких ограничений. Low-code снижает порог для типовых задач, но не заменяет код там, где он нужен.

Enterprise Integration Patterns

Camel реализует паттерны из книги Хоупа и Вулфа. Те, которые используются в продакшне чаще всего:

Content-Based Router — маршрутизация в зависимости от содержимого сообщения. Компонент Choice с условиями на языке выражений. Кредитные заявки до определённой суммы → автоматическое одобрение, выше порога → ручная проверка.

Content Enricher — компонент Enrich получает базовое сообщение, обращается за дополнительными данными к другой системе и объединяет результат. Входящий платёж → запрос в скоринговую систему → объединение данных → отправка в процессинг.

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

Splitter — разбивка одного сообщения на несколько для параллельной или независимой обработки.

Dead Letter Channel — сообщение, которое не удалось доставить после N попыток, уходит в отдельный канал для ручного разбора. Критично для финансовых операций.

Трансформация форматов встроена: JSON ↔ XML ↔ CSV. Для сложных случаев — Java или скриптовые выражения.

Транспортный уровень: Artemis и Kafka

Здесь надо говорить предметно, потому что это именно то место, где у многих возникает вопрос «а зачем два разных инструмента».

ActiveMQ Artemis

Artemis — это не «новая версия» классического ActiveMQ. Это полностью переписанный с нуля проект. Почему он быстрее, чем кажется по описанию:

Неблокирующий I/O через Netty. Вместо создания потока на каждое соединение — один поток обрабатывает тысячи одновременных подключений. Это радикально снижает накладные расходы и позволяет держать большое количество параллельных соединений без деградации.

Журналирующее хранилище (append-only log). Когда сообщение нужно сохранить на диск, Artemis не пишет его в случайное место — он записывает в конец последовательного журнала. Последовательная запись — самая быстрая дисковая операция. Отсюда высокая скорость работы с персистентностью при низкой задержке.

Внутренний пул объектов. Вместо постоянного создания и удаления объектов сообщений в памяти — переиспользование. Минимальная нагрузка на сборщик мусора в JVM.

Artemis поддерживает несколько протоколов из коробки: Core (нативный), AMQP, MQTT, STOMP, OpenWire, HornetQ. Это значит, что к одному и тому же брокеру можно подключить системы на разных технологических стеках без мостов и конверторов.

Гарантии доставки — то, за что мы выбрали Artemis для транзакционных сценариев:

  • Durable Subscriptions — если потребитель отключился, сообщения, отправленные за это время, будут доставлены ему при возврате. Критично для систем с нестабильным подключением.

  • JMS-транзакционность — несколько операций отправки/получения как одна атомарная транзакция. Либо всё, либо ничего.

  • Dead Letter Queue — сообщение, которое не удаётся доставить после N попыток, уходит в DLQ. Вы видите его, можете разобрать вручную или перезапустить обработку.

  • Политики повторной доставки — настраиваемая задержка между попытками, максимальное количество попыток, экспоненциальный backoff.

Кластеризация: Master-Slave репликация через Shared Store (общий диск) или Replication (синхронная репликация журнала по сети без общего диска), симметричный кластер для балансировки нагрузки.

Apache Kafka

Kafka — это распределённый append-only лог. Данные организованы в топики, каждый топик разбит на партиции, партиции распределены по узлам кластера. Каждое сообщение в партиции имеет уникальный офсет.

Фундаментальное различие с Artemis — в том, кто умный: Artemis — умный брокер / простой клиент. Kafka — простой брокер / умный клиент.

Artemis управляет очередями, подписками, доставкой сам. Клиенту не нужно об этом думать. Kafka просто хранит лог. Клиент сам помнит свой офсет, сам решает, с какого места продолжить чтение, сам управляет группой потребителей. Это делает брокер проще и легче масштабируемым горизонтально.

Когда выбираем Kafka:

  • высокая пропускная способность (гигабайты в секунду, миллионы сообщений);

  • горизонтальное масштабирование через партиции;

  • replay событий — нужно перечитать историю заново;

  • event sourcing, event-driven архитектура;

  • потоковые данные для ИИ-сценариев с требованием задержки в десятки миллисекунд.

Когда выбираем Artemis:

  • транзакционность и JMS-семантика;

  • низкая задержка для единичного сообщения при умеренной нагрузке;

  • сложная маршрутизация и фильтрация на стороне брокера;

  • мультипротокольный ландшафт (AMQP, MQTT, STOMP — разные системы к одному брокеру);

  • финансовые транзакции с гарантией at-least-once или exactly-once и DLQ.

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

BPMN 2.0 внутри платформы

Встроенный BPMN-редактор решает конкретную проблему: бизнес-аналитик и разработчик работают в разных нотациях и теряют контекст при передаче требований.

Когда BPMN встроен в ту же платформу, аналитик рисует сквозной бизнес-процесс и отмечает точки интеграции с внешними системами. Разработчик настраивает маршруты передачи данных именно в этих точках — в том же инструменте, без перевода между нотациями.

Для эксплуатации это даёт полную видимость процесса от начала до конца с мониторингом в реальном времени: какой шаг выполнился, сколько времени занял, что передалось между шагами. Если произошла ошибка — видно точно на каком шаге и с какими данными.

Для финансового сектора это требование, а не удобство: обработка кредитной заявки проходит через десяток систем, и восстановить картину инцидента без истории выполнения процесса — долгая ручная работа.

Форматы и протоколы

Платформа обрабатывает всё, что встречается в корпоративных ландшафтах:

Форматы: XML, JSON, CSV, Excel (.xlsx, .xls — с сохранением структуры листов и ячеек), PDF (с извлечением текстового слоя), ODF, ZIP/RAR/7-Zip — включая архивы с паролем.

Конкретный кейс: система автоматически забирает ZIP-архивы с FTP-сервера контрагента, распаковывает, извлекает Excel-файлы, трансформирует данные в нужный формат и отправляет в целевую систему. На схеме в визуальном редакторе — три компонента.

Протоколы: HTTP/HTTPS (REST, SOAP), FTP/FTPS, IMAP/IMAPS, gRPC (вызов внешних и предоставление собственных), SSH (команды на удалённых серверах — интеграция с legacy без API), JMS через AMQP/OpenWire/MQTT/STOMP, Kafka, OData.

OData — важно для российских ландшафтов: коннектор к 1С через OData включён в базовую поставку.

Производительность

4 000 TPS — цифра из нагрузочного тестирования. Конфигурация: 2 CPU, 2 GB RAM, один поток, одна очередь. Это базовое железо, не production-сервер.

В базовой конфигурации самого брокера (Intel Celeron, один поток отправителя, один получатель, одна очередь) — 2 000 сообщений в секунду. В иных конфигурациях — 20 000+.

Горизонтальное масштабирование без архитектурных ограничений: каждый адаптер масштабируется независимо. Нагрузка выросла на одном направлении — запускаем дополнительные инстансы именно этого адаптера.

Полный отчёт с методикой, конфигурацией стенда и результатами: q.diasoft.ru/upload/download/Report_load_testing2025.pdf. Там открыто — что тестировалось, на чём, как.

Что не работает и о чём стоит знать заранее

Мало публичных кейсов. Четыре задокументированных проекта на сайте. Банковских и финансовых внедрений больше, большинство клиентов не готовы раскрывать детали. Это реальность финансового сектора.

Миграция — это не только техника. Самое трудоёмкое при переносе с другой платформы — не перенастройка маршрутов, а понимание бизнес-логики, которая за годы осела в шине. Документации обычно нет. Это занимает больше времени, чем сам технический перенос.

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

Попробовать

Бесплатный дистрибутив можно скачать здесь. Dev/test среды не лицензируются — скачать и запустить первый интеграционный поток можно самостоятельно.

Вопросы по архитектуре или конкретным кейсам — пишите в комментарии, отвечу. Или напрямую: integration@diasoft.ru.

Комментарии (0)