Подходы к обновлению баз данных микросервисов задним числом - PullRequest
Новая
       37

Подходы к обновлению баз данных микросервисов задним числом

0 голосов
/ 27 января 2020

Предположим, есть два микросервиса: A и B. Каждый имеет свои собственные базы данных.

A имеет базу данных со следующей схемой: 

{
    "id": "unique id for the user",
    "name": "the name of the user",
    "email": "the email of the user",
    "address": "the address of the user"
}

, а B имеет следующую схему: 

{
    "userId": "unique id for the user",
    "email": "the email of the user"
}

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

Все отлично, и в базе данных B есть идентификатор пользователя и адрес электронной почты каждого зарегистрированного пользователя.

Теперь по какой-то причине мне нужно, чтобы B также имел адрес каждого пользователя, поэтому B Схема базы данных будет выглядеть следующим образом: 

{
    "userId": "unique id for the user",
    "email": "the email of the user",
    "address": "the address of the user"
}

Теперь у каждого пользователя в базе данных B может быть поле адреса, но пока он будет нулевым.

Мой вопрос: Каковы подходы, чтобы привести базу данных B в соответствие с A (то есть, как мне обновить каждого пользователя B, чтобы также заполнить адрес)?

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

1 Ответ

0 голосов
/ 27 января 2020

Зависит от вашей системы и от того, являются ли данные постоянными или нет.

Если у вас есть события и событие содержит все данные, воспроизведите их.

Если у вас нет событий (т.е. нет источников событий), напишите службу миграции, которую вы запускать один раз до (или во время) развертывания вашего приложения, которое будет для каждой записи в B, извлекать данные из A и обновлять их.

Либо просто подождите, пока он не обновится в какой-то момент. Но для этого случая вам всегда понадобится какой-то «начальный посев» (то есть, когда A вышел задолго до того, как был разработан B). В этом случае он ничем не отличается, так как B не считается «единственным источником правды» (то есть A - B - просто проекция A), поэтому легко отбросить все данные B и повторно скопировать их из данных A.

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

...