Консультування з архітектури рішень 1С-Бітрікс
Архітектурні рішення, прийняті на старті проєкту, визначають вартість кожної наступної функції. Неправильний вибір — зберігати дані у властивостях інфоблоку замість окремих таблиць при об'ємі 100 000 елементів — через два роки обернеться неможливістю виконувати прості вибірки за розумний час. Переробка коштує в 10–30 разів дорожче, ніж правильний вибір на початку. Щодня ми бачимо проєкти, де через невірну архітектуру команда витрачає 70% часу на підтримку замість розвитку. За 10+ років роботи ми провели понад 50 архітектурних консультацій і реалізували 30+ проєктів з нуля. Наш досвід — гарантія якісного рішення.
Типові архітектурні розвилки
Інфоблоки vs. ORM-таблиці: що обрати?
Інфоблоки універсальні й керуються через адміністративний інтерфейс — добре для контенту. Але при складних зв'язках, високій частоті запису або нестандартних запитах користувацькі ORM-таблиці (\Bitrix\Main\ORM\Data\DataManager) працюють у 5–50 разів швидше.
Правило: якщо дані редагуються через адміністративний розділ редакторами — інфоблок. Якщо даними керує тільки код (логи, черги, події, транзакції) — ORM-таблиця.
Моноліт vs. модульна архітектура
На старті зручно писати все в одному кастомному компоненті. Через рік цей компонент на 3 000 рядків неможливо тестувати й складно передати іншій команді. Модульний підхід: /local/modules/company.module_name/ з чітким публічним API, подіями та залежностями через Composer.
AJAX-компоненти vs. SPA-підхід
Бітрікс підтримує обидва підходи. AJAX-компоненти (bitrix:main.loader) працюють нативно з ядром, але обмежені в можливостях. SPA на React/Vue (через bitrix:ui.sidepanel або повноцінний SPA) дає кращий UX, але вимагає окремого API та ускладнює SSR/SEO.
Чому кешування — ключовий елемент продуктивності?
Грамотне кешування може прискорити сайт у 10–50 разів без зміни логіки. Бітрікс надає кілька шарів:
| Шар | Механізм | Застосування |
|---|---|---|
| Managed cache | \Bitrix\Main\Data\ManagedCache |
Об'єкти з тегами інвалідації |
| Page cache | Налаштування компонента | Цілі сторінки/блоки |
| memcache / Redis | Налаштування /bitrix/.settings.php |
Сесії, об'єктний кеш |
| CDN | Зовнішній CDN | Статика, зображення |
Вибір редакції та ліцензії
| Задача | Рекомендація |
|---|---|
| Корпоративний портал | Бітрікс24 коробковий, Enterprise |
| Інтернет-магазин з B2B | 1С-Бітрікс: Бізнес або Малий бізнес |
| Навантажений маркетплейс | Enterprise + кластер |
| Лендінг + CRM | Бітрікс24 хмара |
Редакція визначає доступні модулі: b2b, catalog (торговельний каталог B2B), sale.crm (CRM-інтеграція в замовленнях).
Інтеграція з 1С: архітектурні рішення
Класичний обмін через CommerceML (файловий обмін) працює до ~50 000 SKU. При більшому об'ємі або вимозі реального часу потрібен REST-обмін через API 1С або проміжний брокер повідомлень (RabbitMQ).
Архітектура з брокером: 1С → публікує подію в RabbitMQ → Бітрікс-воркер підписується та обробляє → оновлює дані в real-time. Затримка — секунди замість годин при файловому обміні.
Як ми консультуємо з архітектури?
- Аналіз бізнес-вимог та обмежень (трафік, об'єм даних, бюджет)
- Порівняння архітектурних варіантів з оцінкою ризиків і вартості
- Вибір редакції Бітрікс, складу модулів
- Проектування схеми даних і структури модулів
- Архітектура інтеграцій з 1С та зовнішніми системами
- Рекомендації щодо стеку (кеш, пошук, черги)
- Документ «Архітектурне рішення» для команди розробки
Що входить у роботу?
- Аудит поточної архітектури з виявленням вузьких місць
- Порівняння варіантів модернізації з оцінкою вартості та ризиків
- Проектування модульної структури та схеми даних
- Рекомендації щодо стеку технологій (кеш, пошук, черги)
- Готовий документ «Архітектурне рішення» з планом дій
- Консультація команди після впровадження — 2 години підтримки
Кейс із нашої практики: B2B-платформа, 500 000 SKU
Задача: інтернет-магазин для корпоративних клієнтів з індивідуальними цінами, квотами та умовами доставки для кожного контрагента.
Проблеми стандартного підходу:
- Зберігання цін у
b_catalog_price— 500 000 SKU × 200 груп покупців = 100 млн записів, будь-який запит ціни > 500 мс - Фільтр каталогу за властивостями інфоблоку — sequential scan на таблиці з 5 млн рядків властивостей
- Кошик і замовлення стандартного
saleне підтримують квоти та умови по контрагенту
Архітектурне рішення:
- Ціни винесено в окрему ORM-таблицю
bl_b2b_priceз індексом по(user_group_id, product_id)— запит ціни 5 мс - Фільтр через ElasticSearch (інтеграція з Бітрікс через кастомний компонент)
- Стандартний
saleрозширено модулемcompany.b2b_sale— додані поля контрагента, квот і спеціальних умов - Ціни з 1С передаються через RabbitMQ → воркер оновлює
bl_b2b_priceв реальному часі
Результат: сторінка каталогу з фільтром завантажується 300 мс, оновлення цін з 1С — до 30 секунд замість 4 годин.
| Компонент рішення | Технологія | Обґрунтування |
|---|---|---|
| Зберігання цін | ORM-таблиця + індекси | b_catalog_price не масштабується до 100М записів |
| Пошук і фільтр | ElasticSearch | Повнотекстовий пошук + фасетний фільтр за <100мс |
| Синхронізація з 1С | RabbitMQ + воркер | Real-time замість файлового обміну |
| Кошик і замовлення | Розширення \Bitrix\Sale |
Збереження сумісності з модулями Бітрікс |
Отримайте консультацію з архітектури вашого проєкту — ми оцінимо ризики та запропонуємо оптимальне рішення за 2–3 дні. Замовте архітектурний аудит, щоб уникнути дорогих переробок у майбутньому. Ми гарантуємо прозорість і дотримання термінів.