Avro: нормально ли избегать общих схем между производителями и потребителями?

Question

Некоторая хорошо зарекомендовавшая себя система обмена сообщениями (независимо от того, какая именно) используется в качестве «клея для параллелизма» между многочисленными небольшими и независимыми (микро) сервисами.

Таким образом, есть определенное место, где сообщения создаются и потребляются.

Я пробую Avro как двоичный формат, и его Schema s беспокоит меня: Я не хочу поддерживать глобальный запас фактических Schema s, мне бы хотелось, чтобы мои потребители предполагают, что некоторые свойства существуют, и если нет, просто зарегистрируйте такое сообщение как «плохо отформатированное» и немедленно переключитесь на следующее . Это подразумевает следующее: производитель (и) будут производить с использованием одного Schema, а потребитель будет использовать с использованием другого Schema, который, конечно, будет иметь некоторые свойства, , вероятно, в другом порядке . Могу ли я достичь этого с помощью Avro или я неправильно его использую?

Answer 1

http://martin.kleppmann.com/2012/12/05/schema-evolution-in-avro-protocol-buffers-thrift.html:

Единственный способ проанализировать эти двоичные данные [Avro] - это прочитать их вместе со схемой, и схема скажет вам, какой тип ожидать следующего. У вас должна быть та же версия схемы, что и у автора используемых данных. Если у вас неправильная схема, парсер не сможет сделать заголовок или хвост двоичных данных.

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