Привет! Меня зовут Алексей Скоробогатый, я системный архитектор в Lamoda. Недавно мы внесли большие изменения в нашу платформу электронной коммерции: перешли на событийно-ориентированную архитектуру и добавили обработку данных в реальном времени.
На этом примере я хочу поделиться своим опытом реализации эволюционного подхода к изменению архитектуры.
Запрос от компании
Необходимость изменения архитектуры возникла из-за того, что в старой невозможно было реализовать поставленную бизнесом задачу — настраиваемые персональные политики для клиентов.
С их помощью вы сможете добавить в онлайн-продажи элемент геймификации и повысить мотивацию и вовлеченность клиентов.
Различные действия клиента - не только оформление заказа и покупка определенного процента доставленного товара, но даже комментарии к товару и другая активность на сайте - должны фиксироваться, анализироваться, и в результате клиенту присваивается определенная категория.
.
Категория влияет на бонусы, которые получает клиент: процент скидки, подарок в корзине, бесплатная доставка и т. д. 
Причем нам нужно учитывать не только историю клиента, но и его поведение на сайте в режиме реального времени — и сразу общаться с ним, показывать его текущую категорию и подсказывать, как он может переходить из сегмента в сегмент. Это очень важно: чем быстрее мы собираем данные и предоставляем обратную связь по нашим сервисам, тем лучше.
Бизнесу также необходимы инструменты для гибкого управления этими категориями.
Почему нас больше не устраивает нынешняя архитектура?
Как все работало до того, как мы задумались о реализации уровня обработки данных в реальном времени? Наша система в основном состоит из микросервисов, но мы не отказались полностью от монолитов с классической архитектурой — скорее, микросервисы представляли собой второй слой поверх существующего.
Все данные сначала передавались в DWH. 
Затем была проведена аналитика.
Данные обрабатывались с помощью пакетных операций.
Какие-то операции запускались раз в день, какие-то раз в неделю, а то и реже — и результат их работы передавался в виде обратной связи нашим микросервисам.
Как видите, нам пришлось долго ждать обратной связи, а для реализации персональных политик нам требовалось общение в режиме реального времени.
Прежде всего, вам нужен быстрый доступ к данным.
Каждый сервис является хозяином каких-то данных, и их нужно быстро получить.
В старом подходе это реализовывалось с помощью синхронных запросов по сети.
Потребительскому сервису необходимо было связаться с основным сервисом или базой данных, из которой ранее были извлечены данные, и только после этого можно было выполнить обработку.
Но количество потребителей информации от каждого сервиса велико, и их число постоянно растет по мере развития бизнеса.
Для поддержания производительности доступ к данным должен легко масштабироваться, а систему, основанную на синхронных запросах, масштабировать крайне сложно.
Почему невозможно было реализовать запрос в предыдущей архитектуре? 1. нет простого способа получить данные; 2. отсутствует механизм обработки потоков данных; 3. рост глобальной сложности; 4. производительность может пострадать; 5. мы не хотим трогать устаревшие подсистемы.
Какую архитектуру мы хотели построить?
Мы хотели, чтобы наша картина изменилась.Чтобы появились сервисы реального времени и слой обработки данных в реальном времени (ответ за несколько секунд гораздо лучше, чем пакетные операции в течение дня).
Предоставляем обратную связь по нашим услугам, общаемся напрямую с клиентом – условия бизнес-запроса выполняются.
Что именно нам нужно было сделать, чтобы запустить обработку данных в реальном времени?
- Переходите от пакетной обработки к обработке событий, чтобы мы пересчитывали каждое изменение для каждого события и обеспечивали связь.
- Вместо синхронных запросов настройте потоки данных и потоки обработки.
- Создайте уровень преобразования данных, обрабатывающий потоки событий, который идеально настраивается без вмешательства разработчиков.
Дайте бизнесу инструменты для внесения корректировок и изменений.
Теперь, после того как мы внедрили все изменения, нам еще проще их оценить.
Ведь в самом начале мы не до конца понимали, как и что мы хотим получить — многое из того, что я сказал выше, стало понятно где-то в середине проработки бизнес-задачи.
Какие готовые решения были? Потоки Kafka, на его основе вполне можно построить обработку.
Еще Apache Flink — не буду на этом останавливаться.
Больше всего, как оказалось, нашим потребностям по функциональности отвечает Apache Pulsar. У него есть слой преобразования, который подойдет для нашего контекста.
Реализация готового решения: неизвестное неизвестное
Если мы решаем взять готовое решение с рынка, то сразу возникает вопрос, как безболезненно интегрировать его в нашу архитектуру.Ресурсы нужны для экспериментов.
Команды разработчиков необходимо обучить взаимодействию с этим новым компонентом.
Основная сложность реализации чужого готового решения — неизвестное неизвестное.
Мы знаем функционал, который предоставляет эта система, примерно экспериментировали с тем, как она себя ведет. Но мы не знаем, какие подводные камни нас ждут в эксплуатации, если это действительно новые для нас технологии и экспертизы по ним еще нет.
Технология растачивания
В Lamoda мы стараемся максимально использовать «скучные технологии»; об этом подходе вы можете прочитать в статье Технология растачивания .Эти технологии скучны, потому что мы знаем о них все.
И они приносят меньше всего этих неизвестных неизвестных.
В итоге для решения проблемы с персональными политиками мы решили построить свой велосипед — максимально использовать те компоненты, которые у нас есть, и на их основе реализовать обработку данных в реальном времени.
Дизайн мероприятия: данные на первом месте
Прежде чем строить непосредственно обработку данных в реальном времени, нам нужно было внести в систему подготовительные изменения.
- Проектируем события — определяем контекст домена и контракты на передачу данных для каждого сервиса (то есть какие данные и как мы будем передавать через потоки данных).
- Генерируйте потоки событий, научитесь собирать их в одном месте — источнике истины, распределенном журнале транзакций.
- Предоставляйте услуги с легким доступом к потокам.
- Научитесь передавать и обрабатывать события.
Для каждого сервиса мы определяем контекст домена и на основе этого понимаем, какие данные будут передаваться в потоке, исходящем от этого сервиса.
Данные собираются через шину событий (шаблон шины событий).
Спецификации передачи данных описаны в Open API, а сами типы событий с описаниями указаны в реестре схемы.
В нашем случае сборщиком данных (источником истины) был Кафка.
Наш «велосипед»: потоки данных, источник истины и уровень обработки данных
В результате изменилась архитектура нашей системы.
Для всех наших сервисов мы определили контекст (данные, которые они содержат) и подключили к ним соответствующие потоки данных.
Теперь сами сервисы постоянно отправляют данные потоками в шину событий.
А когда сервису, наоборот, нужно получить какие-то данные для обработки, он не обращается напрямую к мастер-системе.
Вместо этого он определяет, какому контексту (домену) принадлежат данные, а затем подключается к соответствующему потоку данных через децентрализованное хранилище (источник истины).
После чего он выполняет необходимую обработку и, в свою очередь, передает данные через свой поток данных.
DWH также может брать данные из источника истины.
Какие технологии мы использовали для реализации всего этого?
В качестве устройства хранения данных о событиях источник истины , мы используем Apache Kafka. Служба обработки данных мы сделали это из API-сервисов с использованием Golang, с помощью которого мы создаем наши микросервисы на платформе электронной коммерции.
Ну для государственное хранилище Мы используем Postgres, как и для наших сервисов API. 
Еще одна важная вещь, которую мы добавили, — это задачи.
События меняют состояние, но не запускают непосредственно обработку данных процессорами.
Каждое событие имеет связанные с ним задачи.
Они могут быть выполнены немедленно или с отсрочкой по времени.
За выполнением заданий следят руководители – рабочие.
А процессоры уже заняты выполнением задач.
Чаще всего процессоры объединяются в цепочки, в которых их можно запускать как последовательно, так и конкурентно.
Процессоры преобразуют данные, вызывая появление новых событий, и цикл повторяется.
Моделирование возможного будущего
Построенная нами архитектура позволяет не только реагировать в режиме реального времени на происходящие изменения, но и прогнозировать последствия событий, которые еще не произошли, но могут произойти в будущем.Поясню на примере: у нас на сайте есть корзина пользователя — это заказ, который еще не создан, но мы знаем, из чего он состоит. И мы можем посчитать и сообщить покупателю, как изменится его процент скидки и другие бонусы, если он создаст этот заказ и купит его полностью.
Для этого мы синхронно повторно используем одни и те же процессоры, вычисляющие реальные события.
Наша архитектура удобна тем, что каждый процессор — это отдельная функция, которая может работать как с событийной моделью, так и с синхронной.
Берем состояние, добавляем к нему дельту (возможные изменения в будущем), запускаем ту же цепочку процессоров и в результате получаем новые данные.
Производительность: менее 10 миллисекунд на ответ
Созданный нами компонент — один из многих, которые появятся в будущем.Он решает конкретную бизнес-задачу с помощью персонализации.
На данный момент он обрабатывает 700 тысяч событий в день и ставит около 2 миллионов задач (150 разных типов).
Мы проверили это посредством нагрузочного тестирования: построенная нами система выдерживает масштабирование нагрузки X10, чего нам пока вполне достаточно.
Текущая нагрузка при общении в реальном времени составляет около 450 RPS, а среднее время ответа — менее 10 миллисекунд.
Балансировка нагрузки при росте и масштабировании
Та часть системы, которую мы изменили, не работает изолированно — это часть всей нашей платформы, которая работает как единое целое.Поэтому нам нужно подумать о том, как мы будем балансировать нагрузку по мере роста и масштабирования.
Наш сервис персонализации политик (Policy) собирает и обрабатывает данные, помещает их обратно в Kafka, передает в приложение — скорость ответа, как я уже говорил выше, теперь составляет 450 RPS. Но у нас также есть служба доставки (Delivery).
Ему нужны данные о клиенте, его скидках и бонусах, которые производит сервис персонализации.
Но сам адрес доставки очень загружен в наших реалиях.
Это 2000 RPS, и мы не можем позволить себе добавить туда синхронный поход в API какого-то другого сервиса.
Поэтому мы договорились масштабировать дублирование клиентского контекста во всех сервисах, где требуется персонализация.
Каждый такой сервис сам хранит данные о клиенте (поскольку синхронные вызовы API по сети разрешить нельзя).
Они также получают обновления через мероприятия.
Мониторинг: Prometheus, информационные панели и оповещения через Icinga
Выше я говорил, что слой трансформации должен быть для нас прозрачным, это очень важно.Мы собираем метрики обо всём, что происходит с данными через Prometheus, и собираем логи в Elastic. Используя Kibana+Grafana, мы создаем информационные панели, а с помощью Icinga мы создаем оповещения и рассылаем их, когда что-то сломалось.
Вот так выглядит плата сервиса личной политики — там есть как технические метрики, так и бизнес-метрики (названия которых я потерял ;) ).
Если мы посмотрим на приборную панель и увидим, что картина изменилась, то мы сможем примерно понять, где что-то пошло не так.
Обработку данных в реальном времени можно построить самостоятельно!
Нам нужна была обработка данных в реальном времени, и мы решили построить ее, максимально повторно используя наши собственные инструменты.
Что произошло в конце?
- Работая небольшой командой из двух-трех человек, включая меня, мы получили MVP за три месяца.
- В процессе решения этой проблемы мы изменили архитектуру нашей системы, поставив данные на первое место.
- Достигнутая нами скорость обработки (менее 0,01 секунды на ответ) позволяет нам удовлетворить текущие потребности бизнеса, а то, что мы создали, достаточно масштабируемо, чтобы удовлетворить требования ближайшего будущего.
- Командам разработчиков легко настроить передачу и обработку событий для новых сервисов, поскольку технологии им знакомы, а спецификации передачи данных описаны и едины для всей системы.
-
Танк «Санта-Барбара». Арджун
19 Oct, 24 -
Выпущен Sql Server 2014 Ctp2
19 Oct, 24 -
Портфолио Для Веб-Программиста
19 Oct, 24 -
Новые Toughbooks От Panasonic
19 Oct, 24 -
Консультант+. Онлайн Не Поддерживает Форекс
19 Oct, 24 -
Вебинары От Adobe
19 Oct, 24
