Архитектура

Интеграционная архитектура: API gateway, ESB и event bus в современном предприятии

Интеграционный слой — фундамент всей цифровой трансформации. Без него каждое новое приложение строит интеграции заново, стоимость владения растёт нелинейно, а изменения в одной системе ломают пять других. Эта статья разбирает три модели интеграции — API gateway, ESB, event bus — и объясняет, как их сочетать в зрелом ландшафте.

Обсудить задачу

Эта архитектурная статья разбирает три модели интеграционного слоя — API gateway, ESB, event bus — и подход к их сочетанию в зрелом enterprise-ландшафте.

В чём архитектурный вызов

Большинство предприятий региона имеют десятки систем, накопленных за 10-20 лет. Каждая система интегрирована со смежными точечно — синхронным API, файлом, прямым доступом к базе. Через несколько лет формируется паутина зависимостей, в которой никто не знает полной картины. Каждое новое требование задевает 5-10 систем, изменения становятся медленными и опасными. Интеграционный слой — это не один продукт, а архитектурное решение, объединяющее API gateway, ESB и event bus в зависимости от характера взаимодействия.

Какие системы, потоки и команды вовлечены

API gateway — единая точка входа для синхронных запросов, контроль доступа, лимитирование, версионирование API
ESB (Enterprise Service Bus) — оркестрация сложных межсистемных процессов, трансформация форматов, гарантия доставки
Event bus — асинхронная шина событий для реактивной интеграции (Kafka, RabbitMQ, AWS Kinesis)
Каталог сервисов и API — обнаружение, документация, мониторинг использования
Слой безопасности — OAuth, mTLS, audit log, контроль контрактов
Observability — distributed tracing, метрики, логирование сквозь все системы

Типичные архитектурные ошибки

Использование API gateway как универсального решения, в том числе для асинхронных и долгих процессов — нарушение архитектурного назначения
ESB как мусорный бак для логики — все правила и преобразования встроены в шину, бизнес-логика теряется
Event bus без схем и контрактов — публикуются события произвольного формата, потребители ломаются при каждом изменении
Отсутствие каталога API — разработчики не знают, что уже есть, дублируют функциональность
Синхронные межсервисные вызовы через event bus — задержки растут, отказ одного сервиса валит цепочку
Нет версионирования API — изменение ломает всех существующих потребителей

Возможные подходы

API gateway для синхронных бизнес-API — для каналов и партнёров. С контролем доступа, лимитами, версионированием.
Event bus для асинхронных взаимодействий — все доменные события публикуются как факты, потребители реагируют на них в своём темпе
ESB для оркестрации сложных многоэтапных процессов — там, где нужна гарантия выполнения и компенсация при сбоях
Schema registry для контроля совместимости событий и API — обязательная часть зрелого ландшафта
Каталог сервисов и контрактов — единый источник истины для всех команд разработки

Как обойтись без замены ядра

Интеграционный слой строится вокруг существующих систем, не вместо них. Старые системы остаются источниками истины по своим доменам — слой добавляет асинхронные потоки событий и API для каналов. Постепенно функциональность выносится из старых систем по мере их устаревания, но это не предпосылка построения слоя, это его естественное продолжение через 2-3 года.

Риски, зависимости, ограничения

Зависимость от качества данных в источниках — слой не исправит мусорные данные АБС
Производительность шины при росте объёма — требует мощностей и наблюдаемости
Сложность отладки распределённых процессов — обязателен distributed tracing
Зрелость команды эксплуатации — без on-call для шины и наблюдаемости интеграционный слой становится узким местом
Безопасность каждого канала и каждого API — отдельная работа, не дополнение

Как выглядит фазовый путь

Месяцы 1-3: дизайн целевой интеграционной архитектуры, выбор технологий, формирование команды интеграции
Месяцы 4-9: внедрение API gateway для каналов и партнёров, базового event bus, observability
Месяцы 10-15: миграция первых 5-10 ключевых интеграций на новый слой, отказ от точечных интеграций по мере готовности
Месяцы 16-24: ESB для сложных процессов, schema registry, каталог сервисов
После 24 месяцев — постепенное расширение, плановая миграция оставшихся точечных интеграций по приоритету

→

Что ещё стоит изучить

Темы из этой же области, которые часто разбираем вместе с этой

Решение

Это не только статьи

Об этом не просто пишу — могу прийти, разобрать вашу ситуацию и спроектировать решение под ваш контур.

Обсудить применение →

← Назад

Готовы обсудить вашу задачу?

Расскажите, что не работает или что нужно построить. Первый разговор — без обязательств.

Обсудить задачу Написать в Telegram

Обычно отвечаю в течение нескольких часов