Розробка багатосайтової структури на 1С-Бітрікс

Розробка багатосайтової структури на 1С-Бітрікс

На одній установці Бітрікса можна запустити десяток сайтів із різними доменами, шаблонами, контентом і навіть мовами. Механізм SITE_ID вбудований у ядро — кожен запит визначає, до якого сайту належить, і підтягує потрібний шаблон, контент, мовні файли. Звучить просто. На практиці — кеш одного сайту «протікає» в інший, права доступу перемішуються, а SEO-модуль генерує sitemap із посиланнями на чужий домен.

Коли багатосайтовість виправдана

Холдинг із п'ятьма брендами. Франшиза з регіональними представництвами. Група компаній, де в кожного напрямку свій домен, але товарна база спільна. У цих випадках альтернатива — п'ять окремих установок Бітрікса, п'ять ліцензій, п'ять серверів, п'ять обмінів із 1С. Багатосайтовість на одній установці — один сервер, одна ліцензія (починаючи з редакції «Бізнес»), одна адмінка.

Не виправдана — коли сайти взагалі не перетинаються за даними, аудиторією та бізнес-логікою. Тоді зв'язка через одну базу лише ускладнює деплой і збільшує радіус ураження при збої.

Архітектура: спільна база vs роздільні

Бітрікс підтримує два режими багатосайтовості.

Спільна база, спільні файли — всі сайти живуть в одній базі MySQL і одній файловій системі. Розділення — через SITE_ID у таблицях. Інфоблок можна прив'язати до кількох сайтів через b_iblock_site. Користувач, зареєстрований на сайті A, автоматично авторизований на сайті B (спільна таблиця b_user, спільні сесії).

Підводні камені:

• Кеш компонентів — якщо не вказати SITE_ID у ключі кешу, компонент news.list на сайті B віддасть дані, закешовані для сайту A. Стандартні компоненти Бітрікса зазвичай враховують SITE_ID, а ось кастомні — ні, поки не додаш $this->arParams['CACHE_GROUPS'] і не включиш SITE_ID у getAdditionalCacheID()
• Права доступу — групи користувачів спільні. Менеджер контенту сайту A може випадково відредагувати інфоблок сайту B, якщо не вибудувана матриця прав на рівні інфоблоків
• Модуль SEO — sitemap.xml генерується через seo.sitemap.run. Потрібно створювати окрему карту для кожного SITE_ID, інакше в карту сайту A потраплять URL сайту B

Роздільні бази — налаштування через .settings.php, секція connections. Кожен сайт підключається до своєї бази. Повна ізоляція даних, але спільних користувачів і спільних інфоблоків більше немає. Використовується рідко — переважно для повного розділення, коли спільна адмінка потрібна лише для керування серверною інфраструктурою.

Домени та маршрутизація

У налаштуваннях сайту (Налаштування → Налаштування продукту → Сайти) вказуються:

• Домен — brand-a.com, brand-b.com
• Каталог сайту — корінь / або підкаталог /brand-b/
• Шаблон за замовчуванням — кожен сайт може використовувати свій шаблон із local/templates/

Маршрутизація працює через модуль ядра: Бітрікс зіставляє HTTP_HOST із полем SERVER_NAME у таблиці b_lang. Якщо домен не знайдений — підставляється сайт за замовчуванням. Для піддоменів (spb.company.com, msk.company.com) механізм той самий — кожен піддомен = окремий SITE_ID.

Нюанс із HTTPS та CDN. Якщо перед Бітріксом стоїть nginx або Cloudflare, заголовок HTTP_HOST може приходити некоректно. Перевіряємо $_SERVER['HTTP_X_FORWARDED_HOST'] і налаштовуємо SITE_SERVER_NAME у dbconn.php.

Шаблони: спільне vs унікальне

Три стратегії:

1. Один шаблон, різні CSS-теми. Спільний HTML-каркас у local/templates/main/, перемикання стилів через SITE_ID. Швидко, дешево, але дизайн сайтів буде схожим
2. Окремі шаблони. local/templates/brand-a/, local/templates/brand-b/. Повна свобода дизайну, але дублювання коду компонентів. Вихід — спільні шаблони компонентів у local/templates/.default/components/
3. Базовий шаблон + успадкування. Основні компоненти та layout у базовому, кастомні — в шаблоні сайту. header.php та footer.php специфічні для кожного сайту, а шаблони компонентів перевикористовуються

На практиці працює третій варіант. Шапка, підвал, кольорова схема, логотип — унікальні. Картка товару, лістинг новин, форма зворотного зв'язку — спільні. Економія на підтримці — баг у шаблоні компонента виправляєш один раз, а не на кожному сайті окремо.

Спільна користувацька база

Головна перевага спільної бази — єдина авторизація. Користувач реєструється на brand-a.com, заходить на brand-b.com — вже авторизований. Це працює через спільну таблицю b_user та спільні сесії.

Але є підступ. Сесії зберігаються у файлах за замовчуванням — у /bitrix/sessions/. При двох доменах cookie PHPSESSID не передається між ними (різні домени — різні cookie). Рішення:

• Спільний домен верхнього рівня — .company.com, cookie ставиться на .company.com, працює для a.company.com та b.company.com
• SSO через токен — при переході між доменами передаємо одноразовий токен у URL, на приймаючій стороні створюємо сесію. Модуль socialservices або кастомний обробник
• Redis для сесій — сесії зберігаються централізовано, але проблема cookie залишається. Redis вирішує іншу задачу — горизонтальне масштабування, не кросдоменну авторизацію

Контент: що ділити, що розділяти

Інфоблоки прив'язуються до сайтів через налаштування в адмінці. Один інфоблок може бути доступним на кількох сайтах. Типовий сценарій: каталог товарів — спільний (SITE_ID: s1, s2, s3), новини — у кожного сайту свої.

Важливий момент — властивості інфоблока спільні. Не можна додати властивість «Акція» тільки для сайту A, якщо інфоблок прив'язаний до сайтів A, B, C. Всі три сайти побачать цю властивість. Рішення — використати множинну властивість типу «Прив'язка до сайту» та фільтрувати в компоненті.

Торговельний каталог. Модуль catalog дозволяє налаштувати різні типи цін для різних сайтів. Сайт для оптовиків показує оптові ціни, роздрібний — роздрібні. Складські залишки — спільні або роздільні через прив'язку до магазинів (b_catalog_store).

SEO-налаштування — шаблони META через iblock.type.edit задаються на рівні інфоблока, не сайту. Для різних сайтів з одним інфоблоком доведеться генерувати META програмно в result_modifier.php, підставляючи потрібні значення за SITE_ID.

Часті проблеми при масштабуванні

• Обмін із 1С — модуль catalog.import.1c імпортує товари в інфоблоки. Якщо каталог спільний на три сайти, імпорт один. Якщо в кожного сайту свій каталог — три окремих обміни, три профілі в 1С. При 50К+ товарів кожен обмін блокує таблиці на 15-30 хвилин. Рознесемо по крону, щоб не перетинались
• Пошук — штатний search.title індексує всі сайти в одну таблицю b_search_content. Результати фільтруються за SITE_ID, але індекс спільний. На 5 сайтах із 100К сторінок кожен — індекс на півмільйона записів, переіндексація займає години. Elasticsearch замість штатного пошуку — якщо обсяг даних суттєвий
• Композитний кеш — модуль composite працює коректно з багатосайтовістю, але вимагає окремого налаштування для кожного домену. Без цього HTML-знімок сайту A може віддатися на домені B

Етапи впровадження

1. Аудит поточної інфраструктури (3-5 днів) — які дані спільні, які унікальні, які інтеграції зачіпаються
2. Проєктування структури (1-2 тижні) — матриця сайтів, інфоблоків, прав доступу, шаблонів. ER-діаграма зв'язків
3. Налаштування ядра (3-5 днів) — створення сайтів, прив'язка доменів, налаштування сесій та кешування
4. Розробка шаблонів (2-6 тижнів) — залежить від кількості сайтів та ступеня відмінностей у дизайні
5. Міграція контенту (1-2 тижні) — перенесення даних, налаштування прив'язок, SEO-аудит
6. Тестування (1 тиждень) — кроссайтові сценарії, авторизація, кеш, SEO

Вартість залежить від кількості сайтів, ступеня унікальності кожного та складності інтеграцій. Визначається після детального аналізу.