Делаем суровые DIY для требовательных мастеров.
Тяжелая, потому что речь идет о шестиметровой доске естественной влажности, железобетонных кольцах, трехметровом гипсокартоне и сыпучих поддонах.
И требовательны, потому что малейшие изменения в UI и UX приводят к тому, что «Что запустилось, то нормально общались».
Интернет-магазин строительных материалов – это когда в каталоге указаны названия товаров от 20 до 140 символов – и в них важно все.
Когда есть 4,8 млн записей подключений сопутствующих товаров, когда цена указана за метр, то он продается пакетами и покупать можно не только целыми.
Когда порой покупатели не знают, что им нужно и как это называется: нейминг в таких изделиях – это богатая тема, достойная отдельной статьи, это вам не трусы: стринги, танго, добрая классика «75+».
Когда товар тонируют, распиливают и поднимают на грузовом лифте, а если его нет, то пешком.
И нам необходимо точно знать, сколько стоит поднять 1 лист гипсокартона пешком на 25 этаж в уездном городе N по конкретному адресу.
При доставке всего 2 часа и перерасчете наличия товара на продажу и логистическом рычаге от ХАБа для сборки заказа, а также способа оплаты необходимо учитывать сотни параметров.
Мы знаем, где в данный момент находится каждый товар: город, подразделение, склад, местоположение и ячейка хранения.
Мы знаем его каналы снабжения и графики движения с точностью до минуты.
На момент оформления заказа мы знаем, откуда его доставим.
Чтобы успеть даже в тот момент, когда оплата проходит долгий путь от «одного касания пользователя» до облачной кассы и ОФД, у нас уже работает машина времени, которая распределяет заказы между рейсами, водителями, автомобилями.
и строит маршруты.
И на рабочем месте сборщика появляется заказ на сборку.
И если что-то в этой цепочке изменилось, хотя бы один параметр, то это надо учесть, пересчитать и отобразить пользователю — всё должно быть настолько реактивно, насколько это сейчас модно.
Как это все началось
Мы поняли, что в нашем проекте 23 разных крестика для модальных окон, каждый экран — это новая кнопка и новый CSS. Если в корзину вносятся изменения, каталог ломается.Мы добавили новую подсказку в листинг - шаблоны страниц товаров были нерабочими.
На складе в Балашихе изменено место хранения категории - сайт должен это видеть, чтобы показывать информацию о наличии и наличии товара.
Только сайт вместе с клеткой получил название, описание, сопроводительные и аналоги, фотогалерею и видео с бородатым мужчиной, садящимся на парашюты, а после роликов пришел админ с вопросом: «Как долго ты будешь насиловатьЭ» сервер, когда вы его переписываетеЭ» 
Тогда мы решили, что пора все переделать.
Монолитность, ненадежность, избыточность, админы опять же игнорирование всего этого - плохая примета.
Как разложишь, так и понесешь в производство.
Мы начали с плана, разделив блоки на передний и задний, оценивая период по принципу трех П.
При этом разработку планировалось вести параллельно.
Вот что мы сделали:
- Мы собрали функциональные требования от разных отделов (посещали маркетинга, SEO, закупок, контент-специалистов, контакт-центра, коммерции и т. д.).
- Проведены исследования и выбраны технологии.
- Разработаны системы обмена данными.
- Мы спроектировали базу данных для хранения накопленной информации.
- Написал протокол взаимодействия с клиентом (API).
- Мы создали и согласовали контракты на работу с API, сгенерировали моки.
- Мы создали дизайн-систему.
- Выполнил прототипирование интерфейса.
- Создан дизайн интерфейса.
- Мы построили бэкэнд и фронтенд архитектуру.
- Мы завершили внедрение, которое включало в себя:
- Осуществление обмена данными (основная информация о товаре: цены, остатки, свойства, аксессуары, комплекты и т.д.) в том формате, в котором они хранятся в учетной системе.
- Реализация агрегации промежуточных данных.
Например, расчет цен из временного реестра, агрегирование остатков по складам, определение активности товара и т. д.
- Сбор всех необходимых данных с учетом нового дизайна.
- Реализация серверной части приложения.
- Реализация бэкэнд-сервисов.
- Расположение шаблонов.
- Реализация клиентской части приложения.
- Осуществление обмена данными (основная информация о товаре: цены, остатки, свойства, аксессуары, комплекты и т.д.) в том формате, в котором они хранятся в учетной системе.
- Подготовили тестовую среду.
- Мы подготовили производственную среду.
- Завершена интеграция (переход с моков на API).
- Провели тестирование на сцене.
- Устранили дефекты и подготовили запуск к производству.
- Запущен.
Чтобы дрэг был хорошим, его нужно выдержать
У нас есть много требований к каталогу на долгие годы, поэтому мы выбрали только те, которые можно отнести к базовой функциональности.Задача была такая: переписать, заложить основы, а не пытаться удовлетворить всех сразу.
Но все договоренности, планы и согласования оказались для сельской паствы ерундой.
Все равно документация оказалась сырой, конструкция и решения менялись на лету.
После демо появились новые требования, а улучшения в макетах, обмене данными, структурах данных и API не были редкостью.
Развитие заднего вида
Источником данных о товарах, наименованиях, складских остатках, акциях и т.д. является наша учетная система.Интеграция с ним изначально была реализована через мыльный сервис, а в конструкции заложена избыточность, что повлекло за собой накладные расходы при изменении части объекта.
Весь код для обмена и работы с данными находился в одном репозитории.
Проект развивался, приобретал как новый функционал, так и избыточность.
И каждая новая функция в каталоге добавляла время на получение и агрегацию данных.
Накопленное наследие сделало управление и совершенствование обмена данными трудоемкой задачей.
Со временем мы перешли от чтения в реальном времени к агрегации и хранению информации в специальных таблицах, чтобы ускорить чтение, а также добавили горячее кэширование.
Проанализировав накопившееся, мы решили существенно изменить существующее решение, чтобы обеспечить высокую скорость обмена информацией, сократить время на доработку и добавление новых бирж, а также увеличить скорость ответа API. В общем, переходить к сервисной архитектуре с монолитной.
Мы начали с обмена.
Необходимо было выбрать брокера очереди.
Проведя исследование среди популярных брокеров ActiveMQ, RabbitMQ, Apache Kafka и других, мы остановились на ActiveMQ (так как он уже был в стеке) и Kafka (как потенциально перспективный для компании).
При рассмотрении инструментов мы ориентировались на масштабирование и гарантию получения сообщений; по результатам экспериментов мы выбрали Кафку.
Естественно, с клиентом пришлось немного поработать, так как по идеологии Кафки именно клиент должен быть «умным» и уметь правильно обрабатывать сообщения.
После того, как решение созрело и мы научились с ним работать, была выбрана задача, над которой мы могли сделать первый шаг в будущее.
Этой задачей был обмен статическими файлами (изображениями, сертификатами, видео) из хранилища учетной системы и выгрузка их в облако.
Тогда на сайте изменение размера изображения происходило в реальном времени, что отражалось на скорости загрузки страниц.
В новых биржах мы решили эту проблему: теперь конвертация изображений и видео во все нужные нам форматы и размеры происходит заранее.
Как мы уже говорили, когда мы начали работать с каталогом, текущая версия была реализована в одном приложении, что представляло определенную сложность, так как не было возможности обновить часть приложения.
За годы разработки проект накопил достаточное количество наследия, поэтому изменения в одной части приложения приводили к неожиданным ошибкам в другой.
Это означало, что тестирование, включая регрессию, нужно было проводить, даже если запятую убрать.
В результате мы разделили все API на независимые сервисы.
Для описания документации и представления стандарта за основу мы взяли спецификацию OpenAPI 3 и правила версионирования SemVer. Мы описали наш список правил и в первую очередь разработали контракт данных.
Договорились «на берегу».
Для обработки сообщений из очереди Kafka мы использовали демон PHP. Для хранения промежуточных данных с биржи был создан отдельный экземпляр базы данных.
Полученные данные являются сырыми и требуют постобработки; это решение позволяет разделить нагрузку.
Новый формат обмена оказался успешным в нашей работе, поэтому мы продолжили его развивать и масштабировать на весь каталог.
При выборе хранилища базы данных мы решали задачу: сделать так, чтобы API отвечал в течение 50 — 100 мс.
Также в разработке мы планировали использовать SSR на Node, что также накладывало требования к скорости ответа API и отказоустойчивости.
Для организации хранения данных каталога в качестве основной базы данных мы выбрали Redis, так как за время работы нами накоплен достаточный опыт ее использования и она хорошо организована в кластер.
Мы настроили Redis Persistence с записью на одну главную и две географически разделенные реплики только для чтения.
Обмены записываются на мастер, а для чтения в API-сервисах используются реплики.
Для репликации использовался вариант AOF, поскольку он более надежный.
Кроме того, мы изучили формат хранения данных и метод сериализации/десериализации данных PHP. По результатам исследования расширение igbinary показало лучшие результаты, чем json, php сериализатор или msgpack. Для фильтрации и сортировки данных в каталоге мы выбрали elasticsearch, так как этот инструмент уже был у нас в стеке и мы остались довольны его производительностью.
При внедрении в продакшен API-сервисы были развернуты на существующей инфраструктуре, но для SSR были подготовлены отдельные серверы с слоем кеширования на Varnish.
Per aspera ad astra
На этапе тестирования каталога мы столкнулись с трудностями; мы периодически получали большие задержки ответов API и долго не могли найти закономерность.К этому моменту мы уже интегрировали новые API для внутренних запросов в сервисах корзин, все виды калькуляторов, смет и уже имели немалую нагрузку.
Чтобы найти проблему, мы использовали профилировщик, проводили отладку, нагрузочные тесты, читали системные логи, но при этом получали необъяснимые зависания в разных местах кода.
В результате, проводя эксперименты с нагрузочными тестами, мы заметили, что пики нагрузки совпадают с запусками агрегации данных и записи их в redis. Причина была в том, что для оптимизации работы по записи в redis мы использовали пакетную загрузку, но пакеты были довольно большими и запрос на запись одного пакета к мастеру мог занять много времени.
Но с учетом репликации AOF, хранящей журнал запросов, все эти запросы выполняются на слейве.
А поскольку redis однопоточный, запросы на получение данных из API сервиса в это время простаивали в очереди.
После уменьшения количества объектов в пакетах записи такие пики практически перестали воспроизводиться.
А поскольку Redis требует большого количества ресурсов ЦП, эти ЦП были назначены виртуальным серверам, обслуживающим кластер Redis.
Фронтмен должен быть красивым! Это для начала
За годы работы в передней части приложения накопилось наследие: скелеты в шкафу, костыли, скелеты на костылях, палки.Поэтому фронт принял волевое решение, что ему все же нужен свой велосипед. и начал нарезать собственную дизайн-систему.
Мы 11-е место в рейтинге среди e-com, у нас много амбиций, мы хотим, как и все, вести себя как взрослые.
Без собственной дизайн-системы вы не сможете продавать нам галоши, обои и полы с подогревом.
И снова 23 крестика для модалов, как тут без стандартизации дизайна, простоты редактирования, сокращения сроков вывода на рынок - это всё модные словечки.
Дизайн-система начиналась с малого.
UI-кит родился без документации, молодой и полезный, как микрозелень, это, конечно, усложняло работу над каталогом.
Но мы считаем, что заложили основу, что дьявол кроется в деталях, и наш Набор рассказывает и показывает, как сделать хорошие цифровые изделия в стиле DIY для всех: и для крутых строителей, и для девочек с собаками.
На переднем плане у нас есть устоявшийся стек технологий: React, RxJS, Webpack, SCSS, Typescript. Но помимо дизайн-системы мы поставили перед собой еще одну задачу: сделать SSR (Server Side Rendering) клиентского кода на Node JS. До этого мы использовали smarty. Таким образом, мы смогли применить один и тот же код как на клиенте, так и на сервере.
Еще об амбициях: CustDev прямо сказал: «Нужна автоматическая загрузка товаров на странице, потому что тыкать в кнопки «Показать больше», когда ты в варежках и на сайте — не вариант!» Нужно было решить задачу, при этом сделать удобно и не рисовать 1000 товаров.
В общем, любой, кто когда-либо делал каталог, скажет: «В следующей жизни я буду разработчиком админки».
Потому что он делал SEO, интеграцию с маркетинговыми инструментами.
А когда у тебя есть SPA, но логировать и отправлять события все равно нужно, то здесь, кроме «Всевышний терпел и приказал нам», лучше и не скажешь.
Краткая история «ССР»
При работе над SSR у нас тоже были проблемы с геморроем; у нас были проблемы с утечками памяти.Подобные проблемы обычно не решаются быстро, а поиск утечек занимает довольно много времени.
Но мы справились и для надежности реализовали кластеризацию приложения Node, что позволило нам в случае новых утечек или других проблем с крахом приложения переключить пользователей на другую ноду в кластере и перезапустить вышедшую из строя.
Кроме того, оценка сроков выполнения задачи была большой проблемой.
Мы много учились, экспериментировали, перенимали опыт наших коллег.
Была очень высокая неопределенность.
Многое сразу не получилось, но мы не сдавались и продолжали двигаться вперед.
Мы несем ответственность за установленную нами функцию
Первые 90% проекта не так страшны, как вторые 90%.У нас есть отработанная схема запуска такого рода крупных фич в производство, и каждая крупная фича проходит несколько этапов тестирования и исправления дефектов.
Тестирование можно разделить на три блока: тестирование API, тестирование макета и функциональное тестирование графического интерфейса.
При тестировании API мы проверяем бизнес-логику приложения.
В результате было описано и автоматизировано более 1600 тест-кейсов по тестовой модели.
Если говорить о верстке, то нужно понимать, что тестировать нужно полную и мобильную версии, а также разные браузеры и разрешения.
И последний этап — функциональное тестирование графического интерфейса.
Но перед этим нам необходимо описать и просмотреть все тестовые сценарии (документация и опыт нам в помощь!).
В результате было проведено более 500 тест-кейсов для десктопа и более 400 для мобильных устройств.
Когда мы поняли, что все критические недочеты исправлены, все важные для SEO моменты учтены и четко работают, когда мы получили обратную связь от отдела маркетинга, что все данные отправляются в различные виды маркетинговых инструментов, мы все-таки запустили новый каталог для нескольких групп волонтеров аутсорсингового контакт-центра, которые работают на сайте.
И только получив их благословение, мы начали переключать новый каталог на пользователей.
И лучшим доказательством того, что мы молодцы, стало молчание наших пользователей.
Мы разобрали все до основания и собрали по-другому, но требовательные прорабы этого не заметили.
И кстати, фуга не о фуге Баха, а о замазке Фугена.
А Антонио — третий по популярности запрос.
Конечно, они ищут не Антонио или Рикардо.
Это автокоррекция Ветонит на ИО.
А парашют - это не про прыжки, а про теплоизоляцию, но об этом в следующем рассказе.
Фото парашютов прилагается.
Дюбель для теплоизоляции Bau-Fix 10х100 мм
Теги: #diy #postgresql #php #электронная коммерция #react.js #typescript #petrovich.ru
-
Чемпионат Мира, Порно И Твиттер
19 Oct, 24 -
Библиотека Онлайн
19 Oct, 24 -
Чистая Прибыль Яндекса Выросла На 139%
19 Oct, 24 -
4 Правила Бизнеса Дэвида Яна
19 Oct, 24
