Стабилизация технической части продукта электронной коммерции и проверка корректности всех процессов должны начинаться заранее и заканчиваться за несколько недель до периода повышенной активности клиентов (например, к Черной пятнице).
Но массовая распродажа товаров зачастую влечет за собой нестабильность всей ИТ-системы маркетплейса, поскольку не предпринимаются никакие шаги по обновлению конфигурации или кода.
Мы с командой постарались заранее разобраться, что нужно сделать, чтобы электронная коммерция выдержала наплыв покупателей.
Техническая команда всегда готова обеспечить резервное копирование.
Даже если вы уверены в своей ИТ-системе, всегда есть вероятность, что что-то пойдет не так.
У вас должна быть система мониторинга и уведомлений, позволяющая быстро получать информацию об аномальном поведении платформы, чтобы вы могли принять меры для безболезненного решения любых проблем.
Чтобы быстро реагировать на проблемы, ваша команда разработчиков должна находиться в режиме быстрой доступности.
Цель состоит в том, чтобы иметь возможность решать проблемы до того, как они станут критическими.
Отказоустойчивость и надежность как часть архитектуры
Ваш рынок или экосистема должны быть спроектированы и разработаны с нуля, чтобы иметь возможность справляться с быстро растущими рабочими нагрузками.Мы рекомендуем создавать продукт, разделенный на отдельные сервисы, каждый из которых представляет собой отдельный компонент, имеющий возможность автоматического масштабирования (Kubernetes).
Связь между сервисами должна происходить путем обмена сообщениями через асинхронные очереди с логикой повторной отправки в случае ошибки.
Это обеспечивает дополнительную надежность, если одна из служб перегружена, позволяя обработать сообщение немного позже, когда нагрузка спадет или служба масштабируется в сторону увеличения ресурсов.
Например, если вы создаете торговую площадку на базе продукта Scallium, то наша сервисная архитектура (SOA) в сочетании с кластером Kubernetes обеспечивает горизонтальное масштабирование.
Триггерами для запуска процесса масштабирования сервисов являются возрастающая загрузка ЦП, увеличение объема используемой оперативной памяти и увеличение количества сообщений на шине.
Эту функцию в Сервисной архитектуре обычно выполняет Шина сообщений, которую мы реализуем на базе RabbitMQ. 
Мы реализовали автоматическое масштабирование на уровне Kubernetes, которое развернули на гибкой облачной платформе Google (GCP).
Это позволило плавно масштабировать все ресурсы, а затем снова автоматически сокращать их при падении нагрузки.
Платформа GCP позволяет из коробки реализовать функционал автоматического масштабирования узлов в кластере Kubernetes, что при увеличении нагрузки на приложение увеличивает количество доступных ресурсов для автомасштабирования самого приложения.
Система мониторинга SaaS-платформы Система мониторинга работоспособности
Мы рекомендуем разработать инструмент мониторинга, который автоматически и круглосуточно анализирует работоспособность и производительность системы, ведет логи, формирует отчеты о событиях и внештатных ситуациях, оповещает дежурных.Данные анализируются соответствующим сервисом, который прогнозирует точки отказа и дает возможность техническим специалистам заранее отреагировать до возникновения нештатных ситуаций.
Система мониторинга связана с корпоративным чатом для информирования соответствующих линий поддержки.
Система мониторинга должна работать на двух уровнях:
- Уровень инфраструктуры
- Уровень приложения
На уровне приложения у нас есть Sentry DSN; позволяет отслеживать работу приложения на уровне взаимодействия сервисов.
Эти уровни являются взаимодополняющими и в результате анализа позволяют предупредить о возникновении нештатных ситуаций.
Или оперативно принимать меры по возникающим проблемам.
Система резервного копирования платформы Marketplace
Одним из аспектов надежности любой платформы (например, маркетплейса) является стратегия создания резервных копий.Если архитектура спроектирована по парадигме сервисной архитектуры, то она фактически позволяет вынести ключевые точки хранения данных за пределы кластера Kubernetes и использовать сервисы как сервисы от провайдера (GCP).
Это упрощает не только администрирование такого приложения, но и создание/обслуживание системы резервного копирования.
А поскольку все ключевые точки (у нас есть наборы сервисов разных типов — PostreSQL, MongoDB, RabbitMQ, S3 Bucket и десятки сервисов) являются «автономными» сервисами провайдера, резервное копирование реализовано с помощью нативных инструментов GSP, а это означает простоту управления.
, надежность и надежность .
Теги: #отказоустойчивость #Управление электронной коммерцией #Развитие электронной коммерции #платформа #маркетплейс
-
Бросить Монетку
19 Oct, 24 -
Agile: 9 Плохих Советов
19 Oct, 24 -
Новая Жизнь Авто-Fm-Передатчика
19 Oct, 24 -
Улучшение Звука Колонок Sven Stream
19 Oct, 24 -
Отправляем Файлы До 2Гб Бесплатно
19 Oct, 24 -
Видеокапча От Nucaptcha
19 Oct, 24 -
Intel Инвестирует В Vmware
19 Oct, 24
