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

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

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

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

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

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?

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