Микросервисы и состояние публикации против государственных изменений

Question

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

• все свое состояние
• только свои изменения в состоянии

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

 t0  | [ ]
------------------
 t1  | [X,  Y]
------------------
 t2  | [X', Y]
------------------
 t3  | [X', Y, Z]
------------------
 t4  | [X',    Z]

Он может публиковать каждый из этих снимков своего текущего состояния (правый столбец) или может публиковать только такие изменения, как

-----------------------
 delta(t0, t1)| +X, +Y
-----------------------
 delta(t1, t2)| X->X'
-----------------------
 delta(t2, t3)| +Z
-----------------------
 delta(t3, t4)| -Y

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

• Опубликованные события потребляются в правильном порядке
• Опубликованные события, которые "пропущены" службой, должны быть распознаны икаким-то образом компенсированы за
• В алгоритме дельты нет ошибки

, тогда как если опубликовано все состояние, то

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

Несколько решений, которые я могу придумать, чтобы сделать дельта-подход немного более надежным, добавить много сложности:

• Опубликовать оба изменения и все состояние и указатель на предыдущее событие.Службы, использующие событие, могут выяснить, обрабатывать ли дельту или весь набор данных.
• «Цикл» между публикацией дельт и полным состоянием.Может быть, публиковать изменения 9/10 раз, а затем все состояние в 1/10 раз, чтобы помочь исправить вещи.

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

Answer 1

Третий вариант заключается в том, что опубликованные события не содержат информации о состоянии, а потребитель событий несет ответственность за получение состояния от производителя.Событие может содержать обратный вызов производителя и / или идентификатор для данных, которые изменились.

Конечно, наименее сложное и наименее эффективное решение для потребителя - слепо извлекать данные у производителя по расписанию..

Answer 2

Это действительно хороший вопрос.Семантика публикации дельт - это, по сути, то, что придумано архитектурой, управляемой событиями, если вы хотите продолжить чтение.

Основным преимуществом, которое дают вам события (дельты, по вашему определению), является прозрачность.События небольшие и ограниченные, так как они определяют что-то, что произошло с вашей системой, и отслеживаются.Если вам нужно захватить другое поведение, вы можете добавить тип события.Хотя с изменениями состояния, ему не хватает прозрачности относительно того, что произошло;вам, вероятно, придется вернуться ко всем различным состояниям и выяснить, что произошло, и если они вышли из строя, может быть трудно рассуждать.

Также по следующим пунктам:

Отслеживание дельт

В алгоритме дельта нет ошибки

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

Отслеживание состояний

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

Что, если служба, ответственная за изменение состояния, имеет ошибку и обновляет запись до недопустимого состояния?Публикация того же 3-го состояния будет отражать постоянную ошибку в последующих системах, которые зависят от изменения состояния.Использование событий здесь разъединяет эти две семантики, по сути, состояние и то, что произошло.