Sdílet prostřednictvím

Aspekty kódování zpráv

  • Článek

Mnoho cloudových aplikací používá asynchronní zprávy k výměně informací mezi součástmi systému. Důležitým aspektem zasílání zpráv je formát, který se používá ke kódování dat datové části. Po výběru technologie zasílání zpráv je dalším krokem definování způsobu kódování zpráv. K dispozici je mnoho možností, ale správná volba závisí na vašem případu použití.

Tento článek popisuje některé aspekty.

Potřeby výměny zpráv

Výměna zpráv mezi producentem a spotřebitelem potřebuje:

  • Obrazec nebo struktura, která definuje datovou část zprávy.
  • Formát kódování, který představuje datovou část.
  • Knihovny serializace pro čtení a zápis zakódované datové části.

Producent zprávy definuje tvar zprávy na základě obchodní logiky a informací, které chce odeslat příjemcům. Pokud chcete obrazec strukturovat, rozdělte informace do samostatných nebo souvisejících subjektů (polí). Rozhodněte vlastnosti hodnot pro tato pole. Zvažte: Jaký je nejúčinnější datový typ? Bude datová část vždy obsahovat určitá pole? Bude datová část obsahovat jeden záznam nebo opakující se sadu hodnot?

Pak zvolte formát kódování podle toho, co potřebujete. Mezi určité faktory patří možnost vytvářet vysoce strukturovaná data, pokud je potřebujete, čas potřebný ke kódování a přenosu zprávy a možnost parsovat datovou část. V závislosti na formátu kódování zvolte knihovnu serializace, která je dobře podporovaná.

Spotřebitel zprávy si musí být vědom těchto rozhodnutí, aby věděl, jak číst příchozí zprávy.

Pro přenos zpráv producent serializuje zprávu do formátu kódování. Na konci příjmu příjemce deserializuje datovou část tak, aby používala data. Díky tomu obě entity sdílejí model a pokud se tvar nezmění, bude zasílání zpráv pokračovat bez problémů. Když se kontrakt změní, formát kódování by měl být schopný zpracovat změnu, aniž by došlo k narušení příjemce.

Některé formáty kódování, jako je JSON, jsou popsány vlastním popisem, což znamená, že je lze analyzovat bez odkazování na schéma. Takové formáty ale mají tendenci poskytovat větší zprávy. V jiných formátech nemusí být data analyzována tak snadno, ale zprávy jsou kompaktní. Tento článek popisuje některé faktory, které vám můžou pomoct vybrat formát.

Důležité informace o formátu kódování

Formát kódování definuje, jak je sada strukturovaných dat reprezentována jako bajty. Typ zprávy může ovlivnit volbu formátu. Zprávy související s obchodními transakcemi s největší pravděpodobností budou obsahovat vysoce strukturovaná data. Můžete ho také později načíst pro účely auditování. U datového proudu událostí můžete chtít co nejrychleji přečíst posloupnost záznamů a uložit ji pro statistickou analýzu.

Tady je několik bodů, které je potřeba zvážit při výběru formátu kódování.

Čitelnost člověka

Kódování zpráv lze široce rozdělit do textových a binárních formátů.

Při kódování založeném na textu je datová část zprávy ve formátu prostého textu, a proto ji může zkontrolovat osoba bez použití knihoven kódu. Formáty čitelné pro člověka jsou vhodné pro archivaci dat. Vzhledem k tomu, že člověk může datovou část číst, jsou textové formáty jednodušší ladit a odesílat do protokolů pro řešení chyb.

Nevýhodou je, že datová část má tendenci být větší. Běžným textovým formátem je JSON.

Šifrování

Pokud jsou ve zprávách citlivá data, zvažte, jestli by se tyto zprávy měly šifrovat v plném rozsahu, jak je popsáno v těchto doprovodných materiálech k šifrování neaktivních uložených dat služby Azure Service Bus. Případně pokud je potřeba zašifrovat jenom určitá pole a chcete snížit náklady na cloud, zvažte použití knihovny, jako je NServiceBus .

Velikost kódování

Velikost zprávy má vliv na výkon vstupně-výstupních operací sítě napříč drátem. Binární formáty jsou kompaktnější než textové formáty. Binární formáty vyžadují serializaci/deserializační knihovny. Datovou část nelze přečíst, pokud není dekódovaná.

Pokud chcete snížit nároky na přenos a přenos zpráv rychleji, použijte binární formát. Tato kategorie formátu se doporučuje ve scénářích, kdy je problém s úložištěm nebo šířkou pásma sítě. Mezi možnosti binárních formátů patří Apache Avro, Vyrovnávací paměti protokolu Google (protobuf), MessagePack a Stručná reprezentace binárních objektů (CBOR). Výhody a nevýhody těchto formátů jsou popsány v této části.

Nevýhodou je, že datová část není čitelná. Většina binárních formátů používá složité systémy, které mohou být nákladné na údržbu. Potřebují také specializované knihovny k dekódování, které nemusí být podporovány, pokud chcete načíst archivní data.

Principy datové části

Datová část zprávy se dorazí jako posloupnost bajtů. Aby příjemce mohl tuto sekvenci analyzovat, musí mít přístup k metadatům, která popisují datová pole v datové části. Existují dva hlavní přístupy k ukládání a distribuci metadat:

Označená metadata V některých kódováních, zejména JSON, jsou pole označená datovým typem a identifikátorem v textu zprávy. Tyto formáty jsou samostatně popisovány , protože je lze analyzovat do slovníku hodnot bez odkazování na schéma. Jedním ze způsobů, jak příjemce porozumět polím, je dotazování na očekávané hodnoty. Producent například odešle datovou část ve formátu JSON. Příjemce parsuje JSON do slovníku a kontroluje existenci polí, aby porozuměl datové části. Dalším způsobem je, aby spotřebitel použil datový model sdílený producentem. Pokud například používáte staticky zadaný jazyk, mnoho knihoven serializace JSON může analyzovat řetězec JSON do typové třídy.

Schéma. Schéma formálně definuje strukturu a datová pole zprávy. V tomto modelu má producent a spotřebitel smlouvu prostřednictvím dobře definovaného schématu. Schéma může definovat datové typy, povinná/volitelná pole, informace o verzi a strukturu datové části. Producent odešle datovou část podle schématu zapisovače. Příjemce obdrží datovou část použitím schématu čtenáře. Zpráva se serializuje nebo deserializuje pomocí knihoven specifických pro kódování. Existují dva způsoby distribuce schémat:

  • Uložte schéma jako preambuli nebo záhlaví zprávy, ale oddělte ho od datové části.

  • Uložte schéma externě.

Některé formáty kódování definují schéma a používají nástroje, které generují třídy ze schématu. Producent a spotřebitel tyto třídy a knihovny používají k serializaci a deserializaci datové části. Knihovny také poskytují kontroly kompatibility mezi schématem zapisovače a čtenáře. Tento přístup se řídí protobufem i Apache Avro. Klíčovým rozdílem je, že protobuf má definici schématu nezávislou na jazyce, ale Avro používá kompaktní JSON. Dalším rozdílem je způsob, jakým oba formáty poskytují kontroly kompatibility mezi schématy čtenáře a zapisovače.

Dalším způsobem, jak uložit schéma externě do registru schématu. Zpráva obsahuje odkaz na schéma a datovou část. Producent odešle identifikátor schématu ve zprávě a příjemce načte schéma zadáním daného identifikátoru z externího úložiště. Obě strany používají ke čtení a zápisu zpráv knihovnu specifickou pro formát. Kromě uložení schématu může registr poskytovat kontroly kompatibility, aby se zajistilo, že kontrakt mezi producentem a příjemcem není poškozený, protože se schéma vyvíjí.

Než zvolíte přístup, rozhodněte se, co je důležitější: velikost dat přenosu nebo možnost parsovat archivovaná data později.

Uložení schématu spolu s datovou částí přináší větší velikost kódování a dává přednost přerušovaným zprávám. Tento přístup zvolte, pokud je přenos menších bloků bajtů zásadní nebo očekáváte posloupnost záznamů. Náklady na údržbu externího úložiště schémat můžou být vysoké.

Pokud je dekódování datové části na vyžádání důležitější než velikost, včetně schématu s datovou částí nebo přístupu k označeným metadatům zaručuje dekódování později. Může dojít k významnému zvýšení velikosti zprávy a může mít vliv na náklady na úložiště.

Správa verzí schématu

Při změně obchodních požadavků se očekává, že se tvar změní a schéma se bude vyvíjet. Správa verzí umožňuje producentovi indikovat aktualizace schématu, které můžou zahrnovat nové funkce. Správa verzí má dva aspekty:

  • Spotřebitel by si měl být vědom změn.

    Jedním ze způsobů je, že příjemce zkontroluje všechna pole a určí, jestli se schéma změnilo. Dalším způsobem je, aby producent publikoval číslo verze schématu se zprávou. Když se schéma vyvíjí, producent zvýší verzi.

  • Změny nesmí ovlivnit ani narušit obchodní logiku spotřebitelů.

    Předpokládejme, že je pole přidáno do existujícího schématu. Pokud uživatelé používající novou verzi získají datovou část podle staré verze, může se jejich logika přerušit, pokud nebudou schopni přehlédnout nedostatek nového pole. Předpokládejme, že se v novém schématu odebere pole. Uživatelé, kteří používají staré schéma, nemusí být schopni číst data.

    Formáty kódování, jako je Avro, nabízejí možnost definovat výchozí hodnoty. Pokud je v předchozím příkladu přidáno pole s výchozí hodnotou, chybějící pole se naplní výchozí hodnotou. Jiné formáty, jako je protobuf, poskytují podobné funkce prostřednictvím povinných a volitelných polí.

Struktura datové části

Zvažte způsob uspořádání dat v datové části. Jedná se o posloupnost záznamů nebo samostatnou datovou část? Strukturu datové části je možné kategorizovat do jednoho z těchto modelů:

  • Array/dictionary/value: Definuje položky, které obsahují hodnoty v jednom nebo vícerozměrném poli. Položky mají jedinečné páry klíč-hodnota. Lze ji rozšířit tak, aby představovala složité struktury. Mezi příklady patří JSON, Apache Avro a MessagePack.

    Toto rozložení je vhodné, pokud jsou zprávy kódovány jednotlivými schématy. Pokud máte více záznamů, datová část může být nadměrně redundantní, což způsobí, že datová část bude blouděná.

  • Tabulková data: Informace jsou rozdělené na řádky a sloupce. Každý sloupec označuje pole nebo předmět informací a každý řádek obsahuje hodnoty pro tato pole. Toto rozložení je efektivní pro opakující se sadu informací, jako jsou data časových řad.

    CSV je jedním z nejjednodušších textových formátů. Zobrazuje data jako posloupnost záznamů se společným záhlavím. U binárního kódování má Apache Avro preambuli podobnou hlavičce CSV, ale generuje kompaktní velikost kódování.

Podpora knihoven

Zvažte použití známých formátů u proprietárního modelu.

Známé formáty jsou podporovány prostřednictvím knihoven, které jsou obecně podporovány komunitou. Ve specializovaných formátech potřebujete konkrétní knihovny. Vaše obchodní logika možná bude muset obejít některé z možností návrhu rozhraní API poskytovaných knihovnami.

Pro formát založený na schématu zvolte knihovnu kódování, která provádí kontroly kompatibility mezi schématem čtenáře a zapisovače. Některé kódovací knihovny, jako je Apache Avro, očekávají, že příjemce před deserializací zprávy určí zapisovač i schéma čtenáře. Tato kontrola zajistí, že příjemce bude znát verze schématu.

Vzájemná funkční spolupráce

Volba formátů může záviset na konkrétním ekosystému úloh nebo technologií.

Příklad:

  • Azure Stream Analytics má nativní podporu pro JSON, CSV a Avro. Pokud používáte Stream Analytics, je vhodné zvolit jeden z těchto formátů, pokud je to možné. Pokud ne, můžete zadat vlastní deserializátor, ale tím se řešení ještě více zkompiluje.

  • JSON je standardní formát výměny pro rozhraní HTTP REST API. Pokud vaše aplikace obdrží datové části JSON z klientů a pak je umístí do fronty zpráv pro asynchronní zpracování, může mít smysl použít JSON pro zasílání zpráv, a ne znovu zakódovat do jiného formátu.

Jedná se pouze o dva příklady aspektů interoperability. Obecně platí, že standardizované formáty budou interoperativnější než vlastní formáty. V textových možnostech je JSON jedním z nejvíce interoperabilních.

Volby pro formáty kódování

Tady je několik oblíbených formátů kódování. Než zvolíte formát, zvažte to, co je potřeba vzít v úvahu.

JSON

JSON je otevřený standard (IETF RFC8259). Jedná se o textový formát, který následuje za modelem pole, slovníku a hodnoty.

JSON se dá použít k označování metadat a datovou část můžete analyzovat bez schématu. JSON podporuje možnost zadat volitelná pole, která pomáhají s dopředu a zpětnou kompatibilitou.

Největší výhodou je, že je všeobecně dostupná. Je to nejoperabilní a výchozí formát kódování pro mnoho služeb zasílání zpráv.

Být textovým formátem, není efektivní přes drát a není ideální volbou v případech, kdy je úložiště problém. Pokud vracíte položky uložené v mezipaměti přímo klientovi prostřednictvím protokolu HTTP, ukládání JSON může ušetřit náklady na deserializaci z jiného formátu a pak serializovat do formátu JSON.

Použijte JSON pro zprávy s jedním záznamem nebo pro posloupnost zpráv, ve kterých má každá zpráva jiné schéma. Nepoužívejte JSON pro posloupnost záznamů, například pro data časových řad.

Existují další varianty JSON, jako je binární JSON (BSON), což je binární kódování, které je zarovnané pro práci s MongoDB.

Hodnoty oddělené čárkami (CSV)

CSV je textový tabulkový formát. Záhlaví tabulky označuje pole. Je to upřednostňovaná volba, ve které zpráva obsahuje sadu záznamů.

Nevýhodou je nedostatek standardizace. Existuje mnoho způsobů vyjádření oddělovačů, záhlaví a prázdných polí.

Vyrovnávací paměti protokolu (protobuf)

Vyrovnávací paměti protokolu (neboli protobuf) je formát serializace, který používá definiční soubory silného typu k definování schémat ve dvojicích klíč/hodnota. Tyto definiční soubory se pak kompilují do tříd specifických pro jazyk, které se používají pro serializaci a deserializaci zpráv.

Zpráva obsahuje komprimovanou binární malou datovou část, což je rychlejší přenos. Nevýhodou je, že datová část není čitelná. Vzhledem k tomu, že schéma je externí, nedoporučuje se také v případech, kdy potřebujete načíst archivovaná data.

Apache Avro

Apache Avro je binární serializační formát, který používá definiční soubor podobný protobuf, ale neexistuje krok kompilace. Místo toho serializovaná data vždy obsahují preambuli schématu.

Preambule může obsahovat hlavičku nebo identifikátor schématu. Kvůli menší velikosti kódování se pro streamovaná data doporučuje Avro. Protože má také hlavičku, která se vztahuje na sadu záznamů, je dobrou volbou pro tabulková data.

MessagePack

MessagePack je binární serializační formát, který je navržený pro kompaktní přenos linkou. Nevyužívá žádná schémata zpráv ani kontrolu typu zpráv. Tento formát se nedoporučuje pro hromadné úložiště.

CBOR

Stručná reprezentace binárního objektu (CBOR) (Specification) je binární formát, který nabízí malou velikost kódování. Výhodou CBOR oproti MessagePacku je, že je kompatibilní s IETF v RFC7049.

Další kroky