Привет, я – Павел Савельев, глава отдела BPA (Business Process Automation) в Lamoda. Это один из самых крупных отделов в нашем IT – 9 команд, и мы планируем расширяться и дальше. Расскажу о том, как устроен мой отдел разработки и что “под капотом” у Lamoda.
Если совсем просто, то BPA – это такая централизованная сеть, которая объединяет службу доставки, огромный склад и систему управления заказами, с разработкой и интеграцией с партнерами. Все это обвязано отчетами и аналитикой. Мы проектируем и пишем все сервисы по взаимодействию этих систем и предоставлению похожих услуг партнерам.
В нашем отделе IT встречается с реальным миром: в IT-системе легко выставить 15-ти минутный интервал доставки, однако довольно сложно сделать так, чтобы тысячи торговых представителей в Москве приезжали на адрес ровно в этот промежуток. Основная задача нашего отдела связывать бизнес и технологии. Сам отдел BPA сейчас — это три направления: доставка, склад и коммерческая функция, в которую входит взаимодействие с B2B и market place. И все, чем мы пользуемся сами и продаем вовне – это реально круто: наши фичи приносят деньги, экономят время и предлагают качественный сервис нашим клиентам.
5 языков и 2 млн строк кода
BPA — это множество систем, которые интегрированы друг с другом и другими системами Lamoda. Для их разработки мы используем PHP, Java, Kotlin, есть немного Go и Typescript – на нашем техрадаре 5 языков. Все системы мы пишем под задачи нашего бизнеса. Сейчас это 2 миллиона строк кода, 25 сервисов и более сотни переиспользуемых библиотек.
Основной язык — PHP, еще несколько крупных сервисов написаны на Java и Kotlin. Почему PHP? Во-первых, на нем реализована система процессинга заказов — монолит, который мы распиливаем на микросервисы уже много лет, а во-вторых, мы классно умеем работать с PHP: быстро пишем на нем, хорошо обслуживаем, обжили его кучей библиотек. Этот подход позволяет нам запускать новые сервисы со всей инфраструктурной обвязкой: со всеми логами и мониторингами, буквально за несколько дней. Мы можем использовать и Go, и Kotlin, как на складе. Мы не используем дублирующиеся технологии, а все остальное не запрещено, лишь бы работало.
В бизнес-процессах важна логика и продуманность каждого шага. Чтобы не получилось так, что ваш заказ поехал со склада во Владивосток, а там в системе внезапно выскочила неожиданная табличка, и его вам не выдали.
Мы должны покрывать каждый шаг тестами, поскольку критически важна стабильность и корректность исполнения логики работы системы. Тем более, что нашими бизнес-процессами пользуются еще и наши партнеры. Поэтому приоритет компании — стабильность, несмотря на то, что для бизнеса скорость запуска новых сервисов тоже важна. Для обеспечения стабильности мы инвестируем время в проектирование сервисов и тестов вокруг них. Это дает нам возможность развивать систему, не рискуя все сломать.
Есть даже гречка!
Я – Антон Дмитриенко, техлид WMS — системы управления распределительным центром Lamoda или если проще — складом.
Мои основные задачи – это разговаривать на одном языке с бизнесом, развивать доменную модель и готовить систему к изменениям. Для этого необходимо понимать, где у нас «горячие точки». Есть процессы, которые выстроены один раз на три года, а бывают те, которые меняются раз в три месяца – это и есть «горячие точки». Их важно учитывать при проектировании системы.
Сейчас у меня четыре команды – 18 человек, которые занимаются созданием, тестированием и поддержкой системы. Мы ускоряем все операционные и бизнес-процессы склада: без нас с текущими объемами бизнеса Lamoda, отгрузка одного клиентского заказа занимала бы много времени, наше участие сокращает время обработки любого заказа до 4-х часов.
Масштаб, конечно, очень большой: склад Lamoda — это примерно 40 тысяч квадратных метров или несколько футбольных полей в 5 этажей, где хранится 10 миллионов товаров. Он работает круглосуточно 364 дня в году, выходной бывает один раз в год – 1 января. И каждый день на смену выходит более 500 сотрудников, а через нашу систему проходит отгрузка и приемка 200 тысяч товаров. Плюс внутри склада развернута сеть механизированных конвейеров и оборудования, которые предназначены для транспортировки товаров, упаковки посылок, физической консолидации клиентских заказов, сортировки посылок по направлениям отгрузки, ими мы также управляем.
Lamoda продает клиентам разные категории товаров: от негабаритных зонтов и чемоданов до маленьких часов и ювелирных изделий. Все это хранится и обрабатывается у нас на складе. У каждой категории свои особенности. Например, негабаритные товары нельзя обрабатывать на автоматизированном оборудовании, с дополнительными мерами безопасности хранятся и обрабатываются ювелирные изделия, а косметика, духи, например, требуют определенных температурных условий хранения и контроля сроков годности товаров.
Недавно у нас был проект «Гречка». После введения режима самоизоляции Lamoda добавила в ассортимент популярные продукты питания с длительным сроком хранения. Кстати, мы реализовали такую возможность всего за несколько дней. Конечно, основной ассортимент — это одежда и обувь, работа с которыми также имеет некоторые нюансы: для продажи товары необходимо подготовить и проверить их качество: будет плохо, если мы, например, привезем клиенту рубашку без пуговиц.
Lamoda это не просто интернет-магазин, а полноценная e-commerce платформа, которая предоставляет свою инфраструктуру и сервисы (в том числе и склад) внешним партнерам. Например, крупные международные fashion бренды, хранят свои товары у нас. Вроде какая разница? Платья, пальто и обувь у партнеров такие же, как те, что уже лежат на нашем складе. Но у всех есть индивидуальные требования к процессам, которые мы обязаны соблюдать по контрактам, например, часть товаров крупных клиентов хранятся в отдельных зонах, а вещи из маркетплейса располагаются по всему стоку. Эти особенности также необходимо учитывать.
Каждый товар на каждом этапе процесса мы проверяем и обрабатываем с учетом специфики не только в физическом мире, но и в IT-системе. Более того, IT-система сама подсказывает сотруднику склада, как надо обращаться с конкретным товаром, так как оператор не может знать все особенности или договоренности: на товаре не написано, кому он принадлежит: крупной международной компании или небольшому партнеру по маркетплейсу.
Ключевая особенность системы – взаимодействие через сканеры и штрих-коды: на каждом товаре наклеен уникальный штрих-код, считав который можно получить всю необходимую информацию о товаре. Такой подход минимизирует ошибки и позволяет проводить все действия с товаром быстрее, сокращая количество сотрудников. Если мы за сутки отгружаем 200 тысяч товаров, то сэкономленная на одном товаре 1 секунда – это 55 часов рабочего времени. Для бизнеса — ощутимо.
Под капотом склада
Наши технологии:
· Java 8,
· PostgreSQL,
· Wildfly,
· Spring,
· Redis,
· ActiveMQ,
· Hibernate.
Мы начинали с готового решения на Java, но с тех пор функциональность системы очень сильно расширилась и код уже несколько раз полностью рефакторился, переписывался.
Сейчас у нас 350 тысяч строк кода – и это только бэкенд основного приложения, а еще есть 5 второстепенных сервисов и 2 пользовательских интерфейса: тонкий веб-клиент и мобильное нативное приложение. Мы ведем full-stack разработку.
Мобильным клиентом пользуются сотрудники склада. Они перемещаются по складу, используя наше собственное приложение под Android, это более современная и удобная технология, которая позволяет использовать особенности самого устройства: вибрацию, звуки для ошибок, а батарея тратится меньше, если приложение нативное, а не браузерное. Само приложение написано на Kotlin, у нас хороший опыт его использования. Мы даже начали писать на нем бэкэнд: пока это только один сервис, но нам нравится, что код получается проще и выразительней, чем на Java, а производительность такая же. У нас нет цели все переписать на Kotlin, но мы и дальше будем его использовать для подходящих задач.
Взаимодействие с другими системами Lamoda построено через шину данных, написанную на Apache Camel с применением брокера сообщений ActiveMQ. Такой подход обеспечивает гарантированную доставку и относительно простую трансформацию сообщений под различные форматы, возможность распределения сообщений по нескольким потребителям. Мы первыми стали использовать Apache Camel в далеком 2014 году, затем этот способ интеграции переняли и другие команды нашего отдела.
Принципы построения систем склада:
· надежность и качество
· расширяемость и гибкость
· простота
Склад находится в центре логистических процессов Lamoda, ошибки и простои системы сильно влияют на бизнес. Поэтому мы уделяем пристальное внимание стабильности и отказоустойчивости системы. Надежность достигается за счет дублирования критических элементов системы и инфраструктуры. У нас два независимых сервера, которые нарезаны на виртуальные машины. Каждое приложение разворачивается на двух инстансах, каждый инстанс — на своей виртуалке. Клиент с сервером взаимодействуют через балансировщик в виде Haproxy, который маршрутизирует запросы на один из инстансов. База данных также резервируется за счет применения схемы репликации Master-Slave.
Все наши серверы физически располагаются прямо на складе, это также повышает надежность и скорость работы за счет взаимодействия всех элементов системы по локальной сети. Даже если у нас отвалится внешний интернет, то мы все равно продолжим работать, а на случай отключения электричества у нас есть источники бесперебойного питания и бензиновые генераторы прямо на складе.
Чтобы минимизировать количество ошибок в коде мы пишем автоматизированные тесты: unit, интеграционные, приемочные, нагрузочные, а команда тестировщиков все проверяет руками. Все это обязательная практика и встроено в жизненный цикл задачи, иногда, конечно, вылезают баги, но полноценных откатов релизов у нас не было уже несколько лет.
Расширяемость и гибкость — для нас это в первую очередь вопрос, сколько усилий и времени мы потратим для изменения системы под новые требования бизнес-процессов. Поэтому при разработке предусмотрена возможность быстрого и простого изменения кода в будущем. Например, любой категории товаров можно настроить определенное место физического хранения, это позволяет быстро подключить для продажи новые категории товаров. Для каждого заказа настраивается, в какой материал он будет упакован и какие сопроводительные документы для него будут распечатаны. И это только малая часть функций.
У нас сложная предметная область с большим количеством бизнес процессов и разветвленной доменной моделью. Чем проще код, тем лучше, потому что это увеличивает его читаемость, понятность, снижает вероятность ошибок. И позволяет больше сосредоточиться на том, какую функцию для бизнеса выполняет код.
Страховка от ошибок
Меня зовут Денис Плиско – я руководитель направления разработки для службы доставки в BPA.
Мы создали, развиваем и поддерживаем IT-систему LM Express. Она служит для автоматизации работы транзитных складов, торговых представителей и пунктов выдачи заказов. Наша система знает все о прибытии и отправке поставок, занимается их обработкой, осуществляет продажу и выдачу уже оплаченных заказов, прием возвратов и множество других сопутствующих бизнес-процессов. Также в ней мы фиксируем и анализируем физические действия наших торговых представителей и работников складов – отслеживаем все, что происходит на «последней миле» перед передачей товара покупателю. Большая часть технических процессов, которые есть в информационном виде в системе Express, отражают физические действия сотрудника службы доставки.
Как это выглядит? Например, работник принимает поставку, достает из нее паллету – короб, где лежат пакеты с товарами, достает пакеты, сортирует их по полкам: каждое действие, которое он делает, сопровождается операцией у нас в системе. И вот тут могут возникнуть ошибки: никогда нельзя быть уверенным, что даже если сотрудник доставки все «накликал» правильно, то так оно и есть. Как следствие, одна из самых больших частей логики наших процессов – это предупреждение и исправление ошибок: иногда это можно сделать автоматически, иногда через самого человека, иногда через службу поддержки или пользователей, у которых есть более расширенные права. Если бы не эти особенности, то наши системы были бы в 5 раз меньше.
Принципы построения систем доставки:
· стабильность и доступность систем
· консистентность данных
· независимость от внешних систем и сервисов
Задача — обеспечить максимально стабильную работу систем, так как от этого напрямую зависит получат ли люди свои покупки вовремя или нет. При реализации любой функциональности мы стараемся быть независимыми от внешних сервисов и систем, для этого многие взаимодействия дублируются. Допустим, приехала поставка, а по ней нет данных о заказе, тогда мы запросим эту информацию сами, чтобы не останавливать работу. Также важно делать многие операции идемпотентными, чтобы сохранить необходимую консистентность данных, особенно в обменах с другими сервисами.
Более того, все необходимые данные мы стремимся получать, как можно раньше, чтобы не получилось, что человек пришел за товаром, и не может его получить из-за сбоя системы. Мы стремимся сделать внутренние части системы предельно надежными, чтобы взаимодействие с ними пользователя зависело лишь от наших собственных сервисов. Таким образом, даже если все системы Lamoda временно станут недоступны, то работа складов и ПВЗ не остановится и основные операции продолжатся.
По улицам курьеры, курьеры
Помимо собственной доставки, Lamoda сотрудничает со сторонними курьерскими службами, например, «Почтой России», «Пони-экспресс», DPD и другими. Это происходит когда в городе, регионе или стране (например, в Украине) наша доставка возможна только через партнеров. Мы обеспечиваем обмен информацией через взаимодействие с их IT-системами.
Подключение каждой новой курьерки – это увлекательное приключение, так как API у всех очень разные и не всегда адаптированы для интеграции. Это происходит потому, что часть курьерских служб – исторически оффлайн компании. Они занимались доставкой еще во времена бумажного документооборота, а написать хорошее API — непростая задача.
Мы используем специальную систему на базе ESB фреймворка Apache Camel для реализация интеграции с новым партнёром. Использование Camel позволяет легко выполнять самые разные преобразования данных и взаимодействие по разным протоколам обмена. Обычно настройка интеграции с новой курьерской службой занимает от двух недель до месяца.
Доставка – одна из услуг, которую наряду со складом мы продаем нашим партнерам. При заказе товара в интернет-магазине популярного бренда одежды, который с виду не имеет никакого отношения к Lamoda, покупку доставит торговый представитель в форме LM-экспресс. Этими проектами мы занимаемся совместно с командой коммерческой функции.
Для реализации проектов нашего бизнеса я и наши техлиды из 2-х команд (в третью сейчас идет найм разработчиков и тестировщиков) определяем, как лучше уложить все изменения в нашу текущую архитектуру.
Мы работаем на основе бэклогов из списка проектов. Каждый проект бизнес оценивает с точки зрения финансового и маркетингового эффекта. Мы оцениваем трудозатраты и продумываем технический подход: можно ли сделать новую фичу быстро и эффективно или, наоборот, это будет так дорого и сложно, что перекроет весь бизнес-эффект. На основе этих оценок мы корректируем бэклог и делаем проекты из верха списка. Около 30% времени разработки у нас заложено на технический бэклог, поэтому выискивать время на рефакторинг и улучшение систем с технической точки зрения не приходится, все идет по плану.
Внутренний мир доставки
Наши технологии:
· PHP,
· Java,
· Kotlin,
· TypeScript,
· MySQL,
· PostgreSQL,
· RabbitMQ,
· ActiveMQ,
· Apache Kafka,
· Apache Camel,
· Docker, K8S.
Большинство наших сервисов построены на РНР. Исторически сложилось, что на этом языке были написаны системы, на которых была создана Lamoda. Одна из первых версий сайта была создана на Magento, потом для доставки и обработки заказов за основу были взяты системы Rocket Internet. Они пережили множество итераций развития и переработок, но РНР и сегодня лежит в основе почти всех сервисов, в том числе и новых. У нас уже написано около 200 тысяч строк кода, и много опытных разработчиков на PHP (направление доставки вместе с QA инженерами насчитывает 20 человек и активно расширяется) – но они не ограничиваются одной технологией, это отличные инженеры, которые выбирают подходящий инструмент под задачу.
Мы не собираемся отказываться от PHP в бэкенде, так как у нас хорошо развита культура разработки на нем: мы используем свежие версии языка и фреймворков, покрываем почти весь код тестами, проводим тщательный code review, имеем хорошо выстроенный CI и немало общих библиотек, которые ускоряют процесс разработки.
В отличие от online-shop у нас нет больших нагрузок связанных с RPS. В первую очередь нам необходима сложная и гибкая архитектура приложений, с большим количеством уровней абстракций (стараемся придерживаться DDD) для сложной и, порой запутанной, бизнес-логики. Также у нас огромное количество как синхронных обменов (JSON-RPC, SOAP), так и асинхронных обменов (RabbitMQ, Apache Kafka) с другими системами.
Итого примерно 80-85% систем написаны именно на PHP, хотя мы иногда используем Java. На нем написан сервис взаимодействия с внешними службами доставки, который мы постоянно изменяем.
Фронтенд представлен связкой VueJS + TypeScript. Наши админки для внутренних пользователей не требуют супер-верстки или сложного дизайна.
Также у нас есть мобильное нативное приложение для торговых представителей, которое написано на Kotlin под Android. Когда-то его разрабатывали выделенные в команду мобильные разработчики, но сейчас мы весьма успешно развиваем его своими силами.
Для сотрудников которые работают на транзитных складах, откуда заказы разъезжаются по всем складам и ПВЗ России у нас есть web-приложение. При таком подходе существует риск недоступности нашего приложения в связи с отключением интернета в конкретном пункте самовывоза или на складе, но мы минимизируем его, используя резервирование каналов связи.
Помимо этих систем, которые касаются доставки («Express» и мобильное приложение, шина для интеграции с внешними курьерскими службами) у нас есть еще два сервиса, которые наша команда поддерживает в данный момент: это сервис по печати электронных чеков и Datamatrix. Последний предназначен для обеспечения маркировки товаров уникальными кодами в соответствии с новыми требованиями законами. Эти два проекта не имеют непосредственного отношения к доставке, но именно через наши сервисы идет обмен необходимыми для них данными.
Служба доставки печатает чеки: у каждого торгового представителя есть касса, плюс на каждом нашем ПВЗ стоят кассы. Поэтому сервис фискализации постоянно взаимодействует с нашей системой. Datamatrix затрагивает почти все системы BPA (склад, доставку, партнерские взаимодействия, учетные системы). Наше подразделение тоже очень активно взаимодействует с ним, поэтому мы приняли активное участие в его разработке. Прямо сейчас ведем разработку новой системы для политик мотивации торговых представителей.
Коммерческая функция BPA: что мы продаем
Перед компанией стоит амбициозная цель — быть лучшей fashion-платформой в СНГ. Для этого Lamoda много вкладывала в качество сервиса и с нуля поднимала операционные процессы: доставка, склад, фотостудия, работа операторов контакт-центра. Все операционные процессы проверены и обкатаны на наших клиентах. Мы экспериментировали, следили за клиентской обратной связью, ошибались, исправляли ошибки, постоянно улучшали все, что можно улучшить в опыте покупки товаров через интернет. На пятом году жизни компании мы приняли решение, что готовы делиться нашими ресурсами и экспертизой с другими игроками рынка.
Так у нас появилось первое B2B направление, предоставляющее крупным партнерам услуги фотостудии, хранения и доставки товаров, обзвона клиентов. Вскоре внутри компании появился Marketplace, для средних и небольших компаний, который предоставляет витрину Lamoda, как дополнительную услугу к предыдущему списку. Оба направления работали и развивались практически параллельно, догоняя и перегоняя друг друга в наборе услуг.
Спустя еще 3 года и после оценки результатов было принято решение объединить B2B и Marketplace в коммерческую функцию, которая занимается созданием, развитием и поддержкой услуг для внешних партнеров, на базе существующих внутренних сервисов Lamoda.
Сейчас мы сотрудничаем с примерно 20 крупными брендами — это все глобальные компании с мировым именем, которые имеют свои комплексные бизнес-процессы. Еще 1000 наших клиентов — это средние и небольшие компании, у которых зачастую нет развитой IT-инфраструктуры. Для всех партнеров мы на своей стороне поддерживаем отдельный слой интеграции, который предназначен для быстрой и гибкой разработки функциональности, конвертирующей внешние процессы в наши.
Я – Алексей Фельде, solution архитектор, отвечаю в Lamoda за техническое и продуктовое развитие коммерческой функции.
Я занимаюсь развитием и поддержкой сервисов в слое интеграции, а для этого я должен досконально разобраться в бизнес-процессах компании и наших партнерах, чтобы проектировать любые изменения в системах Lamoda.
Как я упоминал выше, мы развиваем два основных направления взаимодействия с брендами: Marketplace для небольших брендов, которым предоставляем SAAS решение в виде отдельного WEB приложения, и B2B — отдельные большие проекты для крупных мировых брендов, которым дополнительно либо полностью предоставляем наши операционные мощности, либо помогаем интегрироваться с нашими.
B2B направление одно из самых интересных в компании, но одновременно одно из самых сложных. Бывает, что к нам приходит мировые fashion-гиганты с совершенно новыми для нас требованиями или ограничениями интеграции. В таких случаях моя команда взаимодействует с другими командами Lamoda, и мы проектируем изменения в любом необходимом сервисе компании. Для подключения одного из лидеров мировой модной индустрии нам потребовалось погрузиться во все его бизнес-процессы, включая бухгалтерские и операционные. В рамках проекта мы затронули 15 наших внутренних процессов: начиная с описания товаров на сайте заканчивая эккаунтингом и доставкой. Моя команда владеет самой широкой экспертизой по работе IT-систем и бизнес-процессов Lamoda. Это требует тщательно систематизировать и документировать наши знания.
Для небольших производителей одежды, обуви и аксессуаров, у которых часто даже нет собственного IT-подразделения, мы предоставляем коробочное решение Marketplace, которое позволяет отслеживать продажи, движение товаров, возвраты. Оно полностью работает на мощностях наших систем: фотографии товаров делаются нашей студией и хранятся у нас, товары физически находятся не у клиента, а на нашем складе, и доставляются службой доставки Lamoda.
Еще один наш коробочный продукт с исходным кодом – фотостудия. Несколько лет назад ее купил крупный люксовый ритейлер. У них на сайте были очень разные фотографии, и это сильно влияло на конверсию продаж. Наша же фотостудия проводила большое количество тестов с фотографиями: какие из них лучше продают (фото мужчин без головы или с головой, правильные ракурсы ноги и т.д). Результаты этих тестов очень понравились клиенту, и он хотел применить наш опыт в своем интернет-магазине. Для этого ему нужно было построить аналогичную нашей студию, где будут работать люди, организовать процесс фотосъемки, и поставить нашу IT-систему.
Lamoda в миниатюре
У нас в отличие от сервисных команд стоит другая задача — развитие интеграционного слоя, за которым скрывается энтерпрайз большой компании. Основной продукт — B2B-платформа, которая на уровне кода внутри разбита по модулям: модуль работы со складом, модуль работы с доставкой и так далее. Это одна большая система, которая на уровне этих маленьких модулей может управлять определенными услугами. Получается, что наша платформа – это Lamoda в миниатюре. При этом партнеры видят лишь одно API – универсальное и очень простое, за которым скрыта вся сложность Lamoda. При этом мы должны быть максимально простыми для интеграции – наш первый принцип при разработке, дальше идут стабильность и надежность. Мы поддерживаем различные SLA, например, одно из них — это 4 часовое максимальное время недоступности системы в год. Как и коллеги, мы много внимания уделяем задачам по отказоустойчивости, процессам релиза, качеству кода, покрытия функциональными тестами. Наша B2B платформа чуть ли не самая первая система в списке по количеству тестов, у нас более 2 000 функциональных тестов и 3 000 юнит-тестов.
Принципы построения системы B2B платформы:
· простота и универсальность интеграции
· стабильность
· надежность
· отказоустойчивость
Интеграция в действии
Наши технологии:
· PHP,
· Java,
· JavaScript,
· немного GO,
· Symfony,
· Camel,
· PostgreSQL,
· AngularJS,
· Apache Kafka,
· RabbitMQ.
Перед подключением бренда мы согласуем с партнером все детали взаимоотношений: ассортимент и ожидаемое количество товаров, географию доставки, набор подключаемых услуг. Далее в игру вступает IT составляющая: с брендом обсуждаются детали интеграции и помогаем подключиться к нашему API. Если что-то отличается от стандартной схемы интеграции, то дополнительно поднимаем сервисы, которые являются middleware между системами партнера и нашей B2B-платформой.
90% времени мы модернизируем нашу платформу и внедряем новые бизнес-процессы. Последний из внедренных бизнес процессов — работа с Datamatrix кодами, о котором уже рассказывали в другой статье, а коллеги упоминали выше.
В нашей работе главное соблюдать баланс технологий и выбирать инструменты под решаемые задачи. Мы, честно, не гонимся за модой в индустрии. Наш стек — это PHP, Java, Javascript и немного Go.
Как уже упоминалось в статье, в компании множество систем исторически написаны на PHP. На нем удобно и быстро программировать бизнес-процессы. На нем написана основа нашей B2B-платформы – авторизация, управление ролями, все основные бизнес-процессы. В основе – гексогональная архитектура, активное использование DDD и API first дизайн. Мы поддерживаем Single Page Application, написанный на Angular 1.5. Оно общается с нашей B2B-платформой по API и несет основную ответственность рендеринга UI для сотрудников нашей компании и сотрудников партнера.
Мы также используем и Java, в частности интеграционный фреймворк Camel. Не всегда бренды готовы использовать наше API, и для очень крупных игроков мы пишем middleware, которые занимаются конвертацией предметной области бренда в предметную область Lamoda. Camel экономит время на разработку решений по интеграции систем, изменяет людей в сторону хороших инженерных практик с использованием enterprise integration patterns (EIP). Мы планируем развивать Camel в тех местах, где удобнее использовать интеграционные паттерны, чем писать какой-то отдельный сервис.
Для обменов данными между внутренними системами активно используем Kafka. Это значительно уменьшает связность между системами, ведь нам в специфике нашей работы необходимо хранить заточенные для партнеров слепки данных со всех систем. Для всего, что должно делаться быстро и для служебных задачи мы пишем на Go. Один наш сервис каждую минуту вычисляет на основании хранимых данных метрики. Раньше это решение было встроено в B2B-платформу и было написано на PHP, но мы переписали это на шустренький Go, так как у него выше производительность, проще поддержка, он лучше масштабируется и можно деплоиться вне релизного цикла B2B -платформы.
Я искренне радуюсь, когда я вижу на 30+ сторонних сайтах крупных и известных fashion-брендов результат работы нашей платформы. Вижу, как заказ, который оформляется в наших системах с чужого сайта, обрабатывает наш оператор контакт-центра, а затем его перевозят нашей доставкой. Никто не знает, что все эти процессы созданы и автоматизированы в Lamoda, но мы делаем это так круто, что наши процессы покупают мировые бренды.
Автор: Pavel Savelyev
