Назначение и границы основных компонентов MTB ESB Next Gen.

Компоненты платформы

Компоненты ESB разделены по ответственности. Таблица ниже помогает быстро понять, куда относится изменение или проблема.

Рабочие порталы: MTB Swagger для API reference и Flows для бизнес-процессов и интеграционных схем. Общие возможности WSO2 описаны в официальной документации API Manager.

Компонент	Назначение	Не должен использоваться для
WSO2 API Manager	API lifecycle, gateway, auth, policies, portal	Сложной доменной бизнес-логики
Event Router	Выбор маршрута и публикация в целевой topic	Хранения бизнес-данных
Apache Kafka	Надёжный транспорт сообщений и событий	Бессрочного архива и system of record
Kestra	Оркестрация многошаговых процессов	Простого proxy-вызова без orchestration
Adapter	Интеграция с конкретной целевой системой	Общей логики всех доменов
Callback Service	Асинхронная доставка результата consumer	Основной обработки бизнес-операции
PostgreSQL	Служебное состояние компонентов	Централизованного хранилища payload всех интеграций
Observability stack	Логи, метрики, трассы и диагностика	Хранения чувствительных payload без политики

WSO2 API Manager

WSO2 формирует consumer-facing слой платформы.

В его состав входят:

API Gateway — принимает runtime-трафик и применяет политики;
Publisher — используется создателями и владельцами API;
Developer Portal — каталог API для потребителей;
Admin Portal / Carbon — административные функции;
API Controller (apictl) — перенос API-артефактов и CI/CD-операции;
служебные базы данных — метаданные API, подписки, приложения, политики и users/roles.

Доступ к административным интерфейсам

Publisher, Admin Portal и Carbon — не пользовательские API endpoints. Они должны иметь отдельные правила доступа и не публиковаться как consumer-facing сервисы.

Event Router

Event Router связывает внешний API-маршрут с внутренней топологией сообщений. Он принимает нормализованный запрос, применяет routing rule и публикует сообщение в нужный Kafka topic.

Routing rule должна быть прозрачной и управляемой: источник правила, владелец, входные условия и целевой topic фиксируются в реестре.

Apache Kafka

Kafka предоставляет транспортный слой между Gateway, Router, Kestra, адаптерами и callback-механизмом.

Для каждого topic определяются:

каноническое имя;
назначение и владелец;
producer и consumer;
partitions и message key;
schema или формат envelope;
retention;
retry и DLT/DLQ strategy.

Kestra

Kestra выполняет декларативные flows для сложных интеграционных сценариев. Flow хранится как версионируемый YAML-артефакт и проходит контролируемое продвижение между окружениями.

Kestra отвечает за последовательность шагов и их техническое выполнение, но не заменяет формальное описание бизнес-процесса и ownership операции.

Adapters

Адаптер принадлежит конкретной целевой системе или ограниченному интеграционному домену. Он:

принимает платформенное сообщение;
проверяет необходимый контракт;
преобразует данные и протокол;
вызывает целевую систему;
нормализует результат или ошибку;
сохраняет trace и correlation context.

Callback Service

Callback Service доставляет потребителю результат асинхронной обработки. Он управляет разрешённым callback endpoint, защищённой доставкой, повторными попытками и наблюдаемостью результата.

Identity-механизмы устанавливают доверенную идентичность приложения или пользователя. Канонический X-Consumer-ID определяется платформой на основании проверенных credentials или token claims, а не принимается как доверенное значение из произвольного заголовка.

Observability

Каждый компонент должен поддерживать единый trace context и структурированное логирование. Минимальная диагностическая связка:

Consumer ID + External Request ID + traceparent + component + environment

Idempotency-Key является отдельным бизнес-идентификатором и не заменяет trace или request ID.

Компоненты