Послуги з проектування архітектури на 1С-Бітрікс

Архітектура проєктів на 1С-Бітрікс

Неправильно обраний тип зберігання — і каталог на 80К товарів віддає сторінку за 5 секунд. Не передбачили винесення сесій — і при додаванні другого веб-сервера користувачі починають «вилітати» з кошика. Архітектурні помилки в Бітріксі не прощаються — вони накопичуються і через рік перетворюються на капітальний рефакторинг.

Інфоблоки vs 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 дає типобезпеку, валідацію та систему подій. Але доведеться писати адмінку з нуля.

Масштабування: як не лягти у Чорну п'ятницю

Горизонтальне масштабування — тема, на якій горять 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-first: 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 замість Word-файлів

• ADR — Architecture Decision Records. Короткий файл: контекст, рішення, наслідки. «Чому обрали Highload для каталогу?» — через рік новий розробник відкриє ADR і зрозуміє за 5 хвилин, замість того щоб гадати три дні
• Діаграми — сервери, потоки даних, точки інтеграцій. 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. Збір вимог (3–5 днів) — навантаження, плани зростання, інтеграції, бюджет
2. Проєктування (1–2 тижні) — структура даних, схема інтеграцій, ADR за ключовими рішеннями
3. Прототипування (1 тиждень) — навантажувальні тести на реальних обсягах. Highload-блок з 200К записів і 30 властивостей — чи витримає фільтрація?
4. Документування (3–5 днів) — діаграми, runbook, специфікації API
5. Рев'ю (2–3 дні) — внутрішнє, потім із замовником

На виході — архітектурний документ, на який можна спиратися при розробці, оцінці термінів та масштабуванні.