Если ваш Битрикс тормозит, а Laravel кажется из другой вселенной — эта статья для вас.
Привет, хабровчане! На связи Алиса — тимлид в e-commerce агентстве KISLOROD. Мы ежедневно имеем дело с большими каталогами, сложной коммерцией и 1С, которая дышит в затылок. И однажды мы решили сделать невозможное: подружить Битрикс с Laravel. Так, чтобы Битрикс остался каноном и привычной админкой, а Laravel стал помощником — взял на себя API, тяжёлую бизнес-логику и все, что тормозит. Без форка ядра, слез SEO-шника и без утечек в 1С. Да, это реально.
Что будет внутри:
Архитектура «соседнего сервиса» — покажем, как Laravel становится полноценным соседом Битрикса, а не его врагом. Где провести границы, чтобы не сломать ничего важного.
JWT, SSO и Redis Streams без боли — авторизация, события и наблюдаемость: как соединить две платформы так, чтобы всё было прозрачно и надежно.
Очереди, вебхуки, кеш, наблюдаемость — разберем, как мы внедряли очереди событий, обрабатывали вебхуки с проверкой подписи и делали наблюдаемость без костылей.
Пошаговый план миграции с откатами и фича-флагами — как эволюционно мигрировать проект с Битрикса на Laravel, не выведя прод из строя.
Код, конфиги и живые примеры — не будет абстракций: только продовые конфиги, API-контракты и трейсинг с боевого проекта.
Кода будет много. Теории — ровно столько, чтобы вы могли повторить это у себя. Погнали!
Почему вообще это нужно
«Не трожь Битрикс — сломаешь 1С» — старая народная мудрость.
Если ваш проект на Битриксе вырос за пределы его изначальных возможностей, вы это чувствуете:
медленные каталоги, листинги, фильтры;
сложно внедрять новые бизнес-фичи без риска все сломать;
нет нормального API для фронтов и партнеров;
любая сложная логика превращается в компонент с бизнес-логикой размером с модуль CRM;
любая интеграция с внешними сервисами переходит в мини-движок с кастомным API, который сложно сопровождать.
Знакомо? Тогда давайте покажу, как мы пошли другим путем: без форка, без слома — через архитектурное разделение и разумный headless-подход.
Архитектура «Соседний сервис»: кто где живет и зачем
Представьте, что Битрикс — это Морфеус, а Laravel — Нео. Один знает, как устроен мир, второй — как его менять. В нашей архитектуре:
Битрикс продолжает управлять админкой, корзиной, UI, бизнес-логикой скидок, регистрацией заказов.
Laravel берет на себя все, что требует производительности, API-first мышления и легкой масштабируемости: каталог, фильтры, уведомления, интеграции.
Принципы взаимодействия:
Nginx маршрутизирует /bitrix/* в Битрикс, а /api/* в Laravel;
аутентификация и авторизация — через JWT (RS256) с публикацией JWK из Битрикса;
обмен событиями — через Redis Streams, в стиле outbox pattern.
Ножницы владения данными:
Битрикс пишет только в свои b_* таблицы;
Laravel — в svc_*;
взаимодействие строго через REST/AsyncAPI.
Шаг А: Аутентификация, события, наблюдаемость
Цель: создать фундамент для headless-подхода: единая авторизация, корректная передача событий и наблюдаемость всей архитектуры.
Что делаем:
реализуем мост SSO: пользователи логинятся через Битрикс, получают JWT в HttpOnly cookie, Laravel использует кастомный guard;
внедряем outbox-слой в Битрикс, чтобы гарантировать доставку событий в очередь (Redis Streams, RabbitMQ);
настраиваем наблюдаемость: X-Request-Id, трассировка запросов с OpenTelemetry, метрики Prometheus и алерты в Sentry.
Контракты | Метрики | Риски и откат |
REST: /auth/login, /auth/logout, /.well-known/jwks.json; AsyncAPI: catalog.events, order.events, stock.events, price.events. | логин: P95 < 300 мс; лаг публикации события: < 5 с; ошибки валидации JWT: < 0.5%. | SSO не работает? Laravel просто не пускает, а Битрикс продолжает работать по сессиям; Redis упал? Outbox не теряет данные — публикация догоняет после восстановления. |
Шаг Б: Каталог и OpenSearch
Цель: убрать основной тормоз Битрикса — это листинги, фильтры и каталог в целом. Мы хотим, чтобы пользователи не ждали по 5 секунд, пока откроется раздел, а получали быстрый отклик даже на больших выборках и с множеством фильтров.
Что делаем:
создаем денормализованный индекс в OpenSearch на основе таблиц svc_catalog_*, заранее подготавливая структуру под фасеты и фильтрацию;
Laravel раздает быстрые ответы по эндпоинтам /api/catalog/search, /api/products/{id} — с поддержкой сортировки, фасетных фильтров, fulltext и nested-атрибутов;
админка больше не «висит»: ленивые вкладки, кеш метаданных, быстрые справочники и автокомплиты позволяют работать без ожидания перезагрузки страницы;
подключаем отдельный медиасервис — он делает асинхронные ресайзы, готовит WebP и AVIF, отдает через CDN-ссылки.
Контракты и события:
REST: /api/catalog/search, /api/products/{id};
события: catalog.element.updated, price.changed, stock.changed.
Метрики:
TTFB каталог: < 150 мс на кэше, < 400 мс на миссе;
лаг реиндексации: < 10 с.
Риски: если OpenSearch упал — Laravel отдает кеш из Redis или заглушку.
Шаг В: Коммерция — корзина, цены, заказы
Цель: ускорить путь пользователя от выбора товара до успешного заказа и при этом существенно разгрузить Битрикс в самых уязвимых точках — корзине, расчете цен и создании заказов.
Что делаем:
переносим корзину в Redis, сохраняя полную совместимость с логикой sale. Пользователь продолжает работать с привычным интерфейсом, но данные обрабатываются быстрее и устойчивее;
цены и остатки теперь отдаются через API: мгновенный ответ из кэша, плюс персонализация (скидки, правила, группы пользователей), если нужно — с запросом к внутренним сервисам;
заказ создается с минимальным набором данных в b_sale_order для совместимости с UI и административкой. Вся остальная логика, маршруты, статусы, уведомления и интеграции уходят в Laravel и обрабатываются асинхронно.
Контракты: /api/cart, /api/pricing, /api/inventory, /api/orders
Метрики:
операции с корзиной P95: < 120 мс;
расчет цен P95: < 120 мс (кэш), < 300 мс (реальный вызов);
заказ: запись в Битрикс < 400 мс, саги Laravel < 60 с.
Риски:
конфликт логики скидок — проверка на стороне Битрикс;
откат — по флагу, данные совместимы.
Шаг Г: Интеграции и уведомления
Цель: собрать все внешние вызовы в одно место и вытащить из админки логику, которую туда когда-то «временно» положили. Больше никаких скриптов в init.php, чтобы синкать заказы с CRM или вручную слать уведомления.
Что делаем:
разворачиваем единый шлюз интеграций, через который проходят все внешние взаимодействия — 1С, CRM, платёжные шлюзы, доставки. Все это оформлено в отдельные каналы с retry, паузами, fallback и таймингами;
оборачиваем все в очередь с DLQ (dead letter queue), чтобы не терять события при сбоях. Плюс мониторим лаги и ошибки;
уведомления выносим в отдельный сервис, который работает через REST, поддерживает шаблоны писем и сообщений, учитывает приоритеты и предпочтения пользователя.
Контракты:
/api/integrations/*, /api/notify;
события статусов обратно в Битрикс и ERP.
Метрики:
интеграции P95: < 30 с;
уведомления: >98% доставляемости.
Риски:
если провайдер лег, очередь ставится на паузу;
спам — скоростные лимиты и троттлинг.
Шаг Д: Headless API и SDK
Цель: вытащить API наружу, чтобы фронты больше не зависели от внутренних модулей, бизнес-логики и тонкостей реализации. Меняем концепцию: не «Лезь в Битрикс за JSON», а «Обратись в стабильный API и получи то, что нужно».
Что делаем:
API Gateway на Laravel — единая точка входа (/v1/*) с версияцией, лимитами, ключами партнеров и всем, что положено продовому API;
SDK для фронтов — готовая библиотека с типами из OpenAPI, встроенными ретраями, трейсингом и логикой повторов. Работает одинаково на вебе и в мобильных.
Метрики:
Доля 5xx — менее 0,2%;
P95 отклика по кэшу — до 150 мс;
SDK покрыт автотестами и валидируется при CI-доставке.
Откат: если SDK вдруг перестал работать — фронт может напрямую ходить по REST, пока не починим. Все маршруты стабильны, структура API не меняется без версии. Теперь API — это контракт, не фреймворк. Вы можете менять фронт, деплоить виджеты, выносить в мобилки — и не трогать бэкенд вовсе.
Laravel и Битрикс — разные, но вместе работают круче. Headless-подход не требует рвать все на части — он требует осознанности, фича-флагов и нормальной архитектуры.
Так проект становится гибче, быстрее, масштабируемее. А главное — не превращается в «спагетти-код с криками в комментариях».
Продолжение следует...
Если статья зашла — покажите её тем, кто сомневается: а можно ли сделать современную архитектуру рядом с Битриксом? Можно. И нужно.
