Привет, Хабр. Меня зовут Виктор Овчинников, я руковожу разработкой интеграционной платформы 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.
ссылка на оригинал статьи https://habr.com/ru/articles/1053890/