Проектування архітектури проекту на 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 разів і знижує навантаження на сервер. Теговане кешування працює в 3 рази швидше за файловий кеш при високому навантаженні. Порівняємо методи:

Чому кешування – основа швидкого Бітрікс-проекту?

Без кешування кожен запит до сторінки каталогу генерує десятки 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 рядків без документації. Вартість проектування для такого проекту визначається індивідуально, що в підсумку окупається за рахунок зниження витрат на підтримку.

Реалізоване рішення:

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

Результат: час завантаження сторінок скоротився в 4 рази, економія на підтримці — близько $15 000 на рік. Весь проект масштабується без переписування коду. Якщо ви зіткнулися зі схожими проблемами, отримайте консультацію — ми допоможемо перепроектувати архітектуру.

Що входить в роботу на етапі проектування

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

Терміни та вартість орієнтовно

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

Типові помилки при проектуванні архітектури проектів на 1С-Бітрікс

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

Правильне проектування на старті економить до 40% бюджету на розробку. Ми проектуємо структуру даних, кешування, масштабування та інтеграції — з урахуванням зростання навантаження до 500К товарів та пікового трафіку в Чорну п’ятницю. Кожен проект проходить етап навантажувального тестування, щоб уникнути сюрпризів у продакшені. Оптимальна архітектура знижує вимоги до хостингу, заощаджуючи значну суму щомісяця.

Вибір типу зберігання: інфоблоки або 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-блоки з індексованими колонками фільтрують дані в 10 разів швидше, ніж EAV-модель інфоблоків.

Highload-блоки обов'язкові для:

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

D7 ORM та свої таблиці — для бізнес-логіки, яка не вписується в модель інфоблоків. Зв'язки many-to-many, обчислювані поля, кастомні агрегації. Bitrix\Main\ORM\Data\DataManager дає типобезпеку, валідацію та систему подій. Але доведеться писати адмінку з нуля.

Як масштабувати 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 робочих днів. Щоб отримати персональну консультацію щодо вашого проекту, напишіть нам — розкажемо, які архітектурні рішення підійдуть саме вам.