Консультирование по архитектуре решений 1С-Битрикс

Консультирование по архитектуре решений 1С-Битрикс

Архитектурные решения принятые в начале проекта определяют стоимость каждой следующей функции. Неправильный выбор — хранить данные в свойствах инфоблока вместо отдельных таблиц при объёме 100 000 элементов — через два года обернётся невозможностью выполнять простые выборки за разумное время. Переделка обходится в 10–30 раз дороже, чем правильный выбор в начале.

Типичные архитектурные развилки

Инфоблоки vs. ORM-таблицы. Инфоблоки универсальны и управляются через административный интерфейс — хорошо для контента. Но при сложных связях, высокой частоте записи или нестандартных запросах пользовательские ORM-таблицы (\Bitrix\Main\ORM\Data\DataManager) работают в 5–50 раз быстрее.

Правило: если данные редактируются через административный раздел редакторами — инфоблок. Если данными управляет только код (логи, очереди, события, транзакции) — ORM-таблица.

Монолит vs. модульная архитектура. На старте удобно писать всё в одном кастомном компоненте. Через год этот компонент на 3 000 строк невозможно тестировать и сложно передать другой команде. Модульный подход: /local/modules/company.module_name/ с чётким публичным API, событиями и зависимостями через Composer.

AJAX-компоненты vs. SPA-подход. Битрикс поддерживает оба подхода. AJAX-компоненты (bitrix:main.loader) работают нативно с ядром, но ограничены в возможностях. SPA на React/Vue (через bitrix:ui.sidepanel или полноценный SPA) даёт лучший UX, но требует отдельного API и усложняет SSR/SEO.

Кеширование. Битрикс предоставляет несколько слоёв:

Выбор редакции и лицензии

Редакция определяет доступные модули: b2b, catalog (торговый каталог B2B), sale.crm (CRM-интеграция в заказах).

Интеграция с 1С: архитектурные решения

Классический обмен через CommerceML (файловый обмен) работает до ~50 000 SKU. При большем объёме или требовании реального времени нужен REST-обмен через API 1С или промежуточный брокер сообщений (RabbitMQ).

Архитектура с брокером: 1С → публикует событие в RabbitMQ → Битрикс-воркер подписывается и обрабатывает → обновляет данные в real-time. Задержка — секунды вместо часов при файловом обмене.

Кейс: B2B-платформа, 500 000 SKU

Задача: интернет-магазин для корпоративных клиентов с индивидуальными ценами, квотами и условиями доставки для каждого контрагента.

Проблемы стандартного подхода:

• Хранение цен в b_catalog_price — 500 000 SKU × 200 групп покупателей = 100 млн записей, любой запрос цены > 500 мс
• Фильтр каталога по свойствам инфоблока — sequential scan на таблице с 5 млн строк свойств
• Корзина и заказы стандартного sale не поддерживают квоты и условия по контрагенту

Архитектурное решение:

• Цены вынесены в отдельную ORM-таблицу bl_b2b_price с индексом по (user_group_id, product_id) — запрос цены 5 мс
• Фильтр через ElasticSearch (интеграция с Битрикс через кастомный компонент)
• Стандартный sale расширен модулем company.b2b_sale — добавлены поля контрагента, квот и специальных условий
• Цены из 1С передаются через RabbitMQ → воркер обновляет bl_b2b_price в реальном времени

Результат: страница каталога с фильтром грузится 300 мс, обновление цен из 1С — до 30 секунд вместо 4 часов.

Что входит в консультирование по архитектуре

• Анализ бизнес-требований и ограничений (трафик, объём данных, бюджет)
• Сравнение архитектурных вариантов с оценкой рисков и стоимости
• Выбор редакции Битрикс, состава модулей
• Проектирование схемы данных и структуры модулей
• Архитектура интеграций с 1С и внешними системами
• Рекомендации по стеку (кеш, поиск, очереди)
• Документ «Архитектурное решение» для команды разработки