CQRS & Event Sourcing & Microservices.
Составил для себя пока что два варианта. Следует учесть что понятное дело Materialized View формируется из нескольких потоков данных от нескольких микросервисов.
1. У нас CQRS, с элементами Event Sourcing, но можно в принципе ивенты и не хранить в отдельном store.
https://i.imgur.com/4J5Xuen.png
У каждого сервися есть своя БД, которая отображает связи доменной модели. Приходит Command и обрабатывается сервисом, после записи в локальную БД, кидается Event на Bus и соответственно ловится сервисом представления, обнволяет локальное представление. То есть в данном случае только часть View использует псевдо Event Sourcing. Теперь кейз, когда свалился сервис или запущен новый инстанс View сервиса, как нам получить состояние? Либо если есть EventStore делать реплей полный (или со снепшота) или же тупо делать дамп данных и накатывать их уже внутри (как-то не очень выглядит).
2. Тут уже нет локальной БД, а используется локальный Event Store (ES).
https://i.imgur.com/SOdRtTo.png
В данном случае восстановление состояния возможно только реплеем всех событий, которые записаны в локальном ES. Но вопрос, как нам запросить реплей, чтобы не вывалить обратно все ивенты на EventBus, что повлияет на состояние других сервисов. В данном случае применение реплея будет идти с нескольких сервисов, которые представляет определенный View сервис, но если данные пересекаются порядок выполнения eventов не важен, в инном случае придется делать привязку по времени или же каким-то другим способом.
Подскажите пожалуйста, что по этому поводу думаете. Опять же это чисто размышления на счет проблемы, а не игры в "поломай продакшн":)
Интересно мнение умной аудитории
Спасибо
imho: имеет смысл выделять users из-за billing'а и security, и central-part общую для всех sub-projects или independent, а делать сервисы ради сервисов - bad way.
Обсуждают сегодня