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

Мне поручено создать поток событий, в котором у меня есть автоматический опросчик (установленный с 10-минутными интервалами) для извлечения всех объектов, которые изменились за последние 10 минут.

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

  1. Получает предыдущее состояние объекта
  2. Сравнивает это предыдущее состояние с самым новым состоянием (т.е. diff)
  3. Создайте событие обновления, если хотя бы одно из полей, которое бизнес-логика определила как важное
  4. Если событие обновления было создано, замените предыдущее состояние объекта последним.

Учитывая эту архитектурную проблему, существует ли известный шаблон или набор шаблонов или рекомендации по построению системы такого типа?


api architecture rest data-modeling event-stream
person ugotchi    schedule 06.11.2019    source источник

Ответы (2)


arrow_upward
3
arrow_downward

Каноническое решение этой проблемы наоборот: вместо того, чтобы обнаруживать изменения после их внесения, система должна в первую очередь создавать события изменения. Другими словами, API не должен позволять сохранять новые версии объектов; вместо этого он должен только разрешить применение изменений. С точки зрения проектирования системы, работа в обратном направлении (обнаружение изменений после того, как они уже сделаны) создает более сложную систему, поскольку она включает в себя больше шагов.

Наиболее распространенной реализацией этого подхода является Источник событий, который также хорошо сочетается с CQRS. Два обычно ставятся вместе. Правильная реализация Event Sourcing может быть сложной задачей, и ее, безусловно, не следует использовать без веской причины (хотя ваш вариант использования, безусловно, звучит так). В зависимости от того, где производятся изменения, вы можете рассмотреть возможность использования фреймворков, облегчающих отслеживание изменений (например, Redux на уровне пользовательского интерфейса) .

Я понимаю, что эту модификацию, возможно, необходимо добавить в систему, которая уже разработана для хранения версий сущностей. Одним из возможных решений в этом случае является создание уровня изоляции между двумя мирами: уровня в системе, который будет преобразовывать версии сущностей в поток изменений. Например, сохраните существующий интерфейс, но замените его реализацию на основанную на событиях; создавайте события как можно раньше в системе, вместо того, чтобы смешивать два подхода.

Надеюсь, это имеет смысл.

person Timur    schedule 16.11.2019
comment
Привет, спасибо за ответ. Не могли бы вы подробнее рассказать о решении для слоя изоляции? Чтобы обеспечить дополнительный контекст, я пытаюсь создать события (на основе бизнес-правил) при опросе созданных и обновленных объектов из внешнего модульного API, который является моим единственным интерфейсом в реляционной базе данных, где находятся данные. Это само по себе готовое приложение, поэтому я не могу его изменить, реализация должна происходить после того, как я использую API. Какие варианты у меня есть, чтобы сохранить этот simple? - person ugotchi; 19.11.2019
comment
т.е. есть ли у меня какие-либо другие варианты, помимо необходимости хранить все объекты, для создания событий на основе изменений, в случае, если мне нужно создать событие на основе конкретных изменений в объекте (например, изменение поля состояния с от ожидающего до принятого), когда API только сообщает мне, что сущность в целом была обновлена. - person ugotchi; 19.11.2019
comment
О, мой ответ касается приложения, которое само хранит данные. Я не думаю, что вышеизложенное легко применимо, если вы работаете за его пределами. Вариант опроса имеет большой недостаток — не существует правильной частоты опроса: слишком частый создаст большую нагрузку на оба приложения, слишком редкий — пропустит промежуточные изменения. Если вы размещаете это приложение, возможно, вы можете рассмотреть возможность прослушивания базового журнала фиксации БД или перехвата изменений в другом месте (например, прослушивания HTTP-запросов), при условии, что ваша лицензия для этого приложения позволяет это. Недостаток этого решения: оно очень хрупкое. - person Timur; 19.11.2019

arrow_upward
3
arrow_downward

Взгляните на шаблон наблюдателя и шаблон итератора, а также в парадигме реактивное программирование.

Обратите внимание, что это довольно общие подходы к обработке изменений состояния (или событий). Реализация зависит от языка программирования и операционной среды, которую вы используете. Вам действительно следует искать существующие фреймворки и библиотеки, такие как ReactiveX (кроссплатформенный) или Spring WebFlux (Java).

Вот интересное обсуждение взаимосвязи между концепции.

person Gerd    schedule 13.11.2019