Детализация тем в архитектуре, управляемой событиями

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

Давайте представим, что у нас есть система управления пользователями, в которой пользователи могут выполнять различные действия, такие как регистрация, вход в систему, изменение некоторых атрибутов профиля и т. Д. Если мы хотим уведомить остальные службы об этих изменениях, я могу подумать о некоторых возможностях для название темы:

  1. Одна тема для каждой из классических операций CRUD в каждой из моделей (исключая чтение, поскольку состояние пользователя не меняется). У нас были бы user-created, user-updated, user-deleted. Этот подход является достаточно общим, но потенциально может быть много служб, подписанных на user-updated тему и отбрасывающих все те события, которые не изменяют конкретное поле.

  2. Одна тема для каждого важного для бизнеса изменения. В дополнение к user-created и user-deleted у нас могут быть такие события, как user-email-updated, user-signed-in (которые в противном случае были бы запущены как событие user-updated, когда была изменена дата последнего входа в систему) и т. Д. Я считаю, что даже если это было бы удобно тем подписчикам, которых интересуют только очень конкретные изменения, будет сложнее для тех служб, которым необходимо синхронизировать все, что происходит с пользователем, поскольку им придется подписываться на все большее количество тем, чтобы отслеживать все изменения в модель пользователя.

  3. Смесь от 1 до 3, где оба события user-updated и user-email-updated будут отправляться, когда пользователь обновляет электронное письмо, но только user-updated будет отправлено, если пользователь изменит профиль.


events architecture event-driven event-driven-design soa
person Bustikiller    schedule 04.03.2019    source источник
comment
Вариант 2 - ваш лучший вариант, бизнес-события, из которых вы можете найти контекст. мои 2 цента, рад обсудить дальнейшие   -  person Sean Farmar    schedule 04.03.2019
comment
@SeanFarmar спасибо за ваш комментарий. Недостаток, который я вижу здесь, заключается в том, что для некоторых изменений в модели не может быть никаких дополнительных действий, кроме синхронизации нового значения с остальной частью службы. Я думаю, что в модели может быть много изменений, которые необходимо синхронизировать между сервисами, но без достаточной релевантности, чтобы иметь отдельную тему. Есть ли у вас еще идеи, как с этим бороться?   -  person Bustikiller    schedule 06.03.2019
comment
Тематическая маршрутизация не является обязательным условием для создания систем, управляемых событиями. Я бы посмотрел на архитектуру служебной шины, в которой маршрутизация является публичной и децентрализованной.   -  person tom redfern    schedule 07.03.2019

Ответы (1)


arrow_upward
1
arrow_downward

Можно реализовать второй вариант, но реализовать его с иерархией тем, чтобы позволить подписчикам выбирать степень детализации их интересов (например, при подписке на users. * Или * .updated или user.actions.login и т. Д.)

Некоторые технологии (например, RabbitMQ) имеют эту встроенную возможность, для других вы можете реализовать реестр тем и предоставить инфраструктуру для самостоятельного управления подписками.

person Arnon Rotem-Gal-Oz    schedule 06.03.2019