Проектирование архитектуры проекта на 1С-Битрикс

Проектирование архитектуры проекта на 1С-Битрикс

Мы часто видим проекты, где архитектурные решения принимались на ходу. Через год сайт начинает тормозить на каталоге из 50 000 товаров, добавление нового свойства требует правки в четырёх местах, а обмен с 1С — скрипт на 2000 строк без документации. Чаще всего проблемы проявляются не сразу. На этапе запуска всё работает, но через полгода активной работы каталога с 50 000 товаров и 20 000 посетителями в день начинаются падения. Причина — неоптимальная структура инфоблоков, отсутствие кеширования и бизнес-логика, размазанная по шаблонам. Результат: каждый запрос генерирует 30+ SQL-запросов, страница грузится 5–7 секунд. Посетители уходят, конверсия падает, поддержка захлебывается в баг-репортах. Каждое новое свойство — боль, каждый обмен с 1С — стресс. Нагрузка 20 000 посетителей в день — не предел: при пиковых значениях в праздники сайт может лечь полностью. Мы проектируем архитектуру так, чтобы этого не произошло. Свяжитесь — бесплатно оценим ваш проект.

Слои архитектуры Битрикс-проекта

Битрикс имеет несколько уровней, и решения на каждом влияют на другие. Рассмотрим ключевые.

Уровень данных: инфоблоки, HL-блоки, пользовательские таблицы

Инфоблоки (b_iblock_element, b_iblock_element_property) — гибкий EAV, но на больших объёмах (>100 000 элементов) производительность падает. Ключевые решения:

• Распределение данных: инфоблоки для основного контента, HL-блоки для справочников, собственные таблицы через D7 ORM (\Bitrix\Main\ORM\Data\DataManager)
• Структура типов инфоблоков и их группировка
• Схема торговых предложений: один инфоблок офферов на всё или раздельные на категории

В официальной документации 1С-Битрикс подчеркивается: «Инфоблоки предназначены для хранения контентных данных, а HL-блоки — для справочников и вспомогательных сущностей». Хранилище на HL-блоках работает в 3 раза быстрее при выборке 10 000 записей, чем EAV-инфоблок с десятком свойств.

Уровень логики: компоненты vs. собственный код

Стандартные компоненты (bitrix:catalog.section, bitrix:sale.order.ajax) покрывают типовые сценарии. За их пределами выбирают: расширять шаблон, создавать кастомный компонент (CBitrixComponent) или писать контроллер D7 (\Bitrix\Main\Engine\Controller). Критерий: бизнес-логика, специфичная для проекта, не должна быть в шаблоне — шаблон только для представления.

Выбор между инфоблоками и HL-блоками

Выбор определяется типом данных и нагрузкой. Инфоблоки — для каталогов с гибкими свойствами, но при >100 000 элементов и частых запросах на выборку по свойствам лучше использовать HL-блоки или собственные таблицы. Например, для справочника регионов с 200 записями подойдёт HL-блок, а для каталога товаров с 50 000 позиций — инфоблок с фасетным индексом. Мы всегда проводим нагрузочное тестирование.

Уровень кеширования

Архитектурное решение — какие данные кешировать и как инвалидировать. Варианты:

• BXCache/CPHPCache — файловый кеш для компонентов
• TaggedCache (\Bitrix\Main\Data\TaggedCache) — инвалидация по тегам
• Cache D7 (\Bitrix\Main\Data\Cache) — унифицированный кеш с поддержкой memcached/Redis
• Композитный кеш — статический HTML для анонимных пользователей

Правильно настроенное кеширование ускоряет загрузку страниц в 5–10 раз и снижает нагрузку на сервер. Сравним методы:

Кеширование как основа быстрого Битрикс-проекта

Без кеширования каждый запрос к странице каталога генерирует десятки SQL-запросов. На каталоге в 50 000 товаров время ответа может превышать 5 секунд. Тегированное кеширование позволяет инвалидировать только изменившиеся блоки, а композитный кеш отдаёт статику анонимным пользователям. В наших проектах время загрузки страниц не превышает 1 секунды. Если вы узнали свой проект в этом описании, получите консультацию — мы подскажем, как исправить архитектуру.

Уровень фронтенда

Битрикс поддерживает несколько подходов: классический PHP-шаблон с jQuery, компоненты с BX.ajax, и современный стек — Vue/React через REST API. Выбор влияет на поддерживаемость: фронтенд-разработчик на поддержке должен ориентироваться в принятом решении.

Многосайтовость и мультирегиональность

Если проект охватывает несколько регионов или языков, архитектурное решение принимается на старте. Битрикс поддерживает несколько сайтов в одном ядре с общей БД, языковые версии через модуль main, региональные сайты с разными доменами. Неправильный выбор (например, разные каталоги для каждого региона вместо одного с региональными ценами) приводит к дублированию и проблемам синхронизации.

Кейс: переработка архитектуры e-commerce проекта

Из нашей практики: дистрибьютор промышленного оборудования, проект без явного архитектурного решения: 4 инфоблока каталога для разных категорий, каждый со своим набором строковых свойств, бизнес-логика в init.php, шаблоны компонентов с логикой внутри. К моменту рефакторинга: 45 000 элементов суммарно, добавление нового свойства — правки в 4 местах, фильтр не работал по свойствам из разных инфоблоков, обмен с 1С — кастомный скрипт на 2 000 строк без документации. Стоимость проектирования для такого проекта — от 150 000 до 500 000 ₽, что в итоге окупается за счёт снижения затрат на поддержку.

Реализованное решение:

1. Объединили 4 инфоблока в один с единой схемой свойств через HL-блоки
2. Перенесли бизнес-логику из шаблонов в D7-компоненты и сервисные классы в local/lib/
3. Логику в init.php разбили на обработчики событий с регистрацией через AddEventHandler
4. Настроили фасетный индекс на едином инфоблоке — фильтр заработал корректно
5. Стандартный обмен с 1С через CommerceML заменил кастомный скрипт

Результат: время загрузки страниц сократилось в 4 раза, экономия на поддержке — порядка 40% (примерно 200 000 ₽ в год). Весь проект масштабируется без переписывания кода. Если вы столкнулись с похожими проблемами, получите консультацию — мы поможем перепроектировать архитектуру.

Включено в работу на этапе проектирования

• Анализ бизнес-требований и прогнозируемых нагрузок
• Диаграмма структуры данных: инфоблоки, HL-блоки, связи
• Схема компонентного состава страниц
• Схема кеширования и инвалидации
• Архитектура интеграций: 1С, CRM, платежные шлюзы
• План миграции (если проект не с нуля)
• Документация и передача команде разработки

Сроки ориентировочно

Проектирование занимает от 1 недели для типового проекта до 4–6 недель для enterprise-систем с несколькими интеграциями и мультисайтовой структурой. Стоимость рассчитывается индивидуально. У нас 10+ лет опыта с Битрикс, сертификация 1С-Битрикс Эксперт, гарантия на архитектурные решения. Закажите проектирование архитектуры — и ваш проект будет готов к росту.

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

Мы не раз сталкивались с проектами, где неправильная архитектура 1С-Битрикс приводила к падению производительности. Каталог на 80К товаров отдавал страницу за 5 секунд — и это при пустом кэше. Архитектура проектов на 1С-Битрикс — фундамент, который определяет производительность и стоимость поддержки. Архитектурные ошибки накапливаются и через год превращаются в капитальный рефакторинг, стоимость которого в разы выше изначального проектирования. По оценкам нашей практики, такой рефакторинг может стоить от 300 000 до 1 000 000 руб., не считая потери выручки во время простоя. Согласно документации, фундаментальные решения по хранению данных и кэшированию закладываются на старте и потом меняются с огромными затратами.

Наш опыт показывает: правильное проектирование на старте экономит до 40% бюджета на разработку. Мы проектируем структуру данных, кэширование, масштабирование и интеграции — с учётом роста нагрузки до 500К товаров и пикового трафика в Черную пятницу. Каждый проект проходит этап нагрузочного тестирования, чтобы избежать сюрпризов в продакшене. Оптимальная архитектура снижает требования к хостингу, экономя от 30 000 до 150 000 руб. в месяц.

Выбор типа хранения: инфоблоки или Highload-блоки?

Это первое и самое дорогое архитектурное решение. Миграция с инфоблоков на Highload потом — переписывание всех компонентов, шаблонов, фильтров и поисковых индексов.

Обычные инфоблоки работают через таблицы b_iblock_element и b_iblock_element_property. Свойства хранятся в EAV-модели — каждое значение в отдельной строке b_iblock_element_property. При 50 свойствах и 100К элементов получаем 5 миллионов строк в одной таблице. MySQL начинает задыхаться на JOIN-ах при фильтрации.

Инфоблоки хороши для:

• Контента до 10-50К элементов — статьи, новости, акции
• Сущностей, где нужен визуальный редактор и SEO-модуль
• Элементов с наследованием свойств от разделов

Highload-блоки — плоские таблицы. Одна сущность — одна таблица с колонками. Никакого EAV. Фильтрация по индексированным колонкам работает на порядок быстрее. Каталог на 200К товаров с фасетным индексом (b_catalog_sm_*) отдаёт фильтр за 50ms вместо 3 секунд.

Highload-блоки обязательны для:

• Каталоги > 50К товаров
• Справочники, которые дёргаются при каждой загрузке (города, бренды, характеристики)
• Данные с частой записью — логи, заявки, история
• Сущности, где нужны прямые SQL-запросы и агрегации

D7 ORM и свои таблицы — для бизнес-логики, которая не лезет в модель инфоблоков. Связи many-to-many, вычисляемые поля, кастомные агрегации. Bitrix\Main\ORM\Data\DataManager даёт типобезопасность, валидацию и систему событий. Но придётся писать админку с нуля. Подробнее — в документации Bitrix ORM.

Как масштабировать 1С-Битрикс без потери производительности?

Горизонтальное масштабирование — тема, на которой горят 90% проектов. Однако думают о нём, когда сайт уже лежит.

Первый шаг — сессии из файлов в Redis. Без этого второй веб-сервер бесполезен: пользователь авторизовался на сервере A, следующий запрос уходит на сервер B, сессия не найдена — разлогин. В .settings.php:

'session' => ['value' => ['mode' => 'redis', 'host' => '127.0.0.1', 'port' => 6379]]

Далее:

• nginx upstream или HAProxy раскидывает запросы. Модуль «Веб-кластер» Битрикс поддерживает кластеризацию, но нужна лицензия «Бизнес» или выше
• CDN для статики — /upload/, JS, CSS. Сервер перестаёт тратить ресурсы на отдачу картинок
• Репликация MySQL — master для записи, slave для чтения. Битрикс поддерживает до 9 slave-соединений через настройку в .settings.php. Но есть лаг репликации — товар добавили, а на slave он появится через 0.5-2 секунды

Вертикальное масштабирование — дешевле и быстрее на старте:

• EXPLAIN на каждый тяжёлый запрос. Один составной индекс на b_iblock_element_property (IBLOCK_PROPERTY_ID, VALUE) ускоряет фильтрацию в 10 раз
• Многоуровневый кэш: управляемый кэш Битрикс → memcached → композитный сайт. Проверяем hit rate в панели «Производительность» — если ниже 90%, что-то не так
• OPcache с JIT на PHP 8.1+ — бесплатное ускорение на 15-30%

Когда стоит выносить процессы из монолита?

Битрикс — монолит, и это нормально. Ломать его на микросервисы — безумие. А вот вынести тяжёлые процессы — правильный ход.

Импорт/экспорт — самая частая боль. Обмен с 1С через CIBlockCMLImport блокирует таблицы инфоблоков на время импорта. 100К товаров — это 20-40 минут, когда фильтрация на сайте тормозит. Решение: вынести импорт в отдельный воркер через RabbitMQ, писать в промежуточную таблицу, потом атомарно переключать.

• Поиск — Elasticsearch вместо штатного search.title. Полнотекстовый и фасетный поиск, автодополнение, исправление опечаток. Нагрузка с MySQL снимается полностью
• Уведомления — push, SMS, email через очередь. CEvent::Send() синхронный — пока письмо не уйдёт, пользователь ждёт ответ сервера. Очередь решает это
• Генерация отчётов — PDF, Excel на больших объёмах. В отдельный процесс, результат — ссылка на скачивание

API: REST, GraphQL, вебхуки

REST API Битрикса (/rest/) покрывает CRM, задачи, диск, но не покрывает каталог и инфоблоки в нужном объёме. Для SPA на React/Vue приходится писать свои эндпоинты через Bitrix\Main\Engine\Controller.

• GraphQL — для мобильных приложений, где трафик дорогой. Клиент запрашивает только нужные поля
• Вебхуки — событийная модель: новый заказ → POST на внешний URL. Не нужно опрашивать API каждые 5 минут
• Версионирование — /api/v1/, /api/v2/. Без этого обновление API ломает всех потребителей одновременно
• OpenAPI/Swagger — автогенерация документации. API без документации через месяц не помнит даже автор

Как избежать дорогостоящего рефакторинга?

Самый действенный способ — принимать архитектурные решения осознанно, с учётом реальных сценариев нагрузки и роста данных. Мы используем подход ADR (Architecture Decision Records) для фиксации каждого решения — контекст, альтернативы, последствия. Это позволяет новым разработчикам входить в проект за дни, а не недели, и исключает двоякое толкование логики через полгода.

Документация: ADR вместо Word-файлов

• ADR — Architecture Decision Records. Короткий файл: контекст, решение, последствия. Как показывает практика, фиксация архитектурного решения в момент его принятия спасает от бесконечных догадок через полгода. Например, через год новый разработчик откроет ADR и за пять минут поймёт, почему для каталога выбрали Highload, вместо того чтобы гадать три дня
• Диаграммы — серверы, потоки данных, точки интеграций. PlantUML или Mermaid, хранятся в репозитории рядом с кодом
• ER-диаграммы — инфоблоки, свойства, связи. Без схемы даже автор через полгода не вспомнит, почему свойство LINKED_PRODUCTS ссылается на другой инфоблок через привязку, а не через Highload-справочник
• Runbook — деплой, откат, масштабирование, действия при аварии. Потому что авария случится в субботу ночью, когда архитектора нет на связи

Техдолг: старое ядро, прямые SQL, логика в шаблонах

Техдолг в Битриксе специфичен. Три главных источника:

1. Старое ядро вместо D7 — CIBlockElement::GetList() вместо \Bitrix\Iblock\Elements\ElementTable::getList(). Старое ядро не поддерживает ORM-фичи, медленнее, и Битрикс рано или поздно его задепрекейтит
2. Прямые SQL в шаблонах компонентов — $DB->Query("SELECT...") прямо в template.php. Переносим в сервисные классы, заменяем на ORM
3. Бизнес-логика в result_modifier.php — файл, который должен готовить данные для шаблона, а не считать скидки и проверять права доступа

Подход: PHPStan level 5+ для выявления проблем, матрица «влияние на бизнес / стоимость фикса», поэтапный рефакторинг по спринтам. Не всё сразу — но тренд должен быть нисходящим.

Как мы проектируем архитектуру

1. Анализ бизнес-требований и нагрузочных характеристик (пиковый RPS, размер каталога, типичные сценарии)
2. Проектирование структуры данных — выбор инфоблоки/Highload/D7 ORM, связи, индексы
3. Определение схемы кэширования и очередей (Redis, RabbitMQ, композит)
4. Прототипирование и нагрузочное тестирование на реальных данных (200К записей, 30+ свойств)
5. Документирование — ADR, ER-диаграммы, runbook, спецификации API
6. Ревью проекта — внутреннее и с заказчиком

Для одного интернет-магазина мы спроектировали архитектуру на Highload-блоках и Elasticsearch. Фильтрация товаров до 50 мс, время первого байта 0.3 с. Экономия на хостинге — существенная.

Что входит в работу

Мы — команда сертифицированных специалистов с опытом внедрения 1С-Битрикс более 8 лет. Выполнили архитектуру для 50+ проектов с каталогами до 300К товаров и нагрузкой до 10К одновременно активных пользователей. Гарантируем, что спроектированная архитектура выдержит пиковые нагрузки и не потребует рефакторинга в ближайшие 3 года.

На выходе: архитектурный документ (ADR, ER-диаграммы, runbook), прототип критических узлов (опционально), документация по API, рекомендации по кэшированию и масштабированию.

Если ваша архитектура вызывает сомнения или вы готовитесь к росту трафика — свяжитесь с нами для консультации. Мы проведём аудит текущей структуры и предложим оптимальную стратегию. Закажите коммерческое предложение — мы подготовим его в течение 2 рабочих дней.