Александр Сараев – Внутренняя разработка WMS

Transcript

1. Ozon Tech 2023 Внутренняя разработка WMS. Особенности разработки системы управления складом Александр Сараев, руководитель направления разработки «WMS»
2. В качестве введения 2 WMS управляет операциями и процессами складов (Warehouse Management System) —
3. В качестве введения 3 Склад Продуктовый каталог Поставщики и селлеры Заказы и логистика Учет Паллета Стеллаж Подбор Груз SKU Размещение Ворота
4. В качестве введения 4
5. Посмотрим, как менялись… 5 Бизнес Архитектура и технические решения Подходы к тестированию
6. Важные шаги в развитии бизнеса 6 Один склад (только штучное хранение) 1
7. Важные шаги в развитии бизнеса 7 Один склад (только штучное хранение) 1 Новый тип хранения (паллеты) 2
8. Важные шаги в развитии бизнеса 8 Один склад (только штучное хранение) 1 Новый тип хранения (паллеты) 2 Много складов 3
9. Важные шаги в развитии бизнеса 9 Один склад (только штучное хранение) 1 Новый тип хранения (паллеты) 2 Много складов 3 Новый тип склада (распределительный центр) 4 РЦ ФФ ФФ ФФ
10. Важные шаги в развитии бизнеса 10 Один склад (только штучное хранение) 1 Новый тип хранения (паллеты) 2 Много складов 3 Новый тип склада (распределительный центр) 4 Склады в других странах (Казахстан, Беларусь) 5
11. Важные шаги в развитии бизнеса 11 Один склад (только штучное хранение) 1 Новый тип хранения (паллеты) 2 Много складов 3 Новый тип склада (распределительный центр) 4 Склады в других странах (Казахстан, Беларусь) 5 Новый тип бизнеса (Ozon Fresh) 6
12. Архитектура 12 business process service X entity service 1 entity service 2 API-gateway N API-gateway 1 storage service M workflow • Много entity- и storage-сервисов • Сервисы бизнес процессов — под рабочие места сотрудников • Зависимости сервисов направленны всегда вниз • Workflow сервис для оркестрации процессов • Логика в API-Gateway
13. Архитектура 13 • Больше сервисов над бизнес процессами, меньше storage/entity • Сервис бизнес процесса — не только автоматизация рабочего места сотрудника • Начали уходить от концепции слоев API-gateway 1 API-gateway N business process service X storage service M business process service Y
14. Архитектура. Что еще 14 • Архивирование БД Operational Archival Shard 1 Shard 2 Shard 3 svc 1 svc 2 Витрина • Шардирование БД • Сервисы витрины и модели чтения
15. Архитектура. Согласованность данных 15 Синхронные вызовы Синхронные вызовы с попыткой отката Библиотека для отката Синхронизация в контрольных точках Custom Saga implementation Saga framework
16. Согласованность данных. Синхронные вызовы User request: - transaction begin
 - http call 1
 - …
 - http call 2
 - db update
 - http call 3
 - transaction commit User request: try {
 - transaction begin
 - http call 1
 - …
 - http call 2
 - db update
 - http call 3
 - transaction commit }
 catch (Exception) {
 - http rollback-call 3 if needed
 - http rollback-call 2 if needed - http rollback-call 1 if needed
 }
 User request: 
 - transaction begin
 - http call 1
 - add rollback-call 1 into ctx
 - …
 - http call 2 - add rollback-call 2 into ctx
 - db update
 - http call 3
 - add rollback-call 3 into ctx
 - transaction commit
 О согласованности не думали Чуть лучше, но не слишком Чуть удобнее, но гарантии такие же
17. Согласованность данных. Синхронизация в контрольных точках 17 Операции объединяются в логические пачки Выбирается точка в процессе, в которой происходит синхронизация всей пачки Сложность из разных мест уходит в одну точку Сложный код синхронизации Cинхронизация с задержкой Синхронизация пачки — тяжелая операция
18. Согласованность данных. Сага • Начали явно моделировать состояние саги • Перешли на Task-based API в некоторых сценариях • Сделали framework для упрощения разработки Id Type (text) Data (jsonb) Created_at Finished_at Failed_reason ‣ Dal model по умолчанию, можно расширять ‣ BLL model, реализованная по принципам богатой модели ‣ Базовая реализация ORM ‣ CRUD generic repository ‣ Интеграционные события создания и завершения саги, можно расширять ‣ Метрики и алерты из коробки
19. Тестирование. Было 19 Unit Integration E2E Manual Ice Cream Cone • Большая часть тестирования выполняется на конечных этапах разработки • Больше всего самых сложных и хрупких тестов • Вовлеченность тестировщиков низкая
20. Тестирование. Стало Юниты Интеграционные BDD сценарии (компонентные) UI E2E • Целиком флоу процесса • Фокус на проверке фронтовой части • Целиком флоу процесса • Фокус на проверке взаимодействия с внешними сервисами • Все основные бизнес-сценарии процесса • Тестируются все слои сервиса, начиная с клиента, на моках внешних сервисов • Интеграция с БД, Redis и пр. • Все методы репозитория, query handlers • По необходимости command handlers • Обязательна вся доменная логика • Любой нетривиальный код (command handlers, providers и т.д.)
21. Тестирование. Стало 21 • Тесты написаны на минимально возможном уровне • Тесты более высоких уровней должны фокусироваться на частях, которые не могут быть проверены на более низком уровне • Если на уровне выше была найдена ошибка, которую должен был обнаружить нижний уровень, но не обнаружил — обязательно добавляем тест именно на нижний уровень • Лучше избегать дублирования тестов на разных уровнях • Необходимое покрытие тестами всегда входит в definition of done задач
22. Примеры распределения тестов по слоям 22
23. BDD-сценарии 23 • Описывают поведение системы с точки зрения пользователя • Фокус на том, ЧТО делает система, а не на том, КАК она это делает • Тестируется весь «вертикальный столбик», взаимодействие всех слоев сервиса • Используют реальные собственные зависимости (БД, кэш, очереди и пр.) • Зависимости внешних сервисов мокируются
24. BDD-сценарии. Структура ‣ Scenario (Сценарий) — последовательность событий и действий, которые 1:1 соответствуют существующему бизнес-сценарию ‣ Given steps (Дано) — описание изначально состояния, контекста системы (seed) ‣ When steps (Когда) — тестируемое действие ‣ Then steps (Тогда) — ожидаемый результат на тестируемое действие ‣ And (И) — используется для последовательности действий 24
25. BDD-сценарии. Сценарий с примерами 25 Каждый пример — запуск сценария с указанными в примере параметрами
26. Наши вакансии 26 Руководитель группы разработки, Склад, Приемка и размещение Старший разработчик С# (Склад, Приёмка и размещение) Инженер по автоматизации тестирования (Python, Склад, Отдел тестирования)
27. alsaraev@ozon.ru Спасибо за внимание Александр Сараев, руководитель направления разработки «WMS»