Модель чтения в микросервисной архитектуре

Question

У меня есть вопрос, касающийся поиска событий в микросервисной архитектуре.

Предположим, что каждый сервис хранит свои собственные события в собственном хранилище событий, как я могу перестроить модель чтения, если проекции нужны данные из более чем одногоservice?

Например, у нас есть UserService и InvoiceService. В модели сервиса счетов-фактур я работаю только с идентификатором пользователя, но в модели чтения мне также нужно имя пользователя для более простых запросов.

Благодарю, у меня есть следующие параметры:

1. Сохраните также имя пользователя в сервисе выставления счетов. Не очень хорошо, я думаю, потому что моим источником истины должен быть пользовательский сервис.
2. Создайте (rest?) API для извлечения имени пользователя из пользовательского сервиса в случае перестройки модели чтения.

Я что-то пропустил? Кто-нибудь знает более простое решение?

Answer 1

Я согласен, что вариант 1 неразумный. Модель домена (модель обновления в CQRS, а не модель чтения) должна иметь только указатели первичных ключей на другие домены, не поддерживающие данные из этих доменов.

Вариант 2 лучше, но все еще не совсем там. Я не являюсь поклонником API-вызовов между доменами при использовании Event Sourcing, потому что это может привести к сбою одного домена или его медленной работе из-за трудностей во втором. В вашем примере наличие домена Invoice вызывает API в домене User для получения имени пользователя для перестройки модели чтения. Это означает, что, если домен User не работает, домен Invoice не может завершить его перестроение - домен Invoice завершается сбоем по собственной вине.

Рассмотрим вариант 3 кэширования информации о пользователе в домене Invoice. Создайте прослушиватели для соответствующих пользовательских событий в домене Invoice и кешируйте необходимые пользовательские данные там - в этом случае только первичный ключ и имя пользователя, но вы можете добавить дополнительные поля позже, если это необходимо. Ваша модель чтения счета-фактуры затем перестраивается с использованием этого кэша, поэтому нет зависимости от домена пользователя.

Просто пояснительная записка, чтобы убедиться, что мы все на одной странице, и для тех читателей, которые новички вCQRS. Модель чтения счета должна содержать ID пользователя и имя пользователя, но модель домена должна иметь только ID пользователя. Чтение моделей повсюду дублирует информацию и не предназначено для третьей нормальной формы;они должны быть очень быстрыми и содержать всю информацию, которая будет отображаться на экране.

Answer 2

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

Я думаю, что вы пропустилиКонцепция событийного магазина. Сервис не должен иметь своего собственного хранилища событий. Представьте, что вы публикуете событие из своего сервиса, и некоторые другие сервисы должны будут подписаться на ваш поток событий. Ваше хранилище событий является единственным источником правды для всех служб.

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

А что если вы не хотите строить прогнозы на стороне хранилища событий? Предположим, у вас есть новое требование показывать отчет о пользователях, содержащий счет-фактуру, общий счет и т. Д. Затем я бы сделал следующее -

1. Подписаться на прослушивание событий UserCreated, UserBasicInfoUpdated от UserService(новая подписка)

2. Подписаться на прослушивание события InvoiceGenerated от InvoiceService (новая подписка)

3. Создание новой модели чтения

4. Затем объедините предыдущую подписку (если есть) с новой. Это важно. Потому что у вас не должно быть нескольких подписчиков на одни и те же события.

Answer 3

Пользователи могут иметь более одного счета-фактуры, и модель воспроизведения / перестройки из источника событий с единственным именем пользователя не будет идеальной (или, по крайней мере, насколько я понимаю). Маршрут, который я предпочитаю, должен иметь a co-relation identifier. Как следует из названия, это поможет вам построить взаимосвязь между вызовами службы / записями источников событий, которые имели место как часть определенной бизнес-задачи / действия. Важно иметь что-то для взаимосвязи, когда дело доходит до перестройки модели (показывать ли на приборной панели или логике для воспроизведения модели / действия). Из быстрого поиска я нашел разговор о идентификаторе взаимосвязи. Пожалуйста, продолжайте, прочитайте больше об этом и посмотрите, решит ли этот подход вашу бизнес-проблему.