ESB vs API Gateway: как выбрать интеграционный инструмент без ошибок

Вступление от Максима Кулагина, менеджера продукта 7Tech Integra в интеграционных проектах ООО «Севентек».

Интеграция распадается на два класса задач: глубокая связка внутренних систем с разными протоколами и безопасная выдача API наружу с контролем трафика и доступа.

Эта статья разбирает различия ESB и API Gateway на языке решений: где какой инструмент закрывает задачу, как избежать архитектурных ловушек и почему гибридный подход часто выигрывает.

ESB — архитектурный шаблон и программный слой, который обеспечивает обмен сообщениями, маршрутизацию, трансформацию форматов и преобразование протоколов между неоднородными приложениями в рамках SOA/EAI. Типовые функции включают контент-ориентированную маршрутизацию, протокольные мосты (HTTP, JMS, FTP), адаптеры к легаси-системам, а также трансформации на нескольких уровнях: преобразование форматов (XML, JSON, CSV, EDI, IDoc), изменение структуры сообщений (агрегация, разбиение, обогащение), и приведение типов данных и кодировок — плюс управление последовательностью сообщений. Это уместно, когда внутри предприятия живут десятки систем с несовпадающими схемами и транспортами, и требуется стандартизованный обмен с гарантией доставки.

Вопреки распространенному мнению, ESB — это не просто «центральная шина» со всеми вытекающими. Это скорее архитектурная платформа, эффективность которой напрямую зависит от качества проектирования: правильно построенная централизация не создает проблем, а дает тотальный контроль над потоками. Итог: ESB сильнее всего именно там, где нужна «глубина» интеграции — богатые адаптеры, сложные оркестрации, протокольные преобразования и смешанный синхронно-асинхронный обмен.

API Gateway — это точка входа в API и микросервисы, которая решает сквозные нефункциональные задачи: аутентификация, авторизация, rate limiting, трафик-менеджмент, кеширование, мониторинг, девпортал, версия API. Его зона ответственности — безопасная экспозиция API внутренним и внешним потребителям, стандартизация политики доступа и повышение наблюдаемости. В современном API‑first/микросервисном стеке это базовый элемент на периметре.

Важно держать Gateway «тонким»: бизнес-логика и сложные процессы живут в сервисах, а не в прокси-слое; перегрузка Gateway логикой — распространенный антипаттерн. При этом связка Gateway+Serverless допускает выполнение обработчиков запросов вне серверов, но сам Gateway остается периметром и маршрутизатором.

Совмещение даёт выигрыш: ESB решает глубокую медиaцию и протокольные мосты между системами, а Gateway обеспечивает безопасную, наблюдаемую выдачу сервисов наружу и внутрь через стандартизованные API. Такой фасад снижает плотность связей, упрощает контроль доступа и ускоряет эволюцию интерфейсов, не ломая внутренние потоки.

«Держите API Gateway тонким: политики доступа, лимиты, трассировка и канареечные релизы — да; агрегация данных и обогащение с внешними зависимостями — в сервисах или интеграционном слое».

Интеграционная платформа «Интегра» (7TECH INTEGRA 2.0) — корпоративная шина для объединения баз данных, приложений и сервисов в единый ИТ‑ландшафт с готовыми коннекторами (HTTP, SQL, RabbitMQ, SMB, Email), реактивным ядром для высокой нагрузки и встроенным мониторингом. Платформа поддерживает кластеризацию, очередность и гарантию доставки, низкий порог входа через low‑code, а также on‑prem и cloud‑модель — что упрощает построение гибридной архитектуры совместно с API‑шлюзом. На главной странице доступен демодоступ к платформе и подробности о сценариях для финансового сектора, ритейла, здравоохранения, телеком‑компаний и госсектора.

«Сначала договоритесь о границах ответственности слоев и о метриках успеха: p95‑задержка, бюджет ошибок, время отката. Технология — лишь средство выполнить эти договоренности».

Чем ESB отличается от API Gateway в одном предложении?

ESB интегрирует разнородные внутренние системы через медиaцию и адаптеры, а API Gateway управляет доступом и качеством потребления API на периметре.

Можно ли обойтись без ESB в микросервисной среде?

Да, если нет легаси‑протоколов и сложных трансформаций; тогда достаточно сервисов и API‑шлюза, соблюдая принцип «тонкого гейтвея».

Где держать оркестрации и агрегации данных?

В бизнес‑сервисах или интеграционном слое, но не в гейтвее, который отвечает за политику и безопасность.

Как снизить риск SPOF у ESB?

Избегать гиперцентрализации, проектировать кластер, распределять ответственность, следить за конфигурационной сложностью.