Создание крупной, масштабируемой платформы электронной коммерции

В этой статье разработчиками компании DST Global, рассматривается архитектура распределенной и масштабируемой платформы электронной коммерции с множеством сервисов и компонентов, размещенной на облачной платформе, такой как AWS.

Высокоуровневое проектирование платформы электронной коммерции, такой как Amazon, Ozon, WB, Walmart, СберМегаМаркет и т.д.

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

Что такое система электронной коммерции и каковы ее преимущества?

Система электронной коммерции — это SaaS, которая позволяет компаниям продавать в основном продукты и, в некоторых случаях, услуги онлайн, предоставляя клиентам цифровую витрину для просмотра, покупки и управления заказами. Она объединяет различные программные компоненты для упрощения онлайн-транзакций, управления запасами, обработки платежей, логистики и т. д.

Ниже приведены преимущества платформ электронной коммерции:

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

- Удобство: Интернет-магазины предоставляют покупателям удобный способ просмотра и приобретения товаров в любое время.

- Масштабируемость: масштабируемая система электронной коммерции может обрабатывать большой объем транзакций для удовлетворения растущего спроса.

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

- Рекомендации: системы электронной коммерции позволяют давать персонализированные рекомендации, улучшая процесс покупок.

- Автоматизация: автоматизированные процессы оптимизируют управление заказами, отслеживание запасов, доставку и возвраты.

Требования и цели системы

Функциональные требования (FR)

- Авторизация

- Поиск

- добавить в корзину

- Заказ/Покупка (Оплата)

- Уведомление (Этап заказа)

- Обслуживание пользователей

- Управление запасами

- История заказов

- Расширенная цель: система рекомендаций

Нефункциональные требования (NFR)

- Доступность (для платформы)

- Последовательность (для инвентаря)

- Надежность (для данных)

- Расширенные цели: мониторинг, наблюдаемость

Вне сферы действия

- Система доставки

- Проектирование API

- Модели данных

- Доставка, возврат, поддержка клиентов и другая логистика после покупки

Соображения по дизайну

- В целом система будет интенсивно читать, поскольку люди больше просматривают, чем покупают, поэтому поиск и рекомендации должны иметь низкую задержку.

- Данные должны быть на 100% надежными. Если пользователь создает учетную запись или продавец создает листинг продукта, система гарантирует, что они никогда не будут потеряны.

- Продавцы могут создавать столько листингов, а клиенты могут заказывать столько товаров, сколько хотят. Система должна поддерживать эффективное управление данными.

- Такие задачи, как уведомления, могут иметь большую задержку, но должны быть надежными.

- Хранилище заказов будет разделено на две части: горячее хранилище (< 1 года. Используйте AWS RDS) и холодное хранилище (> 1 года. Используйте AWS S3 с Athena)

Back-of-the-Envelope Calculations

Ежедневно активные пользователи (DAU)

Платформа обслуживает около 10 млн DAU. Предположим, что 10% активны в пиковые часы.

Поисковые запросы

- Предположим, 1-2 поиска за сеанс. Если 10% DAU активны, это 1 млн поисков/час.

- Каждый поисковый запрос может возвращать несколько элементов, что требует поиска с малой задержкой и высокой пропускной способностью при чтении.

Пункт обслуживания

При наличии более 10 млн товаров каждый пользователь может просматривать 5–10 товаров за сеанс, что приводит к 50–100 млн TPD для сервиса товаров.

Корзина и оформление заказа

- Если 1% поисковых запросов приводит к действию «Добавить в корзину», это 0,1 млн TPD корзины.

- Предположим, что 10–20% из них превращаются в покупки, то есть 0,01–0,02 млн заказов в день.

Рекомендации

Каждый поиск запускает запрос на рекомендательную службу, поэтому служба должна обрабатывать 1 млн рекомендаций в час.

Управление запасами

Служба инвентаризации должна поддерживать информацию о запасах в режиме реального времени. При условии частого обновления продуктов это 10 млн TPD.

Хранение данных

- База данных пользователей: для хранения 10 млн пользователей, где каждый пользователь использует ~1 КБ пространства, и учета избыточности потребуется около 100 ГБ.

- БД товаров: для 10 млн товаров, для хранения сведений о товаре, каждый товар может занять около ~1 КБ, что составляет 100 ГБ. Хранение изображений и видео будет дополнительным, что можно сделать в файловой системе хранения вместе с CDN.

- База данных заказов: если предположить, что за все время один пользователь сделает 1000 заказов, то хранилище заказов может занять около 100 ТБ.

Задержка и пропускная способность

Сервисы должны поддерживать низкую задержку (<100 мс) при высокой пропускной способности, гарантируя масштабируемость и быстроту реагирования на всей платформе.

Высокоуровневый дизайн

Используйте FR и NFR в качестве ориентира для построения этой системы.

Создайте микросервис для каждой функции. Это не жесткое правило, но в целом оно соблюдается. Используйте здравый смысл.

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

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

В соответствии с оценкой объема данных, сделанной выше, можно выбрать следующие технологии:

Хранилище

- Кластер OpenSearch для функциональности поиска

- S3 с Athena для холодного хранения заказов

- СУРБД для всего остального

Инфраструктура очередей: Кафка

- Для использования в задачах, требующих отказоустойчивости и не требующих малого времени выполнения (TAT)

- Примеры задач: уведомления о статусе заказа (заказан, отправлен, доставлен и т. д.)

Распределенная инфраструктура кэширования

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

- - Почему не централизованный ? Централизованный кэш ограничит масштабируемость и может стать узким местом при высокой нагрузке на чтение, что скажется на производительности системы.

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

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

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

- - Почему не централизованно ? Несогласованные данные инвентаризации в централизованном кэше могут привести к расхождениям данных, особенно в часы пик или при высоких нагрузках.

Централизованный кэш:Memcached

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

- - Почему не распределенный ? Распределенный кэш — это излишество для относительно стабильных данных с низкой частотой доступа. Централизованный кэш обеспечивает простоту с меньшими накладными расходами и проблемами синхронизации.

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

- - Почему не распределено ? Нет существенной необходимости в масштабировании данных корзины по нескольким узлам, а централизованное кэширование обеспечивает простоту и быстрый доступ без дополнительного управления.

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

- - Почему не распределенный ? Распределенное кэширование может привести к проблемам синхронизации для управления сеансами и истечения срока действия токенов на нескольких узлах, что усложнит согласованность. Централизованный кэш позволяет избежать этих проблем.

Race Condition

Что происходит, когда несколько клиентов пытаются купить один и тот же товар одновременно? Один и тот же товар не может быть продан нескольким людям, если запасы ограничены. Так в чем же решение?

Есть несколько способов справиться с этой проблемой:

Блокировка БД

Система (Items Management Service) блокирует записи инвентаря, когда клиент начинает транзакцию, чтобы другие не могли получить к ней доступ до завершения процесса. Это происходит автоматически в СУРБД с использованием блокировки на уровне строк, когда происходит транзакция.

Это не очень хороший метод с точки зрения бизнеса, поскольку может быть доступно больше товаров, чем запросил блокирующий пользователь, и поэтому другие пользователи, ожидающие снятия блокировки, создают плохой пользовательский опыт. Amazon обнаружила, что каждые 100 мс задержки обходятся им в 1% продаж [ источник ].

Оптимистичный контроль параллелизма

Система проверяет наличие инвентаря непосредственно перед подтверждением покупки. Хотя OCC минимизирует накладные расходы на блокировку , он не является надежным. Он работает на основе предположения, что большинство транзакций БД не конфликтуют, позволяя нескольким транзакциям продолжаться без блокировки. Однако OCC может давать сбой в сценариях с высоким уровнем конкуренции, когда многие транзакции обновляют одни и те же данные одновременно. В таких случаях могут возникать конфликты, приводящие к неудачным транзакциям, которые необходимо повторить.

Механизм очередей

Обеспечивает модель FCFS (первым пришел — первым обслужен) и отказоустойчивость, но слишком медленная для платформы электронной коммерции с большим объемом транзакций.

Резервирование запасов

Временно зарезервировать товары для клиентов, чтобы они могли завершить покупки в течение определенного временного окна. Как это будет работать:

- Создайте таблицу «Бронирования товаров» (IR), в которой будут столбцы «Количество», «Зарезервировано до», «Статус» (истек срок действия, зарезервировано, куплено) и другие.

- Перед покупкой проверьте, есть ли на складе запрашиваемое количество. Если на складе достаточно товара, зарезервируйте его, вставив запись в таблицу IR; в противном случае откажитесь от покупки.

- После резервирования обновите остатки в таблице товаров, уменьшив количество товаров.

- Чтобы удалить/истечь резервирование, настройте запланированное задание (например, с помощью задания cron) для периодической проверки истекших резервирований и освобождения запасов (путем увеличения количества товаров).

Схема проектирования системы высокого уровня

Проектирование компонентов

1. API-шлюз и балансировщик нагрузки

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

Балансировщик нагрузки распределяет трафик по узлам, обеспечивая высокую доступность, надежность и производительность, не допуская перегрева одного узла. AWS API Gateway — хороший выбор для этого.

2. Поисковая служба

Позволяет пользователям искать продукты, запрашивая поисковый кластер, а также функции поиска, такие как текстовые запросы, фильтры и ранжирование результатов на основе релевантности. Он также обеспечивает быстрое извлечение результатов поиска, индексируя каталог продуктов, хранящийся в Item Service и Details DB. Этот сервис должен поддерживать выдачу результатов, даже если пользователь делает ошибку при вводе, что может быть достигнуто с помощью Fuzzy Search. AWS OpenSearch Service является хорошим выбором для этого.

3. Страница с подробностями обслуживания

Выбор продукта пользователем из результатов поиска вызовет вызов Detail Page Service, который извлекает данные о продукте из Details DB, такие как спецификации продукта, цена, отзывы и доступность, гарантируя, что пользователь может просмотреть всю необходимую информацию для принятия решения о покупке.

4. Служба определения местоположения

Управляет географическими аспектами платформы. Отслеживает местоположение пользователей (в соответствии с разрешением пользователя и местными правилами) для персонализации вариантов доставки, расчета времени доставки и показа рекламных акций. Хранит данные о местоположении в базе данных местоположения и интегрируется с Search Service и Purchase Service для географически адаптированного опыта. Хранение данных должно соответствовать требованиям соответствия и нормативным требованиям.

5. Служба аутентификации

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

6. Обслуживание пользователей

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

7. Обслуживание корзины

Позволяет пользователям добавлять, обновлять и удалять товары из своих корзин, сохраняя эти данные в базе данных корзины. Он обеспечивает пользователям возможность плавного перехода между сеансами без потери информации о корзине и вызывает службу покупки во время оформления заказа.

8. Закупка услуг

Обрабатывает заказы, интегрируясь с Payment Gateway для безопасных транзакций. Он обрабатывает процесс оформления заказа и рассчитывает общую стоимость, включая налоги и доставку. После успешной оплаты он передает данные заказа в Order Service для дальнейшей обработки.

9. Обслуживание товара

Управляет каталогом продуктов и хранит сведения о продуктах, их наличие и метаданные в базе данных товаров. Эта служба интегрируется с Search Service для предоставления индексированных данных для поисковых запросов и с Inventory Service для обеспечения обновлений запасов в режиме реального времени.

10. Служба инвентаризации

Управляет доступностью продукции на различных складах. Отслеживает уровень запасов и обновляет систему, когда товары продаются или пополняются. Служба обеспечивает точный подсчет запасов и интегрируется с Item Service для отображения доступности продукции пользователям в режиме реального времени.

11. Служба управления товарами

Осуществляет управление списками продуктов, позволяя продавцам или работникам склада добавлять, обновлять или удалять продукты из каталога. Интегрируется с Inventory Service для управления уровнями запасов и Item Service для обновления метаданных продуктов.

12. Заказать услугу

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

13. Служба статуса заказа

Предоставляет обновления в режиме реального времени о статусе заказов пользователей. Интегрируется с Order Service и отслеживает заказы по мере их прохождения через различные этапы, от обработки до доставки. Эта информация хранится в Status DB, которая информирует пользователей через Notification Service.

14. Миграционная служба

Отвечает за миграцию заказов старше года (настраивается) в базу данных холодного хранения. Это делается для того, чтобы база данных горячего хранения была небольшой и быстрой. Поскольку старые заказы редко используются пользователями, это решение работает хорошо. AWS S3 с Athena — хороший выбор для этого.

15. Служба уведомлений

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

Это делается для того, чтобы уведомления оставались отказоустойчивыми, и поскольку они не критичны ко времени, это решение работает хорошо. Если есть более критичные уведомления, то им придется использовать систему уведомлений в реальном времени, такую как Web Sockets, Push Notifications, SSE (события, отправленные сервером) и т. д.

16. Рекомендательная служба

Предоставляет пользователям персонализированные предложения продуктов, используя данные пользователей из User Service и историю заказов из Order Service. Анализируя поведение и предпочтения пользователей, эта услуга повышает вовлеченность пользователей, предлагая соответствующие продукты.

17. Кластер ES (Elasticsearch)

Обеспечивает возможности поиска путем индексации данных из Item Service и Details DB. Он хранит данные в формате, оптимизированном для быстрого извлечения, и поддерживает функциональность полнотекстового поиска платформы. Он также поддерживает Fuzzy Search, чтобы запросы с ошибками ввода также давали правильные результаты. AWS Open Search — хороший выбор для этого.

18. Платежный шлюз

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

19. Инфраструктура очередей (Кафка)

Облегчает асинхронную связь между службами. Гарантирует, что обновления, такие как изменения запасов или статус заказа, эффективно распространяются по различным компонентам системы, не требуя прямого соединения между службами. Также облегчает некритичные по времени операции, такие как уведомления.

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

Готовое решение масштабируемой платформы электронной коммерции на базе DST Platform

Для компаний, стремящихся к быстрому развертыванию и масштабированию онлайн-торговли без значительных затрат на кастомную разработку, DST Platform предлагает готовое решение — DST Маркетплейс (лицензия Enterprise). Это комплексная система, объединяющая все ключевые компоненты современной электронной коммерции: от управления товарами и заказами до интеграции с платежными системами и аналитики.

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

DST Маркетплейс поддерживает мультивендорную модель, что делает его идеальным решением для маркетплейсов, где важно координировать работу сотен поставщиков. Гибкие настройки комиссий, рейтингов продавцов и модерации товаров помогают поддерживать качество платформы.

Для корпоративных клиентов лицензия Enterprise включает **расширенную техническую поддержку расширенную техническую поддержку, SLA с гарантией uptime 99.9%, а также возможность глубокой кастомизации под специфические бизнес-процессы. Это позволяет интегрировать платформу с внутренними ERP- и CRM-системами без потери производительности.

Таким образом, DST Маркетплейс сокращает время выхода на рынок и минимизирует риски, связанные с разработкой «с нуля», предлагая при этом функционал уровня крупнейших игроков рынка.