Привет, мы команда СберМегаМаркета, и это обзорная статья о нашей площадке, пробный камень для блога Хабре. За нашими плечами спешный переезд с PHP на GO, ребрендинг и решение таких задач, с которыми большинство разработчиков не сталкивается. Например, мы сделали высоконагруженную платформу для управления заказами на 1С. А вам слабо?
Мы пришли поделиться опытом, и для начала расскажем, как превратились из локального маркетплейса в высоконагруженный e-commerce сервис, и что интересного входит в IT-инфраструктуру современного маркетплейса.
Все началось в 2016 году с goods.ru в маленьком уютном офисе с неработающим кулером. Мы предоставляли витрину, брали на себя общение с покупателями, доставку заказов и маркетинг, а продавцы платили комиссию с каждого выполненного заказа — это был классический маркетплейс.
В 2018 году произошел полноценный запуск: на нашей площадке продавали 13 товарных категорий — от продуктов и книг до бытовой химии и автотоваров. К 2019 году мы предлагали более 1 миллиона товаров. Ассортимент доступных покупателям уникальных товаров сейчас превышает 4,5 миллиона, мы доставляем заказы более чем в тысячу городов России, занимаем отдельный этаж бизнес-центра, а в рейтинге интернет-магазинов E-commerce Index Top-100 по итогам 2021 года занимаем 21 место.
С чего все начиналось. Разработка: от Bitrix до Golang
В 2017 команда разработки goods.ru состояла из 10 человек, включая СТО. Первая версия продукта была написана на Bitrix. Он позволил быстро продемонстрировать идею и получить финансирование.
Бета-версия нашего сайта, какой ее видели первые покупатели
Особых перспектив у Bitrix не было, так что вскоре мы переехали на PHP. Дело было 5 лет назад — тогда мало кто использовал Go, а микросервисы были в новинку.
Построить монолит на PHP и отказаться от него
Тогда нам было бы нечего рассказать на Хабре. В первой версии площадки было не так уж много разработки и технологий. В ее основе лежали довольно простые вещи: PHP, MySQL, логирование в файлах. Ничего сложного и не нужно было. Поначалу нагрузки оставались невысокими: в 2017–2018 годах у goods.ru было от 100 до 500 заказов в день, в пиковые периоды — до 1 тыс. в день, и то нечасто. По RPS нагрузка не превышала 300. Для сравнения — сейчас это примерно до 10 тыс. RPS.
Goods.ru обходился без пунктов вывоза заказов и доставлял товары только по Москве. Количество наименований уникальных товаров не превышало 500 тысяч, но к 2019 году мы выросли настолько, что наш монолит уже не вывозил: появились проблемы с поддержкой, релизом, деплоем. Цикл задачи затянулся — регулярно появлялись трудности с тестированием.
Платформа работала медленно: росло время ответа, периодически все зависало, регулярно происходили ошибки на этапе оформления корзины. Мы правили в одном месте — ломалось в другом. Когда стартовала разработка мобильного приложения, оказалось, что у нас нет готовых API для его подключения. Это стало последней соломинкой, давно пора было все переделать.
Мы все еще придерживались привычного дизайна, но со временем сайт стал гораздо сложнее и оброс различными пользовательскими путями, с которыми мы разбираемся до сих пор
Решили переходить на микросервисную архитектуру и Golang — это наш основной язык разработки и по сей день.
Мы переучивались на Go прямо в процессе переезда, и в то же время старались сделать процесс постепенным и плавным. Продумали архитектуру и распределили всю имеющуюся функциональность по микросервисам, затем начали выводить отдельные микросервисы на прод. Первым делом пересадили мобильное приложение, затем перенесли наиболее важные компоненты, вроде корзины с чекаутом и каталога товаров.
Трудности уже подзабылись, но отдельные моменты останутся в памяти еще надолго. UI в мобильном приложении и в вебе выглядел сильно по-разному, и набор данных из двух этих витрин отличался. Состыковать их было жуткой головной болью. Затем мы проделали это с листингом и в последнюю очередь запустили микросервисы, отвечающие за личные кабинеты и списки заказов.
Честно говоря, времени на перенос было немного, а поток бизнесовых задач не прекращался. В какой-то период мы поддерживали одновременно если не два, то полтора маркетплейса: старый и часть нового. А как только мы наладили микросервисы, освоились и вздохнули с облегчением — начались ребрендинг и интеграция в экосистему Сбера… но это уже отдельная история. Расскажем как-нибудь в другой раз.
Пять лет спустя: к какой архитектуре мы пришли и какая архитектура у нас сейчас
Сейчас у нас полностью микросервисная архитектура. В стек входят Kubernetes, Kafka, RabbitMQ, Elasticsearch, PostgreSQL, Tarantool. Каталог товаров работает на Elasticsearch. Kafka помогает следить за апдейтами. Корзина, избранное, списки недавно просмотренных товаров — все горячие данные, которые часто обновляются, хранятся в Tarantool.
«Все закруглить!» — первая задача, которая стояла перед нами во время редизайна
В целом мы поддерживаем около 150 микросервисов — несколько десятков на одну вертикаль:
система каталога;
отдельный движок для системы полнотекстового поиска;
корзина;
алгоритмы подбора товаров;
чекаут;
сервисы личного кабинета;
бонусная карта;
адреса;
профили;
Сбер ID;
обращения покупателя;
заявки;
чаты;
и так далее.
Это только то, что видит покупатель, а ведь под капотом целый набор других систем. За ними кроется немало занятных технических решений. Взять, например, OMS.
Архитектура крупным планом
Нет, это не про страхование. Order Management System (система управления заказами) — одна из самых нагруженных систем СберМегаМаркета. У нее трехзвенная архитектура: СУБД + клиент + сервер и множество RESTful-интеграций с другими сервисами.
OMS принимает заказ от клиента, а затем взаимодействует с продавцом, сортировочным центром, контакт-центром. Еще она информирует покупателя о заказе, контактирует с операторами, которые отвечают за доставку покупки от сортировочного центра до клиента, и взаимодействует с банком через эквайринг. И это идет речь только о традиционной схеме доставки - когда мы с помощью логистических партнеров доставляем заказы до клиентов. В СберМегаМаркете есть и другие схемы работы: когда продавец самостоятельно доставляет заказы покупателю, или когда покупатель бронирует заказ на маркетплейсе, а забирает самовывозом из конкретного магазина. Таким образом, в момент времени OMS обрабатывает примерно 75 тыс. заказов. И вот эту высоконагруженную систему мы собрали на платформе 1С.
Как (и зачем) мы построили высоконагруженную систему на 1С Суперспособности 1C
Твое лицо, когда рассказали про OMS на 1С
Причина такого выбора проста: мы не только кодим, но и дизайним процесс обработки заказа, а 1С дает нужный для этого UI прямо «из коробки». Если описывать движение заказа кодом, понадобятся громоздкие условные переходы. 1С визуализирует карту процесса обработки, и тем самым сильно облегчает жизнь.
Мы использовали нетипичные решения: например, DevOps и CI/CD, автоматизированный деплой и в целом автоматизацию рутинных операций, EFK (Elasticsearch + Fluentd + Kibana), Grafana для визуализации, а историю версий храним на GitHub.
Да, у 1С слабые места, например, синхронные вызовы. Они выполняются медленнее, чем в высокоуровневых языках. Чтобы ускорить выполнение синхронных вызовов в 1C, мы даже создали отдельный сервис на Go. Мы даем ему команду выполнить действие, а он возвращает ответ в асинхронном режиме. Операция занимает несколько секунд вместо миллисекунд, но мы можем на это пойти, чтобы потратить это время на другие задачи внутри процессинга.
Еще мы научили 1С масштабироваться. Постепенно расширили стек и используем вместе с RabbitMQ брокер очередей Apache Kafka — писали дополнительные инструменты, чтобы их подружить.
Что мы меняем. Над чем мы сейчас работаем в OMS
В целом нас до сих пор все устраивает, но примерно каждые полгода происходит то, что можно назвать вызовом. Чаще всего происходит одно из двух:
Случается нечто, что дает нагрузку на сервисы, и мы срочно должны придумать, как обеспечить бесперебойную работу системы. В последний раз это был COVID, но сложности могут возникнуть и при единовременном начислении большого количества бонусов от СберСпасибо сотрудникам (в честь дня рождения Сбера, например), которые тут же пошли использовать их в СберМегаМаркете. Сюда же относятся и такие крупные акционные распродажи, как Черная пятница или Зеленый день от Сбера.
Проблемы внутри самой 1С, по сути, закрытой платформы, в которой время от времени возникают какие-то сбои. Порой они осложняют нам жизнь, и мы вместе с представителями 1С работаем, чтобы их устранить.
Кстати, есть у нас и свое «детище» — робот, который выполняет процессинг всех заказов, отвечает за распараллеливание и оптимизирует работу каждого потока. Со времен goods.ru он пережил несколько «операций» — и теперь вместо 1 тысячи обрабатывает более 100 тысяч заказов. Сейчас его мультитайлинговая модель гораздо умнее предыдущей: мы научили робота запускать процессы и потоки, не дожидаясь завершения каких-то параллельных, начавшихся раньше.
Под капотом у маркетплейса — какие еще системы мы разрабатываем и поддерживаем, и для чего они нужны
Система управления заказами — это еще далеко не все, ведь современный маркетплейс — уже давно не просто магазин. Можно сказать, что отчасти мы агрегатор предложений, отчасти логистическая компания, параллельно статистическое бюро и рекламная площадка, а на полставки еще и банк.
Наполненность маркетплейса растет и усложняется. Каталог сейчас включает более 4,5 млн уникальных товаров - не путать с SKU, так как особенность нашего маркетплейса в том, что аналогичные товары объединяются в единую карточку товара, а уже в рамках этой карточки покупатель видит всех продавцов с различными предложениями по стоимости и географией получения. Конечно, мы не планируем останавливаться на достигнутом, что означает постоянно растущие нагрузки и увеличение времени на обновление.
Для маркетплейса критически важно, чтобы актуальные товары вовремя появлялись, а неактуальные не транслировались: появление рассинхрона между тем, что завел продавец, и тем, как это выглядит на витрине, — приводит к ошибкам в корзине и негативно сказывается на опыте покупателей.
Мы постоянно придумываем способы оптимизации, например, тестируем базы данных с различной структурой и ищем оптимальные решения для определенных типов данных.
А еще все эти товары необходимо доставить покупателю. Нам помогают разные логистические компании, и это тоже большой объем бизнес-логики, сервисов и неочевидных решений. Например, нужны механизмы для быстрого переключения между поставщиками на тот случай, если кто-то из них окажется перегружен и перестанет принимать заказы.
Еще один интересный аспект работы маркетплейса — скидки. Как правило, аналогичные площадки предлагают только одну или две механики скидок. Мы стараемся расширить этот перечень и развиваем собственную платформу лояльности с поддержкой кешбэка, бонусных рублей, акций, промокодов. В платформу закладывается сложная внутренняя логика с большим массой переменных. Информации на целую статью (скоро опубликуем и все подробно расскажем).
С платформой лояльности соседствуют подсистемы, отвечающие за начисление бонусных баллов. То, как они работают, сильно напоминает банковские проводки. Да и фактически баллы — это эквивалент денег, так что нам приходится уделять много внимания информационной безопасности.
Другая группа задач — повышение релевантности поиска. Персонализация на основе данных о пользователе, его предпочтениях, поведению на площадке — здесь есть где развернуться.
Вообще, совершенствование CJM — взаимодействия покупателя с маркетплейсом, это то, чем мы занимаемся непрерывно. Изначально мы «догоняли» конкурентов и больше думали не об удобстве пользователя, а о том, что нам нужны похожие фичи. Из-за этого образовалось множество пользовательских путей и бывает трудно разобраться, как работать с площадкой. Сейчас мы проводим UI-исследования и работаем над упрощением этого процесса с учетом наших собственных приоритетов и особенностей.
Зачем мы экспериментируем — новые плюшки и модели продаж. Наши планы
Развитие и поддержание всего этого в рабочем состоянии отнимает немало сил, но нестандартные технические решения позволяют реализовать новые модели продаж и оптимизировать старые.
Существует три основных модели продаж:
1P: маркетплейс закупает товар самостоятельно и хранит на своем складе;
2P: товар находится на складе маркетплейса, но не отражается на балансе;
ЗP: когда площадка не является ни владельцем, ни балансодержателем стока. Исполнение товара идет со склада продавца или прямо из магазина.
Мы активно развиваем сотрудничество с продавцами и партнерами по последним двум моделям. Также реализуем схему «Закажи и забери» (Click&Collect или самовывоз из офлайн-магазина при предварительном бронировании через маркетплейс) со всеми ее преимуществами для продажи товаров не только сегмента бытовой техники и электроники, но и FMCG, fashion и др.
Что касается 1P, то сейчас мы учимся приобретать партии товаров самостоятельно. Невозможно одинаково хорошо закупать пылесосы, стиральные порошки и апельсины. Каждая категория имеет много нюансов — здесь как раз пригодятся большие данные, опыт работы с логистикой, статистикой и пользовательскими отзывами.
Мы стремимся искать нестандартные решения для роста и это неизбежно означает, что у нашей команды будет много сложной работы, а у вас — читателей Хабра — много полезных постов.
