Каталог на инфоблоках жил спокойно, пока ассортимент не вырос до сотен тысяч позиций, а трафик — до пиков, когда фильтр открывается по несколько секунд. Команда начинает думать: а что если вынести каталог в отдельный сервис? Идея правильная, но опасная. Выделить каталог — значит вмешаться в самую нагруженную и связанную часть магазина, и одно неверное решение о границах или синхронизации ломает не только каталог, но и заказы, и обмен с 1С.
Эта статья — о том, как выделить каталог в отдельный сервис на проекте с 1С-Битрикс и не сломать всё остальное: когда это вообще оправдано, где провести границу, как синхронизировать данные с инфоблоками и 1С, какой контракт API описать и как переключиться без простоя. Материал опирается на нашу практику аудита и оптимизации 1С и высоконагруженных проектов.
Коротко
- Микросервис каталога оправдан только на больших масштабах; сначала выжмите штатные механизмы и оптимизацию.
- Инфоблоки и 1С остаются источником правды, а сервис строит быстрый индекс для поиска и выдачи.
- Проведите чёткую границу по чтению витрины и опишите узкий контракт API, чтобы не размывать зоны ответственности.
- Обязателен запасной сценарий: при недоступности сервиса витрина деградирует к штатной выдаче, а не падает.
Когда каталог начинает тормозить монолит
Каталог — это сердце нагрузки интернет-магазина. Именно на нём сходятся поиск, фильтрация, сортировка, пагинация, вывод наличия и цен. На умеренном ассортименте штатные инфоблоки и торговый каталог справляются отлично. Проблемы начинаются на больших масштабах: десятки и сотни тысяч товаров, сложные фильтры по множеству свойств, высокий одновременный трафик.
Симптомы, при которых вообще стоит думать о выделении: умный фильтр открывается медленно даже с кэшем, поиск не держит нагрузку, а любое изменение логики каталога рискует задеть остальной сайт из-за плотной связности монолита. Важно: это не сигнал сразу пилить сервис — это сигнал сначала диагностировать причину, потому что часто дело в неоптимальных запросах и кэше, а не в архитектуре.
Что значит «микросервис каталога»
Микросервис каталога — это отдельное приложение, которое берёт на себя чтение витрины: поиск, фильтрацию, листинги и выдачу данных для карточек. Оно держит собственный оптимизированный индекс товаров и отвечает сайту на запросы быстро и предсказуемо, независимо от остального монолита.
Ключевые свойства такого сервиса:
- Специализация. Делает одну вещь — быстрое чтение каталога — и делает её хорошо.
- Независимое масштабирование. Его можно масштабировать отдельно от сайта под нагрузку каталога.
- Собственный индекс. Данные хранятся в форме, оптимальной для поиска и фильтрации, а не для редактирования.
- Чёткий контракт. Общается с сайтом через узкий API, не залезая в чужую логику.
Сначала выжмите штатные механизмы
Прежде чем городить сервис, честно ответьте: исчерпаны ли штатные возможности Битрикса? В большинстве случаев — нет.
Что стоит выжать до выделения: правильное кэширование умного фильтра и списков, композитный сайт для мгновенной отдачи статики, оптимизация запросов на D7, приведение свойств инфоблоков в порядок и грамотная инфраструктура. Как выстроить производительный фундамент, мы разбираем в статьях про D7 и ORM в Битрикс и про хостинг и инфраструктуру BitrixVM. Если после этого каталог всё ещё упирается в потолок — тогда выделение оправдано.
Где проходит граница сервиса
Самое важное решение при выделении — где именно провести границу. Ошибка здесь и есть тот самый способ «сломать всё остальное». Граница должна проходить по чтению витрины.
| Остаётся в Битриксе | Уходит в сервис каталога |
|---|---|
| Оформление заказа и корзина | Поиск по каталогу |
| Оплата и статусы | Умная фильтрация |
| Личный кабинет | Листинги и пагинация |
| Контент и SEO-страницы | Данные для карточек (чтение) |
| Обмен с 1С | Автодополнение и подсказки |
Правило простое: сервис отвечает за то, что показывается покупателю быстро и часто, — за чтение. Всё, что связано с деньгами, заказами и учётом, остаётся в монолите. Как только сервис начинает лезть в оформление заказа или редактирование данных, граница размывается и вся польза выделения теряется.
Кто источник правды: инфоблоки и 1С
Второй фундаментальный вопрос — кто хозяин данных. Ответ: инфоблоки и 1С остаются мастер-источником товаров, цен и остатков, а сервис каталога — это производная, быстрый индекс поверх них. Сервис ничего не редактирует; он только читает и отдаёт.
Такое разделение критично: если допустить, что и инфоблоки, и сервис могут менять одни и те же данные, неизбежен рассинхрон. Поэтому для каждого поля должно быть однозначно определено, где оно рождается. Товары и характеристики — в 1С и инфоблоках, наличие и цены — из обмена с 1С, а сервис лишь отражает их в своём индексе.
Синхронизация данных
Раз сервис — это индекс поверх инфоблоков и 1С, главная инженерная задача — держать его в актуальном состоянии. Синхронизация строится на событиях изменения данных.
- События инфоблоков. При изменении элемента (товар, цена, свойство) сервис получает сигнал и перестраивает свою часть индекса.
- Обмен с 1С. Обновления наличия и цен из учётной системы отражаются в индексе сервиса тем же путём.
- Очереди и фон. Перестройка индекса идёт асинхронно через очередь, чтобы не тормозить сохранение и обмен.
- Полная пересборка. Помимо инкрементальных обновлений держат механизм полной переиндексации на случай расхождений.
Чем ближе к реальному времени синхронизация, тем лучше, но полная точность в моменте не всегда нужна: небольшая задержка в отражении изменения свойства обычно допустима, а вот наличие и цена должны быть максимально свежими. Технику надёжного обмена и защиту точек интеграции мы разбираем в статье про REST, вебхуки и безопасность в Битрикс.
Контракт API между сайтом и сервисом
Сайт и сервис общаются через API, и качество этого контракта определяет, можно ли развивать обе стороны независимо. Хороший контракт — узкий, стабильный и версионированный.
- Узкий. Сайт запрашивает результаты поиска, отфильтрованные списки и данные карточек — и ничего лишнего.
- Стабильный. Фронт завязан на контракт, а не на внутреннее устройство сервиса; менять реализацию можно свободно.
- Версионированный. Изменения контракта вводятся через версии, чтобы не ломать работающий сайт.
- Кэшируемый. Ответы кэшируются, чтобы не дёргать сервис на каждый одинаковый запрос.
Ключевой принцип — сервис не диктует сайту своё внутреннее устройство. Обе стороны договариваются о контракте и живут по нему. Это тот же подход, что и при разработке любого модуля с внешним интерфейсом: мы описываем его в статьях про разработку модуля Битрикс и про более сложный модуль для Маркетплейса.
Запасной сценарий и деградация
Выделяя каталог в сервис, вы добавляете новую точку отказа: между сайтом и сервисом появляется сетевой вызов, а значит, сервис может стать недоступен. Витрина не должна падать целиком из-за этого.
Отсутствие такого сценария — самая частая причина, по которой выделение каталога «ломает всё остальное». Сервис упал, витрина легла, заказы встали. Продумайте деградацию заранее: это дешевле любого инцидента.
Как выделить без простоя
Переход на сервис делают поэтапно и параллельно, чтобы не останавливать продажи.
- Поднимите сервис рядом. Разверните его параллельно работающему сайту и наполните индекс данными из инфоблоков и 1С.
- Сверьте выдачу. Прогоните реальные запросы через сервис и сравните результаты со штатной выдачей — они должны совпадать.
- Переключите под флагом. Направьте часть трафика (например, только поиск) на сервис через фиче-флаг, оставив мгновенный откат.
- Расширяйте постепенно. Убедившись в скорости и корректности, переключайте фильтрацию и листинги.
- Держите откат наготове. На каждом шаге сохраняйте возможность вернуться к штатной выдаче одним переключением.
Такой подход с параллельной работой, сверкой и фиче-флагами позволяет выделить каталог без остановки магазина. Как безопасно выкатывать подобные изменения, описано в статье про CI/CD и деплой Битрикс.
Риски и как ими управлять
Выделение каталога — серьёзное архитектурное решение с реальными рисками. Их важно назвать заранее.
- Рассинхрон данных. В сервисе одно, в инфоблоках другое. Лечится единым источником правды и надёжной синхронизацией.
- Рост сложности эксплуатации. Ещё один сервис, который нужно мониторить и обновлять. Требует зрелого процесса.
- Размытие границы. Сервис постепенно забирает чужую логику. Лечится дисциплиной и узким контрактом.
- Новая точка отказа. Сетевой вызов между сайтом и сервисом. Лечится кэшем и деградацией.
Все эти риски управляемы, но требуют инженерной дисциплины. Если её нет, выделение принесёт больше проблем, чем пользы, — и штатный монолит с оптимизацией окажется правильнее.
Частые ошибки
- Выделять сервис вместо оптимизации. Проблема часто в запросах и кэше, а не в архитектуре.
- Размытая граница. Сервис лезет в заказы и редактирование, и польза выделения теряется.
- Двойной источник правды. И сервис, и инфоблоки меняют одни данные — гарантированный рассинхрон.
- Нет запасного сценария. Сервис упал — витрина легла целиком.
- Жёсткая завязка на внутренности. Фронт зависит от устройства сервиса вместо стабильного контракта.
- Синхронная перестройка индекса. Переиндексация тормозит сохранение и обмен вместо работы в фоне.
- Переключение без сверки и отката. Резкий переход на сервис без сравнения выдачи и возможности вернуться.
Чек-лист внедрения
- Причина подтверждена. Медленный каталог диагностирован, штатная оптимизация исчерпана.
- Граница проведена. Сервис отвечает только за чтение витрины; заказы и учёт — в монолите.
- Источник правды определён. Инфоблоки и 1С — мастер данных, сервис только читает.
- Синхронизация настроена. События инфоблоков и обмена с 1С обновляют индекс в фоне.
- Контракт API описан. Узкий, стабильный, версионированный, кэшируемый.
- Деградация продумана. При недоступности сервиса витрина работает на штатной выдаче.
- Переход поэтапный. Параллельная работа, сверка выдачи, фиче-флаги, мгновенный откат.
- Мониторинг готов. Отслеживаются скорость, доступность сервиса и расхождения индекса.
Вывод
Микросервис каталога — мощный инструмент для действительно больших магазинов, но не универсальное решение. В большинстве случаев штатные инфоблоки, умный фильтр и грамотная оптимизация закрывают задачу дешевле и без риска. Выделять каталог стоит только тогда, когда масштаб и нагрузка реально упёрлись в потолок монолита.
Если решение принято, ключ к успеху — дисциплина: чёткая граница по чтению витрины, единый источник правды в инфоблоках и 1С, узкий контракт API и обязательный запасной сценарий. Переходите поэтапно, со сверкой и возможностью отката, — и тогда каталог станет быстрым и независимым, а заказы, обмен с 1С и остальной сайт останутся целыми.
