Архитектура Битрикс — это набор стандартов проектирования и структурных решений (ядро D7, изоляция кода в /local/, ORM), обеспечивающих безопасность обновлений, масштабируемость проекта и высокую производительность сайта при возрастающих нагрузках.
Знаете это чувство, когда открываешь проект, доставшийся «в наследство», и хочется просто тихо закрыть ноутбук? Я называю такие сайты Франкенштейнами. Вроде живое, вроде ходит, но швы расходятся, а внутри — хаос из костылей десятилетней давности. Чаще всего проблема не в самой CMS (как любят кричать в чатиках любители Laravel), а в том, как именно её готовили. Битрикс — система мощная, но она дает слишком много свободы там, где нужны жесткие рельсы.
Если вы запускаете проект с нуля или планируете серьезный рефакторинг, забудьте про «как-нибудь потом». Архитектура — это фундамент. Если залить его из песка и палок, никакой красивый фронтенд на Vue.js вас не спасет, когда база данных встанет колом под нагрузкой.
Правило №1: Изоляция или смерть (проекта)
Папка /local/ — ваша крепость
Первое, что я проверяю на аудите — это наличие папки /bitrix/php_interface/ или, не дай бог, кастомных компонентов внутри ядра. Это грубейшая ошибка. Весь ваш код, все модули, компоненты, шаблоны и тот самый php_interface должны жить исключительно в директории /local/. Папка /bitrix/ — это территория вендора. Она должна оставаться девственно чистой для обновлений.
Почему это критично? При обновлении платформы система может перезаписать файлы в /bitrix/. Если там лежал ваш гениальный фикс, он исчезнет. В /local/ вы царь и бог, туда апдейтер не лезет.
Данные и производительность: Highload-блоки против Инфоблоков
Раньше мы хранили всё в инфоблоках. Новости, товары, справочники городов, список сотрудников. Но инфоблоки построены на модели EAV (Entity-Attribute-Value). Это гибко, но медленно: чтобы получить одно свойство, базе данных приходится делать кучу джойнов (JOIN). Для каталога товаров это оправдано, но для справочников — убийство производительности.
Сейчас стандартом является использование Highload-блоков (HL) для высоконагруженных сущностей. Они создают под себя отдельные таблицы в БД. Разница колоссальная.
| Характеристика | Инфоблоки (IBlock) | Highload-блоки (HL) |
|---|---|---|
| Структура в БД | Размыта по множеству таблиц (EAV) | Одна таблица на сущность |
| Скорость выборки | Средняя/Низкая на больших объемах | Максимально высокая (прямые запросы) |
| Назначение | Каталоги, иерархические структуры, контент | Справочники, логи, корзины, связи |
| Работа с API | Классы CIBlock (старое ядро) / D7 | Только D7 ORM (сущности Table) |
Оптимизация запросов
Даже HL-блок можно положить, если писать запросы в стиле «дай мне всё». В крупных Enterprise-проектах до 80% тормозов вызваны ленивыми разработчиками, использующими getList с выборкой select => ['*']. Всегда указывайте конкретные поля. База данных скажет вам спасибо.
Стек технологий: уходим от легаси
Ядро D7 и PHP 8+
Если я вижу в коде CUser::GetList или CIBlockElement::GetList в новом модуле, у меня дергается глаз. Это старое ядро. Оно работает, но поддерживается только ради обратной совместимости. Вся современная разработка ведется на ядре D7 (и его развитии D8). Это пространство имен \Bitrix\Main\, это ORM, это контроллеры.
К тому же, переход с PHP 7.x на PHP 8.1 или 8.2 дает прирост производительности ядра примерно на 20–30% без переписывания ни единой строчки кода. Это происходит за счет JIT-компиляции и внутренних оптимизаций интерпретатора. Но тут важно следить за типизацией. В тренде — declare(strict_types=1);, использование DTO (Data Transfer Objects) вместо бесконечных массивов и внедрение зависимостей.
Фронтенд без jQuery
Да, Битрикс долго жил в обнимку с jQuery. Но сейчас курс взят на ванильный JS (ES6+) и библиотеку Bitrix Vue. Строить архитектуру фронтенда с жесткой зависимостью от jQuery в 2024 году — моветон. Headless CMS подход набирает обороты: Битрикс работает как надежный бэкенд (админка + база), а фронт пишется на React или Nuxt, общаясь через REST API.
Процессы и безопасность (DevOps)
Архитектура — это не только код, это среда, в которой он живет. Править файлы по FTP — это как делать операцию на сердце в полевых условиях грязным ножом. Забудьте.
- Миграции БД — это закон. Нельзя создавать свойства инфоблоков вручную на проде. Используйте модули миграций. Структура базы данных должна быть версионирована в коде (git).
- Docker и CI/CD. Разработка ведется локально в контейнерах. Деплой — автоматический, через GitLab CI или GitHub Actions, с прогоном тестов.
- Конфигурация через .settings.php и .env. Пароли от базы, API-ключи от служб доставки — ничего этого не должно быть в коде. Используйте переменные окружения.
- Агенты на CRON. Переводите все периодические агенты с хитов (когда скрипт запускается заходом пользователя) на системный CRON. Это стабилизирует нагрузку и уберет «фризы» у случайных посетителей.
Проблема «Тяжелого init.php»
Файл init.php — это бутылочное горлышко. Если вы подключаете там 50 файлов через require_once, вы замедляете TTFB (время до первого байта) для каждого пользователя. Решение — использовать автозагрузку классов (Autoloading) по стандарту PSR-4. Класс грузится только тогда, когда он реально нужен.
Сервисный слой: отделяем мух от котлет
Самая частая болезнь — бизнес-логика в файле template.php. Шаблон должен отвечать только за вывод HTML. Логика не должна жить и в контроллерах. Идеальная схема:
- Контроллер (Компонент): Принимает запрос, проверяет права.
- Сервис (Service Layer): Выполняет бизнес-задачу (расчет скидки, создание заказа, выборка данных). Сервисы лежат в
/local/modules/или/local/php_interface/lib/. - Репозиторий: Если нужно, ходит в базу данных.
- Шаблон: Получает готовые данные и просто их рисует.
Такой код легко читать, легко тестировать и легко поддерживать.
Построение правильной архитектуры и поддержка
Всё, что описано выше, может звучать пугающе, если вы привыкли просто «натягивать верстку». Но именно этот подход отличает профессиональный проект от любительской поделки, которая рухнет в «черную пятницу». Выстраивание правильной архитектуры с нуля экономит сотни часов на отладке в будущем.
Я занимаюсь тем, что превращаю хаотичные требования в стройную систему. Будь то разработка сложного E-commerce проекта, внедрение Highload-блоков или технический надзор за командой — правильный фундамент окупается всегда. Если вам нужен не просто сайт, а надежный инструмент бизнеса, или требуется аудит текущего «Франкенштейна», я помогу навести порядок.
Частые вопросы
Почему нельзя использовать print_r для отладки на боевом сайте?
Вывод данных через print_r или var_dump ломает верстку и виден пользователям, что непрофессионально и небезопасно. Используйте модуль «Дебаг», xDebug или логируйте данные в файл через класс \Bitrix\Main\Diag\Debug::writeToFile().
Когда стоит включать «Композит»?
Включать композитный режим нужно только после полной отладки всех компонентов. Если в коде есть ошибки или неверная логика кеширования, композит может «заморозить» эти ошибки или показывать пользователям чужие данные (например, корзину).
Зачем нужен тегированный кеш (Tagged Cache)?
Стандартный кеш сбрасывается по времени или при сбросе всего раздела. Тегированный кеш позволяет привязать данные к конкретной сущности (например, товару). Изменили цену одного товара — сбросился кеш только там, где этот товар выводился, а не весь каталог целиком.
Нужна ли мне BitrixVM или лучше настроить сервер самому?
Для 90% проектов BitrixVM — это лучший выбор (стандарт де-факто), так как она преднастроена вендором. Кастомный стек (Linux + NGINX + PHP-FPM) нужен только для очень сложной архитектуры, где требуются специфические настройки тюнинга MySQL или балансировщики нагрузки.
Как перенести изменения инфоблоков с Dev на Prod без потери данных?
Только через миграции. Ручное повторение действий на проде чревато ошибками (забыли галочку, перепутали ID). Миграции позволяют описать изменения в коде и накатить их автоматически, гарантируя идентичность окружений.