Как решить две общие проблемы между хранилищем событий и постоянным слоем?

Question

Две общие проблемы - EventStore и уровень персистентности?

Я хотел бы понять, как отрасль на самом деле решает эти проблемы!

Если микросервис 1 сохраняет объект X в базе данных A. В то же время, для микросервиса 2 для передачи данных из микросервиса 1, микросервис 1 записывает тот же объект X в событиеstore B.

Теперь у меня возникает вопрос: где мне сначала написать объект X?

1. База данных A, а затем в хранилище событий B, справедливо ли откатить поток на уровне приложения, если база данных A не работает?Кроме того, каким должен быть идеальный дескриптор ошибки, если база данных A находится в сети и сохраняется объект X, но хранилище событий B не работает?

2. Как должен выглядеть дескриптор ошибки, если мы пойдем наоборот.в отличие от пункта 1?

Я понимаю, что в современном мире распределенных высокодоступных систем падение систем - сомнительная вещь.Но это может случиться.Я хочу понять, что нужно делать, когда система / кластер базы данных или хранилища событий не работает?

Answer 1

Прежде всего, хранилище событий - это тип персистентности, в котором состояние приложений хранится в виде серии событий, а не персистентности flat , в которой хранится последнее спроецированное состояние.

Если микросервис 1 сохраняет объект X в базе данных A. В то же время, для микросервиса 2 для передачи данных из микросервиса 1, микросервис 1 записывает тот же объект X в хранилище событий B.

Вы пытаетесь использовать два источника истины, которые должны синхронизироваться какой-либо распределенной транзакцией, которая не очень масштабируема.

Это необычный способ использованияМагазин событий.В общем, хранилище событий - это канонический источник информации, единственный источник правды.Вы пытаетесь использовать его в качестве канала связи.Хранилище событий - это постоянство Агрегата, полученного из событий (см. Проект, управляемый доменом).

Я вижу варианты:

1. вы можете реорганизовать вашу архитектуру и сделатьobject X и объект, получающий события, имеющий постоянное хранилище событий.Затем попросите модель чтения подписаться на хранилище событий и построить плоское представление object X, которое сохраняется в базе данных A. Другими словами, сначала запишите в хранилище событий, а затем в базу данных A (но в конечном итогепоследовательным образом!).Это большой скачок, и вы должны подумать, хотите ли вы использовать источники событий.

2. вы можете использовать CQRS без источников событий.Это означает, что после каждой модификации object X испускает одно или несколько событий домена, которые сохраняются в базе данных A в той же локальной транзакции, что и сама object X.Микросервис 2 может подписаться на базу данных А, чтобы получать испущенные события.Фактическая подписка зависит от типа базы данных.

Answer 2

У меня такое ощущение, что вы используете хранилище событий как канал связи, а не как базу данных.Если вы хотите, чтобы микро-сервис 2 передавал данные из микро-сервиса 1 , вам следует общаться с сервисами REST.

Конечно, использование сервисов REST может сделать вас менее устойчивымк отключениям.В этом случае использование технологии, предназначенной для общения, будет правильным решением.(Я думаю, MQ / Темы, такие как RabbitMQ, Kafka и т. Д.)

Затем, когда ваши службы общаются друг с другом, вам все равно нужно будет сохранять свои данные ... но только на одно местоположение.Следовательно, вам нужно определить , где вы хотите сохранить данные.

Задайте себе вопрос:

Кто будет управлять сохранением данных?

• Это Microservice1?Если это так, то каждый раз, когда Microservice2 нужно будет читать данные, он будет вызывать REST для Microservice1.

• Это наоборот?Microservice2 управляет данными, а Microservice1 использует их?

• Это может быть третий микросервис, который вы еще даже не создали.Это зависит от того, как вы применили разделение интересов.

Давайте рассмотрим пример:

• Microservice1 отвечает за обработку наших данных для их экспорта в PDF и другие.форматы
• Обязанностью Microservice2 является предоставление услуги устаревшему партнеру, который требует, чтобы наши данные возвращались в собственном представлении.

кто будет хранить данные, здесь?

• Microservice1 не должен быть единственным, чтобы сохранять данные: его работа заключается только в преобразовании данных в другие форматы,Если для этого требуются некоторые данные, он будет получать их от того, кто управляет данными.
• Микросервис2 не должен быть тем, чтобы сохранять данные.В конце концов, может быть, у нас есть ряд других микросервисов, похожих на этот, но для других партнеров, с другими проприетарными форматами.
• Если есть служба, где вы можете выполнять операции CRUD, то это ваш парень.Если у вас нет такой службы, возможно, вы найдете существующий микросервис, у которого не будет конфликтующих обязанностей.

Например: если у меня есть микросервис3, который всегда проверяет мой ObjectX изменено, он отправит PDF-представление его на какой-либо адрес и уведомит всех моих партнеров, что данные устарели.В этом сценарии этот микросервис выглядит хорошим кандидатом на то, чтобы стать «регулятором данных» для этой части домена и быть универсальным средством для записи / чтения в базе данных.

Answer 3

В общем, вы хотите избегать двухэтапной фиксации того типа, который вы описываете.

В общем, (предполагая систему, основанную на событиях; не уверен, подразумевается ли это в вашем вопросе / вариантедля вас - возможно, SqlStreamStore может быть уместным в вашем контексте?), это обычно достигается путем получения чего-то project из одного авторитетного набора событий на основе извлечения - каждое событие записывается так, чтотребует связанного действия против некоторого нисходящего потока, поддерживает указатель на то, как далеко он получил проецирующие события из базового потока, и перезапускается оттуда в случае прерывания.