Проектування архітектури проекту на 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) - Структура типів інфоблоків та їх групування
- Схема торгових пропозицій: один інфоблок оферів на все або роздільні на категорії
| Сховище | Коли використовувати | Коли уникати |
|---|---|---|
| Інфоблоки (EAV) | Каталоги товарів, контент з багатьма властивостями | Дані з високим навантаженням на запис, великі обсяги (>100 000 елементів) |
| HL-блоки (Highload) | Довідники, списки значень, допоміжні дані | Ієрархічні дані, де потрібна вкладеність |
| Власні таблиці ORM | Логіка замовлень, кошик, аудит | Прості довідники |
В офіційній документації 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) — інвалідація за тегами -
CacheD7 (\Bitrix\Main\Data\Cache) — уніфікований кеш з підтримкою memcached/Redis - Композитний кеш — статичний HTML для анонімних користувачів
Правильно налаштоване кешування прискорює завантаження сторінок у 5–10 разів і знижує навантаження на сервер. Теговане кешування працює в 3 рази швидше за файловий кеш при високому навантаженні. Порівняємо методи:
| Метод кешування | Швидкість (ум. од.) | Складність налаштування | Інвалідація |
|---|---|---|---|
| Файловий (BXCache) | 50 | Низька | Ручна |
| Тегований (TaggedCache) | 80 | Середня | Автоматична за тегами |
| Redis/Memcached | 95 | Висока | Автоматична за ключами |
| Композитний | 100 (для анонімів) | Середня | Повний скид при змінах |
Приклад архітектурного рішення для кешування
Для каталогу з 50 000 товарів ми використовуємо теговане кешування з інвалідацією за змінами в інфоблоці. Композитний кеш вмикається для анонімних користувачів. Результат: час завантаження сторінок <1 секунди.Чому кешування – основа швидкого Бітрікс-проекту?
Без кешування кожен запит до сторінки каталогу генерує десятки 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 рядків без документації. Вартість проектування для такого проекту визначається індивідуально, що в підсумку окупається за рахунок зниження витрат на підтримку.
Реалізоване рішення:
- Об'єднали 4 інфоблоки в один з єдиною схемою властивостей через HL-блоки
- Перенесли бізнес-логіку з шаблонів у D7-компоненти та сервісні класи в
local/lib/ - Логіку в
init.phpрозбили на обробники подій з реєстрацією черезAddEventHandler - Налаштували фасетний індекс на єдиному інфоблоці — фільтр запрацював коректно
- Стандартний обмін з 1С через CommerceML замінив кастомний скрипт
Результат: час завантаження сторінок скоротився в 4 рази, економія на підтримці — близько $15 000 на рік. Весь проект масштабується без переписування коду. Якщо ви зіткнулися зі схожими проблемами, отримайте консультацію — ми допоможемо перепроектувати архітектуру.
Що входить в роботу на етапі проектування
- Аналіз бізнес-вимог та прогнозованих навантажень
- Діаграма структури даних: інфоблоки, HL-блоки, зв'язки
- Схема компонентного складу сторінок
- Схема кешування та інвалідації
- Архітектура інтеграцій: 1С, CRM, платіжні шлюзи
- План міграції (якщо проект не з нуля)
- Документація та передача команді розробки
- Надання доступів до репозиторію та документації, навчання команди розробки основам архітектури, супровід на етапі впровадження
Терміни та вартість орієнтовно
Проектування займає від 1 тижня для типового проекту до 4–6 тижнів для enterprise-систем з кількома інтеграціями та багатосайтовою структурою. Вартість проектування стартує від $1,000 для невеликих проектів та може сягати $10,000 для enterprise-рішень. У нас 10+ років досвіду з Бітрікс, сертифікація 1С-Бітрікс Експерт, гарантія на архітектурні рішення. Замовте проектування архітектури — і ваш проект буде готовий до зростання.