Comments 15
Вы часом DDD (Data Driven Development) с Domain Driven Design не перепутали? Потому что в докладе «Особенности микросервисов на примере e-Com-платформы / Андрей Евсюков» насколько я помню речь шла про Domain Driven Design.
Ещё одна грань это предсказуемость поведения при изменениях, возможность бесшовно катать изменения вперёд и назад. Т.к. процессинг данных напрямую влияет на критичные бизнес-метрики. Поэтому тут у нас требование как и к стандартным продуктовым фича-сервисам.
Возвращаясь к вопросу, скорее мы как ecommerce платформа будем перенимать опыт и практику из DA. Например, сейчас присматриваемся, как и где мы сможем использовать Spark.
Для каких целей используется schema registry? Почему OpenAPI, заточенный под HTTP-протокол, а не что-то типа Async API?
Взяли OpenAPI немногим раньше, чем у нас появилась событийная архитектура в разрезе всей ИТ системы. Один из ключевых моментов в принятии решений в ИТ Lamoda это преемственность стандартов. И чем больше агентов решение затрагивает, тем больше мы обращаем на это внимание. Когда нам станет нехватать текущего решения, то 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.
Как настроить real-time data processing на летящем корабле