Встановлення Vendure: що ламається на робочому контурі магазину
Робочий контур магазину розривається не на старті, а на піковому навантаженні.
Коли розпродаж збігається з розсилкою по базі покупців, каталог збирає кожен лістинг фільтрів із десятків звернень до бази, пул з'єднань перестає встигати, і час відповіді зростає нелінійно: частина кошиків втрачає вибрані позиції, покупець переходить на сторінку помилки.
Те саме вузьке місце каталогу спливає під час перерахунку знижок і залишків — важке завдання виконується в тому самому процесі, що й віддача сторінки.
Другий розрив — завислі оплати.
Шлюз списав кошти, підтвердження не дійшло або обробилося двічі, замовлення залишилося в проміжному статусі: товар не зарезервовано, повернення робиться вручну, а звірка з провайдером іде за вивантаженнями раз на добу, коли розбіжностей уже накопичилося на кілька днів.
Третій — ручні правки під час оновлення.
Модулі, схема даних і оформлення замовлення правляться прямо на робочому сервері, бо так швидше; після наступного релізу зміни затираються або розходяться з репозиторієм, і оновлення перетворюється на нічну операцію з ручним відкатом і прогоном сценаріїв за паперовим чек-лістом.
Встановлення Vendure на окремий контур знімає всі три вузли.
Каталог віддається з прогрітого кешу, важкі завдання — індексація, перерахунок цін, листи — йдуть в окремі воркери через чергу, підтвердження оплат обробляються ідемпотентно, з повтореннями та журналом розбіжностей, щоб повтор вебхука не створював друге замовлення.
Правки при цьому живуть у репозиторії: міграції версіонуються, налаштування середовища винесені з коду, а збірка і схема перевіряються до викатки.
Розбираємо, як це закривається: від підготовки сервера та ролей до черг, кешу й перевірок перед публікацією.
Що дає грамотна збірка магазину: швидкість і відмовостійкість
Збірка інтернет-магазину на Vendure — один передбачуваний контур: каталог, кошик, оформлення замовлення й адмінка працюють на спільному наборі моделей і контрактів.
Тому час відгуку каталогу не зростає разом із розміром вибірки: фільтри та посторінковий вивід рахує база, а важкі агрегати віддаються з прогрітого кешу. Список із сотень позицій відкривається так само швидко, як картка одного товару.
Відмовостійкість тут — набір рішень, а не обіцянка: кілька екземплярів застосунку за балансувальником, винесені фонові обробники для листів, вивантажень і синхронізації залишків, роздільні пули підключень до бази для вітрини й адмінки.
У разі випадіння вузла трафік переходить на живий екземпляр, а час відновлення вимірюється хвилинами, а не годинами простою.
Разом із цим зникає цілий клас відмов, який зазвичай спливає в пік: розсинхрон залишків між вітриною та складом, подвійне оформлення одного замовлення при повторному надсиланні форми, втрачені позиції в кошику після перезапуску.
Це закрито транзакціями на рівні бази та повторюваними операціями оформлення — статус замовлення не залежить від того, чи встиг відповісти зовнішній сервіс.
Стійкість до навантаження перевіряється не синтетикою, а розпродажем: ми обмежуємо кількість паралельних важких запитів, кешуємо каталог і категорії, а оформлення замовлення тримаємо на окремому пулі.
Вітрина під навантаженням не гальмує оплату, тому частка замовлень, доведених до оплати без повторів і помилок, залишається рівною і в пікові години.
Варіанти розгортання: свій сервер, оренда, змішана схема
Розміщення магазину на Vendure визначає не розмір каталогу, а те, хто відповідає за оновлення ядра, резервне копіювання та масштабування в пікові години.
Застосунок потребує процес-менеджера, бази даних, обробника фонових завдань і сховища медіа — це можна зібрати самостійно, віддати провайдеру або розділити контури. Нижче — три робочі схеми та їхні обмеження.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Свій сервер | Потрібен повний контроль над середовищем, свої правила доступу та розміщення в конкретній юрисдикції | Патчі ОС, оновлення застосунку й резервні копії — на вашому боці; помилка в конфігурації дає простій без зовнішньої підтримки |
| Оренда керованого сервера | Немає виділеного інженера, потрібен швидкий запуск і передбачувана базова експлуатація | Нижчий ліміт за навантаженням, обмеження на тривалі фонові завдання та розмір черги, вікна обслуговування задає провайдер |
| Змішана схема | Вітрину й адмінку обслуговує провайдер, а важкі завдання — обробка медіа, вивантаження, обмін з обліковою системою — виносяться на окремий контур | Складніша мережа й права доступу; обов'язкові єдині правила збірки та однакові змінні середовища на всіх контурах |
Схему фіксують до перенесення даних, а не після: від неї залежать спосіб деплою, точки резервного копіювання та порядок відкатів.
На етапі оцінки ми звіряємо вибраний варіант із профілем навантаження й перевіряємо, що фонові завдання та база не виявляться вузьким місцем при зростанні каталогу.
Встановлення Vendure за кроками: від аудиту до передачі
Порядок робіт вибудуваний так, щоб кожне рішення спиралося на факти попереднього кроку. Спочатку фіксуємо, що вже працює в контурі, потім проєктуємо схему — і лише потім торкаємося робочого середовища, щоб встановлення не перетворилося на серію аварійних правок.
- Аудит контуру. Розбираємо сервери, базу, кеш, черги, DNS і сертифікати, поточні ліміти та точки відмови. На виході — карта того, що перевикористовуємо, а що змінюємо.
- Схема розгортання. Визначаємо, де живуть застосунок, база, медіа та фонові завдання, як між ними ходять запити й де втрачається сесія. Схему узгоджуємо до першої команди на сервері.
- Права доступу. Окремий системний користувач, розкладені по каталогах секрети та змінні середовища, ролі бази за мінімумом необхідного: застосунок не працює від суперкористувача.
- Встановлення та налаштування. Розгортаємо актуальну гілку Vendure, проганяємо міграції, підключаємо плагіни та обробники черг, налаштовуємо кеш та індексацію каталогу.
- Перевірка під навантаженням. Проганяємо сценарії покупця — пошук, кошик, оформлення замовлення — на профілі, близькому до реального трафіку, і дивимося час відповіді та поведінку бази під піком.
- Копії та відкат. Налаштовуємо регулярні знімки бази й медіа та перевіряємо відновлення на окремому стенді, а не лише факт створення копії.
- Передача проєкту. Віддаємо документацію, регламент оновлень, розбір схеми та доступи вашій команді.
На виході — працюючий контур і зрозумілий набір дій на випадок оновлення або збою.
Що залишається у вас: конфігурації, схеми, регламенти, доступи
Ми здаємо не лише працюючий сервер, а й усю обв'язку навколо нього: конфігурації розгортання, схеми інфраструктури, регламенти та доступи. Комплект збирається так, щоб його прийняла будь-яка інша команда — без наших усних пояснень і без відновлення рішень із пам'яті.
- Конфігурації розгортання — файли середовища, параметри збірки та запуску застосунку, налаштування каталогу, кошика й оформлення замовлення з поясненням, яке значення на що впливає.
- Схеми інфраструктури — що і де розміщено: сервер застосунку, база даних, кеш, черги, зовнішні сервіси, як вони пов'язані між собою й де розташовані точки відмови.
- Регламент оновлень — порядок випуску нової версії, процедура відкату на попередню, список перевірок до та після викладки.
- Резервне копіювання — розклад, глибина зберігання копій, регламент перевірки відновлення й сама процедура розгортання з копії на чистому середовищі.
- Доступи та ролі — перелік облікових записів, рівні прав, місце зберігання секретів і порядок їх планової зміни.
- Документація — карта коду та плагінів, опис нестандартних рішень, журнал змін і відомих обмежень із зазначенням, що і чому зроблено саме так.
- Інструкція для чергової команди — як читати журнали, які показники вважати нормою і за яких ознак піднімати тривогу.
Окремим блоком іде документація з доробок: що саме ми розширювали в Vendure, де лежить код плагінів, як їх оновлювати разом із ядром і що зламається, якщо пропустити проміжну версію.
Такий комплект можна передати сторонньому підряднику або зібрати свою команду — робота продовжиться з тієї самої точки, а не з повторного вивчення системи.
Кейс: магазин перестав втрачати замовлення при пікових навантаженнях
До перенесення магазин із каталогом на 12 000 позицій не тримав пік: у дні розпродажів до 4% замовлень губилося. Оплата покупця проходила, а запис замовлення не створювався — розбір лягав на підтримку. Оновлення викладали вночі, зупиняючи прийом замовлень на 40 хвилин.
Що змінили
Каталог перенесли зі звіркою: вивантажили через програмний інтерфейс старої платформи, звірили кількість позицій, залишки та прив'язку до категорій, наскрізні ідентифікатори зберегли — адреси сторінок і позиції в пошуку не поїхали. Магазин розгорнули на актуальній гілці Vendure у конфігурації з кількома вузлами застосунку.
Замовлення та списання залишку пишуться однією транзакцією, у спроби є ключ ідемпотентності: повторне надсилання не створює дубль, а збій відкочує замовлення цілком. Кошик і сесії винесли в спільне сховище — перезапуск процесу більше не скидає покупця посеред оформлення.
Викладка йде по черзі на резервні вузли, трафік повертається після перевірки готовності, тому оновлення перестало бути вікном простою.
Що стало
| Метрика | До | Після |
|---|---|---|
| Втрачені замовлення на піку | до 4% | 0 |
| Простій при оновленні | 40 хвилин | без зупинки |
| Відгук сторінки категорії | 1,8 с | 0,4 с |
| Замовлення, що доходять до підтвердження | 96% | 99,8% |
На порівнянному розпродажному навантаженні не втрачено жодного замовлення, підтримка перестала розбирати скарги «оплатив, але не надійшло». Далі розбираємо, як така конфігурація збирається з нуля.
Що робити, якщо магазин уже працює на іншій платформі?
Переносимо діючий магазин у два контури: попередній продовжує приймати замовлення, поки новий на Vendure і NestJS наповнюється каталогом і проганяється в тестовому режимі.
Продажі не зупиняються ні на етапі імпорту, ні на етапі звірки — простій зводиться до короткого вікна запису в момент перемикання.
Каталог імпортуємо з вивантаження старої платформи: зіставляємо артикули, варіанти, атрибути, категорії, медіа та переклади за ключами, а не за назвами.
Імпорт ідемпотентний — повторний прогін оновлює записи, а не створює другу картку на той самий товар, тому розбіжності можна усувати ітеративно, не ламаючи вже перенесене.
Історію замовлень і клієнтів переносимо окремим проходом і тримаємо лише для читання: статуси, суми, позиції та прив'язки до покупців. Так звітність, повторні покупки та повернення за старими замовленнями залишаються робочими, але не перетинаються з новим обліком.
Поки триває перенесення, залишки та ціни тягнуться з попередньої платформи дельтами за часом зміни — новий контур бачить актуальну картину, але продажі закриває старий магазин.
Перемикання робимо на низькому трафіку: коротке вікно запису, фінальна дельта, переведення трафіку та звірка замовлень за лічильниками. Попередній контур залишається гарячим резервом і каналом відкату, поки розбіжності не зійдуть у нуль.
Окремо виносимо в реєстр те, що не переноситься автоматично: сертифікати, промокоди та бонусні баланси. Їхню міграцію узгоджуємо до перемикання — інакше після запуску спливуть розбіжності у знижках, які доведеться розбирати вручну на живих замовленнях.
Часті сумніви перед стартом: навантаження, доступи, оновлення
Сумніви перед стартом зазвичай одні й ті самі: чи вбудується платформа в поточний стек, чи витримає каталог пікове навантаження, хто і що змінює в адмінці, як проходять оновлення і що залишиться після збою.
Чи вбудується платформа в наш поточний стек?
Vendure — застосунок на NestJS, розширення пишуться як звичайні модулі цього фреймворку. Розробники залишаються у звичних шарах і схемі міграцій замість вивчення окремої мови плагінів. Зовнішні системи підключаємо через штатний API платформи.
Чи витримає каталог пікове навантаження?
Каталог на читання віддається через кеш, тому видача категорій і карток не впирається в базу на кожному запиті. Фільтри, добірки та пошук ідуть на окремий сервіс.
Перед запуском проганяємо навантажувальний тест на піковому профілі й дивимося час відповіді каталогу та кошика при сплеску трафіку.
Як розмежовуються права доступу?
Ролі описуємо за операціями: контент-менеджер править картки й медіа, товарознавець — ціни та залишки, підтримка бачить замовлення, але не змінює каталог. Вхід в адмінку — через корпоративну авторизацію, зміни потрапляють у журнал: видно, хто і коли зняв товар з публікації.
У якому порядку виходять оновлення?
Планові оновлення ставимо в узгоджене вікно: спочатку копія робочої бази, прогін міграцій і перевірок на ній, потім викладка. Мажорні переходи робимо окремим етапом із перевіркою розширень. Відкат повертає попередню збірку та схему бази, тому вікно не розтягується на ніч.
Що з резервними копіями?
Щоденний дамп бази та снапшот медіа зберігаємо поза основним контуром, окремо від продакшену. Раз на квартал розгортаємо копію на тестовому стенді: копія, яку жодного разу не відновлювали, копією не вважається. Тому повернення в робочий стан вимірюється хвилинами.
Обговоримо задачу: з чого почнемо і що потрібно з вашого боку
Розмову починаємо з розбору задачі: що вже працює, де вузькі місця і який результат потрібен на виході. Нам важливо зрозуміти не лише «потрібен інтернет-магазин», а як влаштований ваш каталог, хто і як із ним працює щодня, які процеси ламаються зараз.
За підсумками повертаємося з оцінкою та планом — з етапами, порядком викладки й точками, де потрібне ваше рішення.
Щоб оцінка була предметною, а не «на око», від замовника потрібен мінімум:
- доступ до репозиторію або архів із поточним кодом і налаштуваннями середовищ;
- опис інфраструктури: де розгортаємо, чи є обмеження щодо мережі, доступів і резервного копіювання;
- перелік інтеграцій — прийом платежів, доставка, склад, облікова система, розсилки;
- структура каталогу: категорії, варіанти товарів, мови та валюти, правила знижок і акцій;
- очікуване навантаження: скільки позицій у каталозі та який пік замовлень на добу;
- відповідальний з вашого боку — хто приймає роботу та узгоджує спірні місця.
Цього достатньо, щоб зібрати план: підготовка середовища, встановлення Vendure на NestJS, перенесення даних, підключення інтеграцій, перевірка під навантаженням і запуск.
Терміни називаємо за етапами, а не однією цифрою — так видно, що від чого залежить і де ми чекаємо на ваші дані. Опишіть задачу — повернемося з оцінкою, планом і питаннями, які варто закрити до старту.
