Консультування з архітектури рішень 1С-Бітрікс

Консультування з архітектури рішень 1С-Бітрікс

Архітектурні рішення, прийняті на початку проєкту, визначають вартість кожної наступної функції. Неправильний вибір — зберігати дані у властивостях інфоблоку замість окремих таблиць при обсязі 100 000 елементів — через два роки обернеться неможливістю виконувати прості вибірки за розумний час. Переробка обходиться в 10–30 разів дорожче, ніж правильний вибір на початку.

Типові архітектурні розвилки

Інфоблоки проти ORM-таблиць. Інфоблоки універсальні та керуються через адміністративний інтерфейс — добре для контенту. Але при складних зв'язках, високій частоті запису або нестандартних запитах користувацькі ORM-таблиці (\Bitrix\Main\ORM\Data\DataManager) працюють у 5–50 разів швидше.

Правило: якщо дані редагуються через адміністративний розділ редакторами — інфоблок. Якщо даними керує лише код (логи, черги, події, транзакції) — ORM-таблиця.

Моноліт проти модульної архітектури. На старті зручно писати все в одному кастомному компоненті. Через рік цей компонент на 3 000 рядків неможливо тестувати і складно передати іншій команді. Модульний підхід: /local/modules/company.module_name/ з чітким публічним API, подіями та залежностями через Composer.

AJAX-компоненти проти SPA-підходу. Бітрікс підтримує обидва підходи. AJAX-компоненти (bitrix:main.loader) працюють нативно з ядром, але обмежені у можливостях. SPA на React/Vue (через bitrix:ui.sidepanel або повноцінний SPA) дає кращий UX, але потребує окремого API та ускладнює SSR/SEO.

Кешування. Бітрікс надає кілька шарів:

Вибір редакції та ліцензії

Редакція визначає доступні модулі: b2b, catalog (торговий каталог B2B), sale.crm (CRM-інтеграція в замовленнях).

Інтеграція з 1С: архітектурні рішення

Класичний обмін через CommerceML (файловий обмін) працює до ~50 000 SKU. При більшому обсязі або вимозі реального часу потрібен REST-обмін через API 1С або проміжний брокер повідомлень (RabbitMQ).

Архітектура з брокером: 1С → публікує подію в RabbitMQ → Бітрікс-воркер підписується та обробляє → оновлює дані в реальному часі. Затримка — секунди замість годин при файловому обміні.

Кейс: 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 годин.

Що входить до консультування з архітектури

• Аналіз бізнес-вимог та обмежень (трафік, обсяг даних, бюджет)
• Порівняння архітектурних варіантів з оцінкою ризиків та вартості
• Вибір редакції Бітрікс, складу модулів
• Проєктування схеми даних та структури модулів
• Архітектура інтеграцій з 1С та зовнішніми системами
• Рекомендації щодо стеку (кеш, пошук, черги)
• Документ «Архітектурне рішення» для команди розробки