Vlákno názorů k článku Komunikace realizovaná binárním formátem MessagePack (dokončení) od atarist - Takže když například posíláme vyšší desítky až stovky...
-
Takže když například posíláme vyšší desítky až stovky zpráv za sec. přes Kafku (dneska je to JSON), a všechny komunikující strany jsou +- synchronizovaný, co se týká vlastností, má smysl použít tyto samopopisný formáty, nebo jít přímo do Protobufferu? U druhého řešení se bojím právě té synchronizace, kdy by se povýšení verzí jedné nebo druhé strany muselo koordinovat (když se změní formát zprávy).
-
S Protobuffererem se dá pracovat tak, aby byl dopředně kompatibilní, tedy když mi přijde zpráva ve schématu o verzi vyšším, než kterou mám já, tak ji i tak dokážu přečíst. Takže to koordinování by nemuselo být až tak hrozné.
Co se týče výkonnosti, tak stovky zpráv za sekundu asi nebudou výkonnostním problémem, leda kdyby byly v YAMLu :)
-
protobuf je striktně přírustkový formát. Správný postup při evoluci schématu je tedy nejprve udělat deployment nové definice s novými fieldy a až je všude (aplikace, schema registry atd.) tak teprve začít v něm propagovat nová data. Poté je v kafce vše čitelné i roky zpětně, řeší se tím elegantně problém s skákáním v historii.
Nemůžeš-li zachovat přírustkový systém nebo potřebuješ-li mít extra definici pro každou položku, vyhni se protobufu a raději použíj cokoliv jiného (json, bson, messagepack, avro, capnproto atd.).
Samopopisný formáty jsou super, ale stejně potřebuješ v delším horizontu zajistit nějakou stabilitu a spolehlivost, pak to vše padá na tom, že vlastně netušíš, co ti do aplikace leze a jak se s tím vypořádá. Ve spojení s kafkou, která neumí zprávy přeskočit, ale musíš vše zkonzumovat to přináší zajímavé problémy.
-
Dík. My samozřejmě máme schémata + každý JSON obsahuje verzi schématu, ovšem to v praxi neřeší servicy, který už stará schémata neumí. V našem konkrétním případě to není až takový problém, protože retention policy je v řádu dnů, ale ten "mezistav" při povýšení formátu by mohl být kritický, jak píšeš.
-
z praxe mi vychází velice vhodně nedělat v kafce trunk topicy, kam rvu vše a střídím podle schématu, ale striktně držet topic per schéma, poté mi i odpadá problém s upgardem, prostě nové zprávy jsou v novém topicu, staré ve starém.
Tohle ale není všemocné, přenáší to problém na aplikaci, ta si musí řešit deduplikaci sama a sama si musí projít přepnutím topicu.
Každá zpráva v kafce implikuje určitý kontrakt, který má zdrojový systém vůči samotné zprávě a stejně tak by se mělo dbát na popis struktury. Je strašně odlehčující, když můžeš všechny struktury popsat jediným protobuf dokumentem, který časem pouze roste a roste a umíš s ním validovat veškeré zprávy v kafce kamkoliv do historie. Vyhneš se tím složitým algoritmům uvnitř consumeru, který tu logiku musí řešit, tím i zjednoduššíš validaci, přepis consumeru atd. Schema registry je za mě poměrně solidní antipatern, který jde proti hygieně a kontraktům, porušují se tím odpovědnosti systémů a přenáší problémy do budoucna.
