Комментарии 15
День добрый!

Вы часом DDD (Data Driven Development) с Domain Driven Design не перепутали? Потому что в докладе «Особенности микросервисов на примере e-Com-платформы / Андрей Евсюков» насколько я помню речь шла про Domain Driven Design.
Добрый! Да, конечно, в том параграфе речь именно про domain-driven. Спасибо, исправил.
Отличная статья! Подскажите, используете ли вы это решение для задач BI?
Спасибо. Это хороший вопрос, т.к. ответ многогранный. Одна грань это наша орг.структура – Data&Analytics у нас это целый департамент и ребята используют внутри себя много интересных решений специфичных для своих задач. У нас же в департаменте разработки, мы себя называем ecommerce платформой – go сервисы, k8s и классика postgres. Из самого, возможно, экзотичного Aerospike. То, что мы хорошо знаем, и что в подавляющем большинстве случаев отвечает нашим требованиям. Задача, описанная в статье скорее исключение.

Ещё одна грань это предсказуемость поведения при изменениях, возможность бесшовно катать изменения вперёд и назад. Т.к. процессинг данных напрямую влияет на критичные бизнес-метрики. Поэтому тут у нас требование как и к стандартным продуктовым фича-сервисам.

Возвращаясь к вопросу, скорее мы как ecommerce платформа будем перенимать опыт и практику из DA. Например, сейчас присматриваемся, как и где мы сможем использовать Spark.

Для каких целей используется schema registry? Почему OpenAPI, заточенный под HTTP-протокол, а не что-то типа Async API?

Schema registry используется для валидации событий между продюсером (build DTO) -> (validate DTO) хранилище событий -> консюмером (build DTO)

Взяли OpenAPI немногим раньше, чем у нас появилась событийная архитектура в разрезе всей ИТ системы. Один из ключевых моментов в принятии решений в ИТ Lamoda это преемственность стандартов. И чем больше агентов решение затрагивает, тем больше мы обращаем на это внимание. Когда нам станет нехватать текущего решения, то AsyncAPI будет первым кандидатом на рассмотрение.

У нас в schema registry хранятся схемы разных форматов. Специально обученный робот генерирует валидаторы, доки, API клиенты,…
Изначально тоже было OpenAPI, но с развитием обмена данными через очереди, обновили код на поддержку AsyncAPI.

Интересный опыт.


сами виды событий с описаниями перечислены в schema registry.
Что вы используете в качестве schema registry?

Существует ли у вас вопросы гетерогенного стека, когда одно и тоже событие нужно публиковать из golang / php / python?

Наш подход позволяет при необходимости публиковать одно и тоже событие из любого сервиса, на любом из поддерживаемых языков, так как кодогенератор способен создать dto события и клиент автоматически.


Тем не менее, мы стараемся не делать так, чтобы одно событие публиковалось из разных источников, так как воспринимаем сообщения, публикуемые в шину доменными событиями систем, а не командами. Появление двух разных сервисов, публикующих одно и тоже событие означало бы, что у нас появляется несколько источников правды.

Какие данные дублируются о клиенте в сервисах? Нет ли проблем с консистентностью этих данных?
Мы храним проекции данных о клиенте (кастомере) в сервисах (фича-сервисы). Т.е. у нас есть шина данных в которой есть общие доменные объекты (точнее их лог). Сервис подписывается на интересующий его поток доменных событий и строит свою проекцию исходя из потребностей. Важно, что этими данными сервис не владеет, а только может обращаться к ним за чтением.

При проектировании всегда нужно держать в голове, что есть консистентность в конечном итоге. Если нужна строгая, то тут мы используем другие механизмы для гарантированной доставки транзакционных изменений. У нас нет единого менеджера транзакций, но эта ответственность лежит внутри каждого сервиса, где нужно обеспечить строгую консистентность. Saga в частности или Outbox в общем случаи. Тут зависит от конкретного контектса. Далеко не всегда и не везде нужна строгая консистентность. Но важно иметь механизмы, которые её обеспечивают в том или ином виде.
Коллеги, а что вы делаете, если у вас рассинхронизировалось состояние в нескольких сервисах?
Тут, пожалуй, два варианта:
1. проектировать коммуникацию между сервисами с учётом минимизации нарушения согласованности данных;
2. предоставлять механизмы, которые позволяют «прокрутить» состояние заново до нужного состояния;

По первому пункту я немного упомянул в комментарии выше, как мы обеспечиваем консистентность бизнес-транзакций. В дополнение приведу ссылку на доклад Bernd Rücker (Camunda BPM) youtu.be/jjYAZ0DPLNM?t=647 [Eng], где он очень хорошо расписывает подходы, как жить в Event-driven парадигме.

По второму пункту нас спасает наше хранилище с возможностью перечитать заново и восстановить состояние.

Конечно, не везде всё так гладко работает, но это те подходы, которые мы стараемся использовать и одна из моих задач это нести в команды эти подходы. Потому что только когда сами команды будут придерживаться этих принципов, тогда можно говорить об успешности реализации.

Про "моделирование возможного будущего" было бы интересно узнать подробнее. Если это синхронный запрос со стороны браузера, то правильно ли я понял, чтобы дать клиенту представление о его будущем, этому запросу нужно пройти через ряд процессоров, наложить дельту на текущий state и вернуть этот потенциальный будущий state назад в запрашивающий сервис? Я так понимаю, что без асинхронного поллинга со стороны браузера тут не обошлось? Иначе бы вы не уложились в те 10мс SLA.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Информация
Дата основания

5 апреля 2011

Местоположение

Россия

Численность

5 001–10 000 человек

Дата регистрации

20 сентября 2018

Блог на Хабре