Архитектура и масштабируемость CS-Cart¶

Общие сведения¶

CS-Cart — монолитное PHP-приложение. Витрина, административная панель, REST API, бизнес-логика и механизм расширения работают в рамках одного приложения и одного runtime-окружения.

Платформа поддерживает расширение через модули, хуки, контроллеры, шаблоны и сервисные классы без использования и нативной поддержки микросервисов. Такой подход дает ряд преимуществ:

• простота эксплуатации: одна установка и единый цикл обновлений;
• отсутствие риска рассинхронизации данных между сервисами;
• более предсказуемая отладка и диагностика проблем;
• простота расширяемости через хуки, модули и шаблоны без необходимости поддерживать распределенную систему;
• низкий порог входа: CS-Cart можно быстро развернуть на обычном хостинге или VPS-сервере;
• единый REST API для интеграции с основными возможностями платформы.

Масштабирование выносится на уровень проверенных инфраструктурных компонентов (кэша, CDN, балансировщиков нагрузки и базы данных), а не достигается за счет дробления бизнес-логики на отдельные сервисы.

CS-Cart можно развернуть в горизонтально масштабируемой инфраструктуре, однако масштабирование достигается за счет внешних инфраструктурных компонентов, а не встроенных механизмов кластеризации.

Это дает дополнительную гибкость: платформа не навязывает жесткую кластерную архитектуру или фиксированную схему серверов. Пользователь самостоятельно определяет, как масштабировать проект и какие внешние компоненты использовать. Такой подход особенно ценен для технически подготовленных команд и проектов со специфическими требованиями к инфраструктуре.

Горизонтальное масштабирование¶

CS-Cart поддерживает работу на нескольких веб-серверах. Такая схема требует ручной настройки инфраструктуры. Типичная конфигурация может включать несколько веб-серверов с CS-Cart, балансировщик нагрузки, общее файловое хранилище, общий Redis, общую базу данных.

CS-Cart не выполняет автоматическую настройку или оркестрацию распределенной инфраструктуры. Основное преимущество такого подхода — прозрачность, контроль и предсказуемость инфраструктуры. Платформа не скрывает инфраструктурные механизмы и не ограничивает пользователя встроенной схемой кластеризации.

Настройка распределенной схемы — нескольких серверов, балансировщиков, общих файлов и кэша — выполняется администратором, хостинг-провайдером или DevOps-командой. При этом CS-Cart поддерживает работу с Redis, CDN, Varnish и облачными хранилищами, что позволяет строить масштабируемую инфраструктуру с учетом конкретных требований проекта. Такой подход особенно полезен для продвинутых пользователей и компаний, которые хотят самостоятельно контролировать архитектуру своей инфраструктуры.

Механизмы кэширования¶

CS-Cart использует несколько уровней кэширования для повышения производительности и снижения нагрузки на базу данных. Поддерживаются следующие встроенные механизмы кэширования:

• Redis. Redis можно использовать как хранилище кэша, пользовательских сессий и блокировок. Это особенно полезно, если CS-Cart работает на нескольких веб-серверах: все серверы могут обращаться к одному Redis и использовать общий кэш и общие сессии.
• CDN. CS-Cart умеет подключать CDN для раздачи статических файлов, например изображений, CSS, JavaScript и assets. В коде предусмотрен CDN-бэкенд CloudFront. CDN помогает быстрее отдавать файлы пользователям и снижает нагрузку на основной сервер.
• Varnish / обратный прокси-кэш (reverse proxy cache) поддерживается через модуль Full Page Cache. CS-Cart может работать с Varnish для кэширования целых страниц. Varnish ставится перед приложением и может отдавать уже готовые страницы без обращения к PHP и базе данных. В CS-Cart есть механизм заголовков и инвалидации кэша для Varnish.
• Встроенный кэш приложения. CS-Cart кэширует настройки, служебные данные, блоки витрины и часть подготовленных данных приложения. По умолчанию кэш может храниться в файлах, но его можно переключить на другие бэкенды, включая Redis.
• Кэш статических файлов и ресурсов (assets). Система кэширует и переиспользует скомпилированные CSS/JavaScript и другие статические ресурсы. Эти файлы также могут отдаваться через CDN.

Шардирование и партиционирование¶

CS-Cart не предоставляет встроенной поддержки репликации или шардирования базы данных на уровне приложения. Платформа использует одну конфигурацию подключения к базе данных: db_host / db_name. Все запросы приложения (как чтение, так и запись) выполняются через это подключение.

Такой подход упрощает резервное копирование, восстановление, миграции и обновления, обеспечивает ACID-гарантии для заказов, остатков и промоакций (ACID — атомарность, согласованность, изоляцию и долговечность операций), позволяет избежать проблем рассинхронизации между master и replica, а также использует единую схему базы данных с базовыми индексами.

Отсутствие встроенного шардирования и репликации компенсируется следующими инфраструктурными механизмами:

• Redis и файловый кэш снижают количество обращений к базе данных;
• Varnish позволяет отдавать страницы без PHP и SQL-запросов;
• CDN берет на себя доставку статического контента;
• используются пагинация и временные таблицы для тяжелых выборок;
• S3-совместимые хранилища позволяют использовать общие файлы на нескольких веб-серверах;
• массовые операции выполняются пакетами, а не через шардирование.

В конфигурации CS-Cart отсутствуют отдельные настройки master/slave или primary/replica. Для большинства интернет-магазинов встроенные механизмы репликации не требуются, поскольку типичная высокая нагрузка на операции чтения (read-heavy workload) витрины обычно эффективно закрывается комбинацией кэша, CDN и Varnish.

Шардирование каталога по партициям или шардам в продукте также отсутствует. Крупные каталоги обрабатываются в рамках единой базы данных, если не используются внешние инфраструктурные решения. Для компенсации используются инфраструктурные механизмы, описанные выше.

Оптимизация базы данных¶

CS-Cart содержит базовые индексы базы данных и инструмент оптимизации таблиц (Optimize database в настройках), но не предоставляет автоматический подбор индексов для больших каталогов. Для крупных магазинов оптимизация индексов обычно выполняется вручную на основе анализа нагрузки и медленных SQL-запросов. Вместо автоматического подбора индексов рекомендуется использовать внешние инструменты мониторинга и диагностики, например:

• Percona Toolkit;
• MySQL Enterprise Monitor;
• slow_query_log;
• настройку InnoDB buffer pool;
• увеличение объема RAM;
• апгрейд серверного оборудования при необходимости.

Функция Optimize database выполняет техническое обслуживание таблиц базы данных: оптимизирует хранение данных, обновляет статистику для планировщика запросов MySQL и пересортировывает данные в отдельных таблицах при необходимости.

Этот инструмент не предназначен для автоматической настройки производительности больших каталогов. Для ускорения работы крупных каталогов обычно используются кэширование, оптимизация серверной инфраструктуры и ручная настройка индексов на основе анализа медленных запросов.

Настройка и оптимизация индексов выполняются вручную в зависимости от характера нагрузки и структуры каталога.