Osvědčené postupy pro kódování zpráv

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:

• 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ého datového obsahu.

Producent zprávy definuje tvar zprávy na základě obchodní logiky a informací, které chce odeslat příjemcům. Chcete-li strukturovat obrazec, rozdělte informace na samostatné nebo související předměty (nebo pole). Rozhodněte vlastnosti hodnot pro tato pole. Zvažte následující otázky.

• Jaký je nejúčinnější datový typ?
• Má datová část vždy určitá pole?
• Obsahuje datová část jeden záznam nebo opakovanou sadu hodnot?

V závislosti na vašich potřebách zvolte formát kódování. Mezi konkrétní 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. Pak zvolte formát kódování, který vyhovuje vašim potřebám.

Spotřebitel musí těmto rozhodnutím rozumět, aby správně četl příchozí zprávy.

Pro přenos zpráv producent serializuje zprávu do formátu kódování. Na straně příjemce uživatel deserializuje zatížení, aby získal přístup k datům. Tento proces zajišťuje, aby obě entity sdílely stejný model. Dokud obrazec zůstane beze změny, 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 samostatně, což znamená, že je lze analyzovat bez odkazování na schéma. Tyto formáty ale často vytvářejí větší zprávy. Jiné formáty nemusí data tak snadno analyzovat, ale výsledkem jsou kompaktnější zprávy. Tento článek popisuje klíčové faktory, které vám pomůžou zvolit správný 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 výběr formátu. Zprávy související s obchodními transakcemi s největší pravděpodobností obsahují vysoce strukturovaná data. Pro účely auditování můžete také později chtít načíst strukturovaná data. 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.

Při výběru formátu kódování zvažte následující faktory.

Č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, takže ji osoba může zkontrolovat bez použití knihoven kódu. Tento přístup usnadňuje čtení a pochopení dat. Formáty čitelné pro člověka jsou vhodné pro archivaci dat. Vzhledem k tomu, že člověk může datovou část číst, textové formáty se snadněji ladí a odesílají do protokolů pro řešení chyb.

Nevýhodou kódování založeného na textu je, že datová část má tendenci být větší. Velikost datové části lze často snížit prostřednictvím procesu minifikace, pokud je možné ji v případě potřeby vrátit zpět pro čitelnost člověka. Běžné textové formáty jsou JSON a YAML.

Šifrování

Pokud jsou ve zprávách citlivá data, zvažte, jestli by se tyto zprávy měly šifrovat v celé jejich výši. Případně pokud je potřeba šifrovat jenom konkrétní 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 síťového vstupu a výstupu v rámci přenosu. Binární formáty jsou kompaktnější než textové formáty. Binární formáty vyžadují serializaci a deserializační knihovny. Datovou část je možné číst pouze při dekódování.

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 dále v části Volby pro formáty kódování.

Nevýhodou binárního formátu 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.

V případě nebinárních formátů proces minifikace odebere nepotřebné mezery a znaky při zachování souladu se specifikací formátu. Tento přístup pomáhá zmenšit velikost kódování beze změny struktury. Vyhodnoťte možnosti kodéru a proveďte minifikaci jako výchozí. Například JsonSerializerOptions.WriteIndented z .NET System.Text.Json.JsonSerializer řídí automatickou minifikaci při vytváření JSON textu.

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

Datový obsah zprávy 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. Mezi dva hlavní přístupy pro ukládání a distribuci metadat patří:

Označené metadata V některých formátech kódování, 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, který výrobce sdílí. 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á nebo volitelná pole, informace o verzi a strukturu datové části. Výrobce odešle datovou část podle zapisovacího schématu. Příjemce obdrží datovou část použitím schématu čtenáře. Zpráva je serializována a deserializována pomocí knihoven specifických pro kódování. Schémata je možné distribuovat dvěma způsoby:

• Uložte schéma jako preambuli nebo záhlaví zprávy, ale odděleně 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 a 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.

Jiný způsob, jak uložit schéma externě, je v registru schématu. Zpráva obsahuje referenci na schéma a datovou část. Producent odešle identifikátor schématu ve zprávě. Spotřebitel načte schéma zadáním toho 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, jestli je přenosová velikost dat nebo možnost parsovat archivovaná data později důležitější.

Uložení schématu spolu s datovou částí vytváří větší velikost kódování a je ideální pro přerušované zprávy. 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, která ovlivňuje 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 vyvíjí. Správa verzí umožňuje producentovi indikovat aktualizace schématu, které můžou zahrnovat nové funkce. Správa verzí má dva klíčové aspekty:

• Uživatel by měl sledovat a rozumět změnám.

  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, získají náklad podle staré verze, může se jejich logika zhroutit, pokud nebudou schopni přehlédnout nedostatek nového pole. Nyní zvažte opačný scénář. Pokud je pole odebráno v novém schématu, uživatelé, kteří používají staré schéma, nemusí být schopni číst data.

  Formáty kódování, jako je Avro, poskytují 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, jestli jsou data v datové části strukturovaná jako posloupnost záznamů nebo jako samostatná datová část. Strukturu zatížení je možné kategorizovat do jednoho z následujících modelů:

• Matice,slovník/hodnota: Definuje položky, které obsahují hodnoty v jednom nebo multidimenzionálním poli. Položky mají jedinečné páry klíč/hodnota. Model lze rozšířit tak, aby představoval složité struktury. Mezi příklady patří JSON, Apache Avro a MessagePack.

  Toto rozložení je vhodné, pokud jsou zprávy jednotlivě kódovány s různými schématy. Pokud máte více záznamů, datová část může být nadměrně redundantní. Tato redundance může způsobit zvětšení datového obsahu.

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

  Comma-Separated Hodnoty ve formátu CSV jsou jedním z nejjednodušších textových formátů. Zobrazuje data jako posloupnost záznamů se společným záhlavím. Pro binární kódování má Apache Avro preambuli, která se podobá hlavičce CSV, ale generuje kompaktnější velikost kódování.

Podpora knihoven

Místo proprietárního modelu byste měli používat dobře známé formáty. Známé formáty jsou podporovány prostřednictvím knihoven, které komunita obecně podporuje. 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. Konkrétní kódovací knihovny, jako je Apache Avro, očekávají, že příjemce před deserializací zprávy zadá schéma zapisovače i čtenáře. 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. Když vaše úloha používá Stream Analytics, je vhodné zvolit jeden z těchto formátů.

• 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 být vhodné místo opětovného kódování do jiného formátu použít JSON pro zasílání zpráv.

Jedná se pouze o dva příklady aspektů interoperability. Standardizované formáty jsou obecně 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í

Pro reprezentaci a přenos dat se používají následující oblíbené formáty 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 s jeho formátem definovaným Internet Engineering Task Force (IETF) v RFC 8259. JSON je 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 parsovat bez schématu. JSON podporuje možnost zadat volitelná pole, která pomáhají s dopředu i zpětnou kompatibilitou.

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

Vzhledem k tomu, že JSON je textový formát, není efektivní přes drát a není ideální, pokud je úložiště problém. Pokud je to možné, použijte techniky minifikace. Pokud vrátíte položky uložené v mezipaměti přímo klientovi prostřednictvím protokolu HTTP, může uložení formátu JSON ušetřit náklady na deserializaci z jiného formátu a následnou serializaci 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). BSON je binární kódování odpovídající práci s MongoDB.

formát CSV

CSV je textový tabulkový formát. Záhlaví tabulky označuje pole. CSV je vhodný pro zprávy, které obsahují sadu záznamů.

Nevýhodou formátu CSV je nedostatek standardizace. Existují různé způsoby vyjádření oddělovačů, záhlaví a prázdných polí.

Vyrovnávací paměti protokolu

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 malou komprimovanou binární datovou část, což vede k rychlejšímu přenosu dat. Nevýhodou je, že datová zátěž není čitelná člověkem. Vzhledem k tomu, že schéma je uloženo externě, není tento formát ideální pro scénáře, které vyžadují načtení archivovaných dat.

Apache Avro

Apache Avro je binární serializační formát, který používá definiční soubor podobný protobuf, ale bez kroku 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 vhodná pro tabulková data.

Apache Parquet

Apache Parquet je formát sloupcového úložiště obvykle přidružený k Apache Hadoopu a souvisejícím architekturám pro zpracování dat.

Apache Parquet podporuje kompresi dat a má omezené možnosti pro vývoj schématu. Tento formát se obvykle používá, když jiné technologie pro velké objemy dat ve vaší úloze vyžadují jejich vytvoření nebo spotřebu.

MessagePack

MessagePack je binární serializační formát, který je navržený tak, aby byl kompaktní pro přenos přes drát. MessagePack nemá definici schématu a kontrolu typů. Tento formát se nedoporučuje pro hromadné úložiště.

CBOR

CBOR (Specification) je binární formát, který poskytuje malou velikost kódování. Výhodou použití CBOR přes MessagePack je jeho dodržování IETF v RFC7049.

Další kroky

• zpráv, datových částí a serializace služby Azure Service Bus
• Komprese odpovědí v ASP.NET Core