Синхронизация новых / несинхронизированных микросервисов в системе обмена сообщениями pub-sub

Question

В качестве надуманного примера, предположим, у меня есть сервис Posts для веб-приложения блога, который содержит все сообщения блога.Это сосуществует с другими службами, например, Users и UserLikes, и эти службы взаимодействуют через посредник сообщений на основе pub-sub.

Служба UserLikes позволяет пользователям «нравиться» определенным сообщениям.и поддерживает список активных пользователей для обеспечения согласованности.Для этого он подписывается на сообщения от службы Users для пользователя, который создает / удаляет / обновляет.

Все это работает хорошо, но предположим, что теперь я хочу добавить службу UserDislikes.Эта служба вступает в силу после создания текущих пользователей, поэтому она не будет принимать текущих пользователей в качестве новых пользовательских событий от службы Users.Как нам синхронизировать этот новый сервис с текущим списком пользователей?

Сначала я хотел, чтобы сервис Users периодически публиковал список всех текущих пользовательских объектов (скажем, S3) и публиковалэто событие в теме UserSync.Однако необходимость такой синхронизации встречается редко, и, кроме того, экспорт не будет отвечать на случай, когда другой службе потребуется полная синхронизация.Так в чем же решение?Возможно, тема сообщения UserSyncRequest, на которую служба Users подписывается и экспортирует всякий раз, когда об этом просит другая служба?

Есть еще идеи?

Answer 1

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

Вы ведете список таким образом, что, если пользователь будет удален, ему не будет нравиться сообщение.

В 99% или более сценарии, если пользователь будет удален, все его права доступа будут аннулированы, и пользователь не сможет вызвать API для понравившейся публикации.Так что в любом случае API будут вызывать только действительные пользователи.

И для этого 1% -ного случая, когда у пользователя все еще есть доступ, ведение списка пользователей в службе UserLike не поможет, так как обработка удаленного события в службе UserLike можеттакже есть задержка.

Теперь, если я действительно хочу сохранить список на стороне UserLike или Dislike Service

, сначала я подпишусь на список, чтобы я тоже начал получать события, ноне обрабатывая его

, тогда я буду вызывать API для службы пользователей, чтобы дать мне пользователя в пакетном режиме

после начальной синхронизации, я начну обрабатывать события.

Причина неВыполнение UserSyncRequest заключается в том, что все слушатели UsersEvent получат события, которые они уже обработали.

Answer 2

Пример кажется немного наивным, поскольку границы «лайков» и «дислайков» потенциально могут быть одним и тем же сервисом, но я согласен с примером :).Вероятно, причина, по которой вы создали службы UserLikes и UserDislikes, заключается в том, что пользователь ценится меньше, чем любит и не любит в этих службах.

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

Другое потенциальное решение, которое вы можете посмотреть вместо публикации только соответствующего идентификатора пользователя, состоит в том, что вы можете опубликовать весь пользовательский объект целиком и записать пользователя в базу данных для службы UserDislikes.Технически, в ваших «лайковых» сервисах вы не заботитесь о пользователе, пока ему что-то не понравилось или не понравилось, так что это будет работать нормально.Опять же, для обоих решений вам все равно нужно подписаться на созданные пользователем, обновленные и удалять события.