Архітектура 1С-Битрикс: де ламається зростання навантаження
Архітектура 1С-Битрикс рідко ламається одразу — вона деградує поступово, і перший сигнал зазвичай виглядає як «стало повільніше після чергового наповнення каталогу».
Каталог на десятки тисяч позицій, обмін з обліковою системою та зростаюча частка авторизованих відвідувачів складаються у вузьке місце: навантаження на каталог зростає швидше, ніж потужності серверів.
Типові вузькі місця Битрикс відомі: один вузол обслуговує і каталог, і кошик, і адмінку; обмін з обліковою системою відбувається синхронно й тримає таблиці в блокуванні; завдання за розкладом запускаються по черзі й конкурують за ті самі дані. Окремо кожен елемент терпимий — разом вони дають нелінійне зростання часу відгуку.
Окрема історія — кеш. Він не встигає прогріватися, якщо інвалідація спрацьовує на кожну зміну товару, а сторінки каталогу збираються заново для кожного гостя.
Керований і композитний кеш допомагають, але потребують коректних залежностей і розділення прогріву за розкладом — інакше після скидання сайт отримує залп важких запитів.
Аудит архітектури сайту починається не з коду, а з карти точок відмови сайту: скільки вузлів, де живе база, хто й коли пише в каталог, що відбувається за недоступності облікової системи. Далі — вимірювання: план виконання важких запитів, частка сторінок із кешу, час прогріву.
Так видно, що вирішується налаштуванням, а що потребує винесення обміну в чергу та розділення читання й запису. Розбираємо, як це закривається.
Що дає вивірена архітектура на 1С-Битрикс
Перезбирання архітектури 1С-Битрикс починається не з косметики, а з вимірювань: скільки віддає ключова сторінка під навантаженням, які запити йдуть у базу, що кешується, а що перераховується за кожного звернення.
Після винесення важких вибірок і налаштування кешування відгук каталогу й карток перестає залежати від розміру бази — сторінка віддається за частки секунди й тримає пік відвідуваності без зростання кількості серверів.
Відмовостійкість сайту — наслідок розділення ролей, а не одного потужного вузла: застосунок, база, файли й черга фонових завдань живуть окремо, стан реплікується, єдина точка відмови зникає зі схеми.
Час відновлення при цьому вимірюється хвилинами, а не годинами очікування резервної копії, бо перемикання на резервний вузол описано регламентом і відпрацьовано на навчаннях, а не вигадується в момент збою.
Вартість простою вимірюється у втрачених замовленнях і зверненнях, а не в абстрактних ризиках: поки сайт недоступний, клієнт іде до конкурента й рідко повертається.
Тому перше питання на консультуванні — скільки хвилин недоступності напрям вважає допустимим і що саме має продовжувати працювати: приймання заявок, особистий кабінет, інтеграція зі складом.
Викочування релізів отримує таку саму вимірювану межу: набір змін проходить збирання й автоматичні перевірки, на сервер іде готовий артефакт, відкат на попередню версію — одна операція.
Обсяг ручних дій скорочується з десятків кроків до кількох підтверджень, і оновлення перестає бути подією, яку відкладають на ніч. Контрольні точки після перезбирання — відгук ключових сторінок, частка відмов, час відновлення та кількість ручних операцій під час викочування.
Режими роботи: один вузол, кластер, розділення ролей
Режим роботи визначає, що саме доведеться змінювати, коли навантаження зросте вдвічі: підсилити один сервер, рознести ролі по машинах або додати вузли за балансувальником.
Вибір залежить не від розміру каталогу, а від того, де система впирається зараз — у диск, у базу чи в обробку запитів. Нижче — реальні варіанти, між якими обирають на старті та під час переїзду.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Один вузол | Каталог на кілька тисяч позицій, рівномірний трафік, файли й база на тій самій машині | Будь-який збій кладе сайт повністю; резервне копіювання й оновлення потребують зупинки |
| Підсилення одного вузла | Зростання передбачуване, вузьке місце — процесор або диск | Упирається в стелю конфігурації, відмова залишається єдиною точкою |
| Розділення ролей | Важкі вивантаження з 1С, великий архів файлів, багато авторизованих користувачів | Ролі пов’язані мережею: відкладена реплікація й короткий час очікування дають розсинхронізацію даних |
| Кластер серверів | Пікові розпродажі, сезонний трафік, вимога відмовостійкості | Потрібні спільне файлове сховище й винесення сесій, інакше відвідувача «переносить» між вузлами |
Кластер і балансування навантаження працюють тільки разом зі спільним файловим сховищем і вивіреною реплікою бази.
Якщо картинки й кеш залишаються локально на кожному вузлі, відвідувач отримує різні версії сторінки за кожного оновлення; якщо запис іде в репліку — розходяться кошики й замовлення.
Тому режим обирають за вимогами до відновлення, а не за кількістю серверів: спочатку фіксуємо допустимий час простою, потім під нього підбираємо схему.
Етапи робіт: від аудиту схеми до передачі регламентів
Роботи йдуть фіксованою послідовністю: кожен етап закривається артефактом, який можна перевірити до переходу до наступного.
Так ми не переносимо в робочий контур те, що не перевіряли, і не змінюємо архітектуру частинами — інакше причини деградації потім не відокремити від наслідків правок.
- Аудит інфраструктури. Знімаємо факти: версії ядра й модулів, конфігурація вебсервера та бази даних, планувальник, черги, зовнішні інтеграції, фактичні піки за логами відвідуваності. На виході — карта поточного стану й список вузьких місць, а не загальні висновки.
- Схема архітектури. Проєктуємо цільове розділення ролей: вебшар, база, кеш, пошук, винесені фонові завдання. Фіксуємо точки відмови, поведінку за перевантаження та порядок дій під час відкату.
- Збирання тестового контуру. Розгортаємо копію зі знеособленими даними й тими самими версіями компонентів, що в робочому контурі. Інакше результати перевірок на ньому нічого не доводять.
- Навантажувальна перевірка. Профіль навантаження будуємо за реальними логами, а не за середніми значеннями. Ступінчасто піднімаємо навантаження й дивимося час відповіді на ключових сценаріях, частку помилок, споживання ресурсів і місце, де система ламається першою.
- Перенесення без простою. Переводимо трафік на нову схему за мінімального вікна робіт: синхронізація даних, перемикання, контрольні вимірювання. Відкат виконується за заздалегідь описаною процедурою, а не за рішенням на місці.
- Спостережуваність. Налаштовуємо метрики й пороги оповіщень за вузлами, чергами та часом відповіді — щоб деградація виявлялася до скарг користувачів.
- Передача регламентів. Віддаємо схему, правила оновлення, інструкції щодо типових інцидентів і розбір змін команді замовника.
Що залишається в проєкті після здачі робіт
Передача проєкту — це не архів і прощальний дзвінок. Ми віддаємо комплект, за яким ваша команда може розгорнути середовище з нуля, випустити реліз, відкатити його й розібрати інцидент без нас. Усе пишеться під конкретну інфраструктуру проєкту, а не за шаблоном, і оновлюється під час робіт.
- Схема інфраструктури — середовища розробки, приймання й продакшну, ролі серверів, зв’язки з 1С і зовнішніми сервісами, точки входу трафіку, кеш і черги обробки; окремо позначені вузькі місця та зовнішні залежності.
- Документація проєкту — структура рішення, кастомні компоненти й модулі, змінені файли ядра, історія архітектурних рішень з обґрунтуванням: чому зроблено так і що відкинули.
- Конфігурації середовищ — параметри кешування та індексації, завдання за розкладом і фонові агенти, значення, що змінюють поведінку сайту, з позначкою, що можна безпечно правити.
- Політики доступу — ролі в адміністративній панелі за інфоблоками й розділами, права на сервер, порядок видачі та відкликання доступів, ротація ключів і облікових записів.
- Регламент обслуговування — періодичність резервного копіювання й перевірка відновлення, порядок оновлення платформи, вікна робіт, канали оповіщення та критерії ескалації.
- Інструкції супроводу — типові операції за кроками: публікація контенту, випуск і відкат релізу, підключення нової інтеграції, діагностика частих відмов кешу й обміну.
- Реєстр інтеграцій та облікових даних — що з чим пов’язано, де зберігаються ключі, яка сторона відповідає за обмін і що робити у разі розходження даних.
Приймання відбувається за чек-лістом: ви перевіряєте, що за інструкцією справді розгортається середовище й проходить відкат, а не лише те, що документи існують.
Кейс: як рознесли навантаження й прибрали падіння каталогу
Що було
Каталог на 1С-Битрикс працював на одному сервері: застосунок, база й обмін з обліковою системою ділили одні ресурси.
Обмін запускався за розкладом і на час вивантаження цін та залишків забирав з’єднання до бази — картки починали віддаватися секундами, частина запитів зривалася через перевищення часу очікування. Пік припадав на ранок, коли менеджери відкривали адмінку, а відвідувачі — каталог.
Що змінили
Рознесли ролі: окремий вузол під застосунок, окремий під базу з реплікою для читання каталогу, кеш винесли в спільний сервіс. Обмін перевели в асинхронний режим через чергу — порції даних складаються в проміжне сховище й застосовуються покроково, не блокуючи вітрину.
Часто відкривані розділи отримали прогрів кешу після публікації: сторінка збирається заздалегідь, а не першим відвідувачем.
Що стало
Каталог перестав залежати від графіка обміну: вивантаження йде паралельно з роботою вітрини. Відгук карток на піку скоротився в рази, збої за часом очікування на розділі каталогу зникли.
Обмін став спостережуваним — статус кожного пакета видно в журналі, неповний пакет застосовується повторно й не тягне за собою інші, тоді як раніше доводилося перезапускати вивантаження повністю.
Вимірювання знімали за одними й тими самими сценаріями до й після: відкриття каталогу, картка товару, пошук. Тому цифри зіставні, а схему — розділення ролей, асинхронний обмін, прогрів кешу — можна переносити на інші проєкти з частими вивантаженнями.
Чим відрізняється перезбирання на живій системі від перенесення?
Це два різні сценарії, і вибирають між ними за ціною помилки. Перезбирання на живій системі — правки вносять у працюючий контур: шаблони, компоненти, налаштування кешу, міграції прямо на бойовій базі.
Перенесення проєкту — поруч піднімають другий контур, розгортають копію бази й файлів і обкатують усе там.
Перезбирання виграє швидкістю: не потрібно синхронізувати дані й чекати прогріву нового контуру. Але ризики змін лягають на користувачів — міграція схеми йде за бойовими даними, відкат можливий тільки зі знятої копії, а скидання кешу видно на живих запитах.
Перенесення дорожче на підготовці: тестовий контур має повторювати бойовий — та сама гілка 1С-Битрикс, та сама конфігурація вебсервера, той самий пошуковий рушій і правила обміну з 1С.
Зате перемикання без простою роблять на рівні маршрутизації: тримають обидва контури, переносять накопичені зміни бази, переводять домен і закривають запис у старий.
Правило вибору просте. Змінюються структура інфоблоків, властивості, правила обміну з 1С або логіка модулів — це перенесення: ціна помилки вища за вартість другого контуру.
Косметика в шаблоні, налаштування кешу, точкові правки компонентів допустимі на живому контурі — за знятої копії та плану відкату.
Ми розкладаємо задачу за цими двома сценаріями ще на етапі оцінки й показуємо, де точка неповернення, — до початку робіт.
Часті технічні сумніви перед початком робіт
Сумніви на старті майже завжди інженерні, а не організаційні: що буде з працюючим сайтом, на що перетвориться код після оновлення, чи реально вести проєкт своїми силами. Нижче — питання, які ставлять найчастіше, і відповіді по суті.
Чи доведеться зупиняти сайт на час робіт?
Ні. Переносимо й оновлюємо на окремому стенді з копією бази та файлів, перевіряємо критичні сценарії — замовлення, оплата, авторизація, вивантаження в облікову систему. Публікація — це перемикання на підготовлений контур; повернення на попередній стенд займає хвилини.
Оновлення ядра зламає наші доопрацювання?
Ламаються не доопрацювання як такі, а рішення в обхід штатних точок розширення: правки прямо в ядрі, монолітні шаблони. Знімаємо карту таких місць і переводимо логіку в штатні механізми — далі оновлення ставляться без ручного злиття файлів.
Чи не зросте кількість помилок після оновлення?
Спочатку зростає їхня видимість: вмикаємо журналювання й набір регресійних перевірок на критичні шляхи. Оновлення ставимо ступенями з перевіркою після кожного — причину збою видно одразу, відкат залишається точковим.
Чи зможемо далі вести проєкт своїми силами?
Так, і це умова нормальної передачі. Віддаємо документацію з архітектури, схему середовищ, регламент оновлень і журнал змін. Ваших інженерів вводимо в контур заздалегідь: розбір коду, спільні релізи, розбір інцидентів на вашій стороні.
Якщо вашого випадку в списку немає — опишіть задачу, розберемо окремо й повернемося з оцінкою та планом.Обговоримо задачу й повернемося з оцінкою та планом
Щоб оцінка строків спиралася на факти, а не на припущення, потрібні вхідні дані щодо проєкту. Архітектура рішення на 1С-Битрикс визначається навантаженням, обмінами та станом даних — список нижче закриває саме ті місця, де оцінка найчастіше розходиться з реальністю на старті.
- Поточний контур: редакція продукту, де розміщено сайт, як викочуються зміни й хто це робить.
- Інтеграції: з чим відбувається обмін (облікова система, склад, платежі, доставка, служби розсилок), за яким розкладом і що відбувається за розриву зв’язку.
- Навантаження: добова відвідуваність, пікові сплески, обсяг каталогу й кількість одночасних користувачів у години максимуму.
- Дані: обсяг каталогу й замовлень, звідки переносимо, чи потрібно зберігати історію та зв’язки між сутностями.
- Обмеження: жорсткі дати, регламенти й вимоги до доступів, що не можна змінювати в поточному контурі.
- Пріоритети: що критично в першій черзі, а що можна винести на наступний етап.
За цими вхідними даними повертаємося з планом робіт за етапами, оцінкою строків і складом робіт — від проєктування до виведення в продакшн.
Якщо частину даних ще не зібрано, обговорюємо задачу в тому вигляді, у якому вона є, і фіксуємо припущення письмово, щоб початок проєкту не перетворювався на перезбирання домовленостей.
