В крупных компаниях и ведомствах ядро автоматизации работает по 10–15 лет. АБС, биллинг, учётные системы на Oracle и 1С, обмен по SOAP или плоским файлам через сетевую папку. Эти системы нельзя выключить на выходные и переписать. При этом бизнес требует мобильных приложений, личных кабинетов и витрин данных для смежных ведомств. Прямая интеграция «каждый с каждым» превращается в клубок из десятков точечных коннекторов, который никто не решается тронуть. API-шлюз разрывает этот клубок – он становится единственной управляемой границей между старым контуром и новыми каналами.

Шлюз как фасад над legacy

Главная идея – не трогать ядро. Шлюз публикует чистый REST/JSON наружу, а внутри транслирует вызовы в тот протокол, который понимает legacy: SOAP, XML-RPC, хранимую процедуру в БД, выгрузку файла по расписанию. Старая система продолжает работать в своём ритме, а потребитель видит современный контракт.

Что разумно вынести на уровень шлюза, а не в каждую систему по отдельности:

  • Аутентификацию и авторизацию. OAuth 2.0 для внешних клиентов, проверка подписи для межведомственного обмена, маппинг на технические учётки legacy.
  • Версионирование контрактов. /v1, /v2 живут параллельно, пока потребители не мигрируют. Старая система при этом не меняется.
  • Квоты и троттлинг. Legacy-ядро держит сотни запросов в секунду, а не тысячи. Шлюз сглаживает всплески и защищает БД от перегрузки.
  • Логирование и аудит. Единая точка для трассировки запросов – критично для госсектора и проверок.

Когда внешний канал – это мобильное приложение, шлюз заодно решает задачи, о которых мы писали в мобильной разработке B2B: агрегацию нескольких внутренних вызовов в один ответ и адаптацию форматов под слабую сеть.

Strangler: замена ядра по частям

Шлюз – это ещё и инструмент постепенной миграции. Паттерн Strangler Fig работает так: новый сервис перехватывает один маршрут (например, выписку по счёту), отдаёт ответ сам, а всё остальное шлюз по-прежнему проксирует в старую систему. Потребитель не замечает, где именно обрабатывается запрос.

Так мы переносим функциональность модуль за модулем, без «большого взрыва» и риска остановить бизнес. Через год-полтора legacy-ядро может остаться только за двумя-тремя редкими операциями, а новые сервисы уже несут основную нагрузку. Новые сервисы удобно собирать в контейнерах – про развёртывание оркестратора в собственном ЦОД мы разбирали в запуске Kubernetes через kubeadm.

Где шлюз помогает, а где мешает

Шлюз – не серебряная пуля. Он добавляет сетевой хоп и точку отказа, поэтому его резервируют и мониторят как критичный узел. Не стоит закладывать в шлюз бизнес-логику – он должен оставаться тонким: маршрутизация, трансформация, безопасность. Тяжёлую логику и аналитику выносите в отдельные сервисы; для ML-задач это могут быть открытые фреймворки, которые шлюз просто публикует наружу как обычный эндпоинт.

Технически выбор сегодня небольшой и зрелый: Kong поверх nginx, WSO2 API Manager для тяжёлой корпоративной интеграции, либо собственная сборка на nginx + Lua, когда нужен полный контроль и работа в закрытом контуре без выхода в интернет.

Вывод

API-шлюз не заменяет интеграцию, а делает её управляемой: одна граница, единые правила безопасности, версии контрактов и возможность переписывать ядро по частям. Для legacy-ландшафта это самый дешёвый способ открыть данные новым каналам, не рискуя продакшеном. Путь от аудита текущего обмена до промышленной эксплуатации укладывается в поэтапную миграцию через шлюз, когда старое ядро заменяется по частям без остановки бизнеса.