Разъединение модели данных / схемы в конвейере обработки данных с использованием архитектуры на основе событий

Question

Мне было интересно, как микросервисы в потоковом конвейере, основанном на архитектуре, управляемой событиями, могут быть действительно отделены с точки зрения модели данных.Мы реализовали конвейер обработки данных с использованием Event-Driven Architecture, где модель данных очень важна.Хотя все микросервисы не связаны между собой с точки зрения бизнеса, в действительности они не отделены, поскольку модель данных используется всеми службами.

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

Есть ли какое-либо решение или технология, которые действительно могут развязать микросервисы в этом сценарии?

Answer 1

Эта проблема решается путем тщательного проектирования модели данных для обеспечения обратной и прямой совместимости.Такой дизайн важен для независимого развития сервисов, непрерывного обновления и т. Д. Модель данных считается обратно совместимой, если новый клиент (с использованием новой модели) может считывать / записывать данные, записанные другим клиентом (с использованием старой модели).Точно так же прямая совместимость означает, что клиент (используя старую модель данных) может читать / записывать данные, записанные другим клиентом (используя новую модель данных).

Скажем, в Person объект распределяется между службами вJSON кодированный формат.Теперь одна из служб вводит новое поле alternateContact.Служба, использующая эти данные и использующая старую модель данных, может просто проигнорировать это новое поле и продолжить свою работу.Если вы используете библиотеку Джексона, вы бы использовали @JsonIgnoreProperties(ignoreUnknown = true).Таким образом, потребительский сервис предназначен для прямой совместимости.

Проблема возникает, когда служба (используя старую модель данных) десериализует данные Person, записанные с новой моделью, обновляет одно или несколько значений поля и записывает данные обратно.Поскольку неизвестные свойства игнорируются, запись приведет к потере данных.

К счастью, формат двоичного кодирования, такой как Protocol Buffer 3.5 и более поздние версии, сохраняет неизвестные поля во время десериализации с использованием старой модели.Таким образом, когда вы сериализуете данные обратно, новые поля остаются как есть.

Там, возможно, другие эволюции модели данных, вам нужно иметь дело с такими, как удаление полей, переименование полей и т. Д. Основная идея заключается в том, что вы должны знатьи планировать эти возможности на ранней стадии разработки.Распространенными форматами кодирования данных являются JSON, Apache Thrift, Protocol Buffer, Avro и т. Д.