Комментарии 4
ИМХО. Смотрели на эту телегу в качестве возможности использования на нашем проекте. Но… не зашло. Дисклеймер: я не принимал решение использовать или не использовать SR + avro в проекте, просто был одним из тех кто "смотрел" на SR + avro. Сразу скажу, что у меня стойкое отвращение ко всему, что выходит от конфлюентк, также как и от гуголь — все ведь помнят gwt или guava, ах это использование либы на 19 мб ради Strings и Lists — были времена, ну и частично от apache (camel, например). Меня прям тригерит когда я это вижу. Но это все моё личное мнение — оно может не совпадать с вашим и вы можете беспроблемно всем этим пользоваться.
Сначала пытались собрать и запустить SR из исходников — дзззззынь звоночек — не получилось (я не сомневаюсь, что у вас (читателей) получится). Запусками путем подмены либ в confluent platform, т.к. standalone SR отказался запускаться.
В проекте у нас используется karaf и соответственно нужно чтобы авро умел в бандлы — найн. Да я знаю есть либа servicemix bundle — но опять же проблемы с резолвом классов от авро в класслодыре бандла.
Окай — давай только для спринга — вроде запустился.
Но блииин, генерирование классов из текстовых файлов — спасибо я не голодный. А что например, если я хочу кастомные аннотации от того же validation? Где вот мне их указывать? Или мне нужно два отдельных класса для rest api и kafka?
Короче очень странное решение:
- avro не развивается (ага стабильная версия, которую вы смогли найти от 2017)
- если у вас проект на osgi то не факт, что запустится
- если это микросервисы — то, коммон, зачем? если можно использовать разные версии микросервисов для разных схем, и микрухи со старыми схемами просто отключать если на них не приходят события из кафки
- компактность данных — ну если у вас триллионы объектов для передачи по кафке — то да
- зачем вам логические типы внутри кафки, сериализации или дерсериализации? Если только для хранения bigdecimal с 2 знаками после запятой — то это можно сделать и через обычный сериализатор кафки.
Дисклеймер: являюсь автором самописной Schema Registry для Avro, ибо хранить и схемы, и сообщения в одной корзине показалось неуместным.
Фактически, основной use case для Schema Registry — историческая проверка совместимости схем. Мы очень старались натянуть сову на глобус и найти ей большее применение, но благодаря кодогенерации Java из Avro схемы и использованию FULL_TRANSITIVE режима совместимости (все схемы могут читать сообщения, записанные другими схемами в рамках одного субъекта) получилось так, что
- Есть кучка JARников со схемами полноcтью совместимыми друг с другом, соответственно, регистрация схем на лету не нужна (как в случае у автора, где они явно отключили регистрацию)
- Любое Java приложение может спокойно прочитать сообщение, используя эти JAR — соответственно и необходимость чтения схем на лету вызывает сомнения.
По вашим пунктам:
- Avro таки развивается — последний релиз был в декабре 2020. Автор сознательно выбрал поздний релиз из-за легаси.
- Я бы сказал что OSGi это отдельная боль, где при определённой сноровке можно сделать что необходимо.
- В микросервисах нельзя просто так взять и вырубить сервисы. В случае 1 версия сервиса = 1 конкретная версия схемы придётся выпускать багофиксы сразу для нескольких релизов параллельно, что есть боль.
- В любой системе обмена сообщениями количество траффика имеет значение. Если можно его уменьшить при помощи serde — это стоит сделать.
- Очень странный вопрос, так как это типичная кастомизация формата.
а при обновлении модели в первую очередь нужно обновлять консьюмеры
Никак не могу понять что это значит. Например если я удалил поле которые не использовалось консюмером. Что мне обновлять там? Или же имеется ввиду ристарт что бы новая сема подтянулась?
Прочитал только первый абзац и сразу возник вопрос: а чем плох кафка для связи между микросервисами? Не устраивает именно сама концепция очередей сообщений или претензии именно к Кафке? Какой вариант выбрали бы, будь такая возможность?
Как мы Schema Registry для Kafka настраивали, и что могло пойти не так…