Sdílet prostřednictvím

Důležité informace o 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. Jakmile zvolíte technologii zasílání zpráv, dalším krokem je 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:

  • Tvar nebo struktura, která definuje nosič dat 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 místě příjmu příjemce deserializuje datovou část, aby mohl použít 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 vyhledat pro auditorské účely. 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 payload 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 raději 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 datový objem a přenášet zprávy 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, Google Protocol Buffers (protobuf), MessagePack a Concise Binary Object Representation (CBOR). Výhody a nevýhody těchto formátů jsou popsány v Tento oddíl.

Nevýhodou je, že zásilka není čitelná pro lidi. 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.

Pochopení užitečného zatížení

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 sebepopisující, protože je lze analyzovat do slovníku hodnot, aniž by bylo třeba odkazovat na schéma. Jedním ze způsobů, jak spotřebitel může porozumět polím, je dotazování na očekávané hodnoty. Producent například odešle datovou část ve formátu JSON. Uživatel parsuje JSON do slovníku a kontroluje existenci polí, aby porozuměl datovému obsahu. 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 zapisování a čtení. Protobuf i Apache Avro následují tento přístup. 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ž její velikost, zahrnutí schématu s datovou částí nebo použití přístupu označených metadat zaručuje následné dekódování. 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é, kteří používají novou verzi, obdrží datovou část podle staré verze, může jejich logika selhat, pokud nebudou schopni ignorovat absenci 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 užitečného zatížení

Zvažte, jak jsou data uspořádána v datovém bloku. 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 obsahují 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í a nafouknout se.

  • 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čí jak schéma pro zápis, tak schéma pro čtení. Tato kontrola zajistí, že příjemce bude znát verze schématu.

Interoperabilita

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

Napří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 poskytnout vlastní deserializátor, ale tím přidáte určitou složitost vašemu řešení.

  • 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.

Jako textový formát není efektivní pro přenos přes síť a není ideální volbou v případech, kdy je třeba šetřit místem. 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í i jiné varianty JSON, jako je binárníJSON (BSON), což je binární kódování, které je zarovnané pro práci s MongoDB.

hodnoty Comma-Separated (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í.

Protocol Buffers (protobuf)

Protocol Buffers (nebo protobuf) je formát serializace, který používá silně typové definiční soubory k definování schémat v 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 užitečný náklad není čitelný pro člověka. 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 tak, aby byl kompaktní pro přenos přes drát. Neexistují žádná schémata zpráv ani kontrola typu zprávy. Tento formát se nedoporučuje pro hromadné úložiště.

CBOR

Concise Binary Object Representation (CBOR) (specifikace) 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.