Как разработать вето для событий в источнике событий / событие - PullRequest
0 голосов
/ 12 марта 2019

Предположим, что у нас есть простой вариант использования (java / microservice / sourcing / eventuate):

  • Microservice A представляет пользовательскую сущность
  • Microservice B вводит синхронизацию от нашегопользователи к некоторому внешнему хранилищу пользователей (возможно, ldap и т.1010 * Как это реализовать?В классических монолитах мы можем построить что-то вокруг java.beans.VetoableChangeSupport.В микросервисе у меня неприятности.Моей первой мыслью было разделить его на три события.

    Сначала мы опубликуем событие, в котором говорится: «Имя пользователя будет изменено».Вторым событием будет «Изменение имени пользователя отменено», когда микросервису B это не нравится.Третье событие будет «Изменение имени пользователя прошло успешно».

    Пока это будет работать.Но как мы это реализуем?Мне не нравится иметь монолит, который соединяет все микросервисы вместе.Мне нравится иметь некоторые понятия "плагина".Пока мы не запускаем микросервис B, никто никогда не накладывает вето, и мы автоматически запускаем «Изменение имени пользователя прошло успешно».Но как только мы запустим микросервис B, мы должны проверить, любит ли микросервис B наложить вето на событие.

    И как мы можем отделить «микросервис B не работает» от «микросервис B в настоящее время отключен, но скоро вернется»«?В первой ситуации мы не получаем право вето.Во второй ситуации мы должны подождать, пока B не вернется снова, чтобы проверить ожидающие события «имя пользователя изменено».

1 Ответ

0 голосов
/ 25 марта 2019

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

Итак, в Microservice A вы делаете какнасколько это возможно, чтобы убедиться, что изменение не вызовет проблем с синхронизацией MS-B.Затем вы записываете событие «имя пользователя изменено».

Если MS-B не работает, значит, все готово, имя изменилось.
Если MS-B равно работает, и возникает проблема, когда он пытается синхронизировать обновленное имя пользователя, а затем вы переходите в режим исправления.Что именно это означает, будет зависеть от ряда факторов (вероятность возникновения проблемы, ее последствия и т. Д.).
Возможно, MS-B приостановит работу и отправит электронное письмо, чтобы человек мог исправить ситуацию.
Или MS-B может выполнить обратное изменение (другое «имя пользователя изменено» или «изменение имени возвращено на: X» - все, что имеет смысл для вашего домена).

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

...