Ajánlott eljárások az üzenetkódoláshoz

Számos felhőalkalmazás aszinkron üzeneteket használ a rendszer összetevői közötti információk cseréjére. Az üzenetkezelés egyik fontos eleme az üzenet terhelési adatainak kódolásához használt formátum. Miután kiválasztott egy üzenetkezelési technológiát, a következő lépés az üzenetek kódolásának meghatározása. Számos lehetőség áll rendelkezésre, de a megfelelő választás a használati esettől függ.

Ez a cikk néhány szempontot ismertet.

Üzenetváltási igények

Üzenetváltás egy gyártó és egy fogyasztó igényei között:

• Az üzenet terhelését meghatározó alakzat vagy struktúra.
• A teher ábrázolására szolgáló kódolási formátum.
• Szerializálási könyvtárak a kódolt hasznos adatok olvasásához és írásához.

Az üzenet készítője az üzleti logika és a fogyasztóknak küldeni kívánt információk alapján határozza meg az üzenetalakzatot. Az alakzat strukturálásához ossza fel az információt különálló vagy kapcsolódó témákra (vagy mezőkre). A mezők értékeinek jellemzőinek meghatározása. Fontolja meg a következő kérdéseket.

• Mi a leghatékonyabb adattípus?
• A rakománynak mindig vannak meghatározott mezői?
• A payload egyetlen rekorddal vagy ismétlődő értékkészlettel rendelkezik?

Ezután válasszon egy kódolási formátumot az igényeinek megfelelően. Bizonyos tényezők közé tartozik, ha szükséges, a nagyon strukturált adatok létrehozásának képessége, az üzenet kódolásához és átviteléhez szükséges idő, valamint a payload elemzése. Ezután válasszon egy, az igényeinek megfelelő kódolási formátumot.

A fogyasztónak tisztában kell lennie a bejövő üzenetek helyes olvasásával kapcsolatos döntésekkel.

Az üzenetek átviteléhez a gyártó kódolási formátumba szerializálja az üzenetet. A vevő oldalon a fogyasztó deszerializálja a csomagot az adatok eléréséhez. Ez a folyamat biztosítja, hogy mindkét entitás ugyanazt a modellt használja. Amíg az alakzat változatlan marad, az üzenetkezelés problémamentesen folytatódik. Amikor a szerződés megváltozik, a kódolási formátumnak képesnek kell lennie kezelni a változást a fogyasztó zavarása nélkül.

Egyes kódolási formátumok, például a JSON önleírók, ami azt jelenti, hogy sémahivatkozás nélkül elemezhetők. Ezek a formátumok azonban gyakran nagyobb üzeneteket hoznak létre. Előfordulhat, hogy más formátumok nem elemzik olyan könnyen az adatokat, de tömörebb üzeneteket eredményeznek. Ez a cikk a fontos tényezőket ismerteti, amelyek segítenek a megfelelő formátum kiválasztásában.

Kódolási formátummal kapcsolatos szempontok

A kódolási formátum határozza meg, hogyan jelenik meg bájtként a strukturált adatok halmaza. Az üzenet típusa befolyásolhatja a formátum kiválasztását. Az üzleti tranzakciókhoz kapcsolódó üzenetek nagy valószínűséggel magas strukturált adatokat tartalmaznak. Emellett érdemes lehet később lekérni a strukturált adatokat naplózási célból. Egy eseményfolyam esetében érdemes lehet a lehető leggyorsabban beolvasni egy rekordsorozatot, és statisztikai elemzés céljából tárolni.

A kódolási formátum kiválasztásakor vegye figyelembe az alábbi tényezőket.

Emberi olvashatóság

Az üzenetkódolás nagyjából szöveges és bináris formátumokra osztható.

A szöveges kódolással az üzenet hasznos adatai egyszerű szövegben jelennek meg, így egy személy kódtárak használata nélkül is megvizsgálhatja. Ez a megközelítés megkönnyíti az adatok olvasását és megértését. Az ember által olvasható formátumok alkalmasak archiválási adatok tárolására. Mivel egy ember el tudja olvasni a hasznos adatokat, a szöveges formátumok könnyebben hibakereshetők és naplózhatók a hibaelhárítás miatt.

A szövegalapú kódolás hátránya, hogy a hasznos teher általában nagyobb. Az adatteher mérete gyakran csökkenthető egy kicsinyítési folyamat során, feltéve hogy szükség esetén visszaállítható emberi olvasásra. Gyakori szövegalapú formátumok a JSON és a YAML.

Titkosítás

Ha bizalmas adatok találhatók az üzenetekben, fontolja meg, hogy ezek az üzenetek teljes egészében titkosítva legyenek-e. Másik lehetőségként, ha csak bizonyos mezőket kell titkosítani, és inkább a felhőköltségeket szeretné csökkenteni, fontolja meg egy olyan kódtár használatát, mint az NServiceBus.

Kódolási méret

Az üzenetméret hatással van a vezetéken keresztüli hálózati bemeneti/kimeneti teljesítményre. A bináris formátumok tömörebbek, mint a szöveges formátumok. A bináris formátumok szerializálási és deszerializálási kódtárakat igényelnek. A teher csak dekódolt állapotban olvasható.

Használjon bináris formátumot, ha csökkenteni szeretné a vezetékek lábnyomát, és gyorsabban szeretné továbbítani az üzeneteket. Ez a formátumkategória olyan helyzetekben ajánlott, ahol a tárolás vagy a hálózati sávszélesség aggodalomra ad okot. A bináris formátumok közé tartoznak az Apache Avro, a Google Protocol Buffers (protobuf), a MessagePack és a Concise Binary Object Representation (CBOR). Ezeknek a formátumoknak az előnyeit és hátrányait később a kódolási formátumok választási lehetőségei ismertetik.

A bináris formátum hátránya, hogy a payload nem ember számára olvasható. A legtöbb bináris formátum összetett rendszereket használ, amelyek fenntartása költséges lehet. Emellett speciális kódtárakra van szükségük a dekódoláshoz, amelyek nem feltétlenül támogatottak, ha archiválási adatokat szeretne lekérni.

A nem kötött formátumok esetében a minifikációs folyamat eltávolítja a szükségtelen szóközöket és karaktereket, miközben megőrzi a formátum specifikációjának való megfelelést. Ez a megközelítés segít csökkenteni a kódolás méretét a struktúra módosítása nélkül. Értékelje ki a kódoló képességeit, hogy a minification legyen az alapértelmezett. Például a .NET JsonSerializerOptions.WriteIndentedSystem.Text.Json.JsonSerializer vezérli az automatikus kicsinyítést, amikor JSON-szöveget hoz létre.

A terhelés megértése

Az üzenet hasznos adatai bájtok sorozataként érkeznek meg. A sorozat elemzéséhez a felhasználónak hozzá kell férnie a hasznos adatmezőket leíró metaadatokhoz. A metaadatok tárolásának és terjesztésének két fő megközelítése a következő:

Címkézett metaadatok. Egyes kódolási formátumokban, különösen a JSON-ban a mezők az üzenet törzsében lévő adattípussal és azonosítóval vannak megjelölve. Ezek a formátumok önleíró, mivel feldolgozhatók egy értékeket tartalmazó szótárba anélkül, hogy sémára hivatkoznának. A felhasználók számára a mezők megértésének egyik módja a várt értékek lekérdezése. Például a gyártó egy terhelést küld JSON formátumban. A fogyasztó egy szótárba elemzi a JSON-t, és ellenőrzi a mezők meglétét a payload megértéséhez. Egy másik módszer, ha a fogyasztó egy olyan adatmodellt alkalmaz, amelyet a gyártó oszt meg. Ha például statikusan gépelt nyelvet használ, számos JSON-szerializációs kódtár képes egy JSON-sztringet begépelt osztályba elemezni.

Séma. A séma formálisan meghatározza az üzenet struktúráját és adatmezőit. Ebben a modellben a gyártó és a fogyasztó egy jól meghatározott sémán keresztüli szerződéssel rendelkezik. A séma meghatározhatja az adattípusokat, a szükséges vagy választható mezőket, a verzióinformációkat és a hasznos adatok szerkezetét. A gyártó az adatterhelést az író séma szerint küldi el. A fogyasztó egy olvasóséma alkalmazásával megkapja az adatcsomagot. Az üzenet szerializálva és deszerializálva van a kódolásspecifikus kódtárak használatával. A sémák kétféleképpen terjeszthetők:

• Tárolja a sémát preambulumként vagy fejlécként az üzenetben, de a hasznos adatoktól elkülönítve.

• Tárolja a sémát külsőleg.

Egyes kódolási formátumok határozzák meg a sémát, és olyan eszközöket használnak, amelyek osztályokat hoznak létre a sémából. A gyártó és a fogyasztó ezeket az osztályokat és kódtárakat használja a terhelés szerializálására és deszerializálására. A kódtárak kompatibilitási ellenőrzéseket is biztosítanak az író és az olvasó sémája között. Ezt a megközelítést a protobuf és az Apache Avro is követi. A fő különbség az, hogy a protobuf nyelv-agnosztikus sémadefinícióval rendelkezik, és az Avro kompakt JSON-t használ. A másik különbség az, hogy mindkét formátum kompatibilitási ellenőrzéseket biztosít az olvasói és az írói sémák között.

A séma külső tárolásának másik módja a sémaregisztrációs adatbázis. Az üzenet a sémára és az adatcsomagra mutató hivatkozást tartalmaz. A gyártó elküldi a sémaazonosítót az üzenetben. A fogyasztó úgy kéri le a sémát, hogy megadja az azonosítót egy külső tárolóból. Mindkét fél formátumspecifikus kódtárat használ az üzenetek olvasásához és írásához. A séma tárolása mellett a beállításjegyzék kompatibilitási ellenőrzéseket is képes biztosítani annak érdekében, hogy a gyártó és a fogyasztó közötti szerződés ne szakadjon meg a séma fejlődésével.

Mielőtt kiválaszt egy módszert, döntse el, hogy az adatátviteli adatméret vagy az archivált adatok későbbi elemzése fontosabb-e.

A séma és a hasznos adatok tárolása nagyobb kódolási méretet eredményez, és ideális az időszakos üzenetekhez. Ezt a módszert akkor válassza, ha a kisebb bájttömbök átvitele kulcsfontosságú, vagy rekordsorozatra számít. A külső sématárolók karbantartásának költsége magas lehet.

Ha azonban a hasznos adatok igény szerinti dekódolása fontosabb, mint a méret, beleértve a hasznos adatokat tartalmazó sémát vagy a címkézett metaadat-megközelítést, akkor a rendszer ezt követően is garantálja a dekódolást. Az üzenetek méretének jelentős növekedése hatással lehet a tárolási költségekre.

Séma verziókezelése

Az üzleti követelmények változásával az alakzat várhatóan megváltozik, és a séma fejlődik. A verziószámozás lehetővé teszi, hogy a gyártó jelezze az új funkciókat tartalmazó sémafrissítéseket. A verziószámozásnak két fő aspektusa van:

• A fogyasztónak nyomon kell követnie és ismernie kell a változásokat.

  Ennek egyik módja, hogy a fogyasztó az összes mezőt ellenőrzi annak megállapításához, hogy a séma módosult-e. Egy másik módszer, ha a gyártó közzétesz egy sémaverziószámot az üzenettel. Amikor a séma fejlődik, a gyártó növeli a verziót.

• A módosítások nem befolyásolhatják vagy nem szeghetik meg a fogyasztók üzleti logikáját.

  Tegyük fel, hogy egy mező hozzáadódik egy meglévő sémához. Ha az új verziót használó felhasználók a régi verziónak megfelelően kapnak hasznos adatokat, a logikájuk megszakadhat, ha nem hagyhatják figyelmen kívül az új mező hiányát. Most vegye figyelembe az ellenkező forgatókönyvet. Ha egy mező el lett távolítva az új sémából, előfordulhat, hogy a régi sémát használó felhasználók nem tudják olvasni az adatokat.

  Az olyan kódolási formátumok, mint az Avro, lehetővé teszik az alapértelmezett értékek meghatározását. Az előző példában, ha a mező alapértelmezett értékkel van hozzáadva, a hiányzó mező az alapértelmezett értékkel lesz feltöltve. Más formátumok, például a protobuf hasonló funkciókat biztosítanak a szükséges és választható mezőkön keresztül.

Hasznos adatstruktúra

Fontolja meg, hogy a hasznos adatok rekordsorozatként vagy egyetlen különálló hasznos adatként legyenek-e strukturálva. A terhelési struktúra az alábbi modellek egyikébe sorolható:

• Tömb/szótár/érték: Olyan bejegyzéseket határoz meg, amelyek egy vagy többdimenziós tömbökben tárolnak értékeket. A bejegyzések egyedi kulcs/érték párokkal rendelkeznek. A modell kiterjeszthető összetett struktúrák megjelenítésére. Ilyen például a JSON, az Apache Avro és a MessagePack.

  Ez az elrendezés akkor megfelelő, ha az üzenetek külön-külön vannak kódolva különböző sémákkal. Ha több rekordja van, az adatcsomag túl redundánssá válhat. Ez a redundancia a teher felduzzadását okozhatja.

• Táblázatos adatok: Az információk sorokra és oszlopokra vannak osztva. Minden oszlop egy mezőt vagy az információ tárgyát jelzi, és minden sor az adott mezők értékeit tartalmazza. Ez az elrendezés hatékony az ismétlődő információhalmazok, például az idősoradatok esetében.

  A vesszővel elválasztott értékek (CSV) egy egyszerű szövegalapú formátum. Az adatokat egy közös fejlécet tartalmazó rekordsorozatként jeleníti meg. Bináris kódolás esetén az Apache Avro rendelkezik egy, a CSV-fejléchez hasonló preambulumsal, amely azonban kompaktabb kódolási méretet eredményez.

Könyvtár támogatása

A védett modell helyett jól ismert formátumokat kell használnia. A jól ismert formátumokat a közösség által általánosan támogatott kódtárak támogatják. Speciális formátumok esetében speciális kódtárakra van szükség. Előfordulhat, hogy az üzleti logikának meg kell kerülnie a kódtárak által biztosított bizonyos API-tervezési lehetőségeket.

Sémaalapú formátum esetén válasszon egy kódolási kódtárat, amely kompatibilitási ellenőrzéseket végez az olvasó és az író séma között. Bizonyos kódolási kódtárak, például az Apache Avro, elvárják, hogy a fogyasztó az üzenet deszerializálása előtt adja meg az írót és az olvasó sémát is. Ez az ellenőrzés biztosítja, hogy a fogyasztó tisztában legyen a sémaverziókkal.

Interoperabilitás

A formátumok kiválasztása az adott számítási feladattól vagy technológiai ökoszisztémától függhet.

Például:

• Az Azure Stream Analytics natív támogatást nyújt a JSON, a CSV és az Avro számára. Amikor a számítási feladat Stream Analytics-et használ, érdemes választania ezek közül a formátumok közül.

• A JSON a HTTP REST API-k szabványos felcserélődési formátuma. Ha az alkalmazás JSON-hasznos adatokat kap az ügyfelektől, majd azokat egy üzenetsorba helyezi aszinkron feldolgozás céljából, érdemes lehet JSON-t használni az üzenetkezeléshez ahelyett, hogy újrakódolást használna egy másik formátumba.

Ez csupán két példa az együttműködési szempontokra. A szabványosított formátumok általában több interoperábilisak, mint az egyéni formátumok. A szövegalapú beállításokban a JSON az egyik leginkább együttműködő.

A kódolási formátumok lehetőségei

Az alábbi népszerű kódolási formátumokat használják az adatmegjelenításhoz és -átvitelhez. A formátum kiválasztása előtt vegye figyelembe a szempontokat.

JSON

A JSON egy nyílt szabvány, amelynek formátumát az Internet Engineering Task Force (IETF) határozza meg az RFC 8259-ben. A JSON egy szövegalapú formátum, amely a tömb-/szótár-/értékmodellt követi.

A JSON használható a metaadatok címkézésére, és a terhelés elemzéséhez nincs szükség sémára. A JSON támogatja a választható mezők megadását, ami segít az előre és a hátrafelé kompatibilitásban is.

A legnagyobb előnye, hogy univerzálisan elérhető. A JSON a leginkább együttműködő kódolási formátum, és számos üzenetkezelési szolgáltatás alapértelmezett formátuma.

Mivel a JSON szövegalapú formátum, nem hatékony a vezetéken, és nem ideális, ha a tárolás aggodalomra ad okot. Ha lehetséges, használjon minification technikákat. Ha a gyorsítótárazott elemeket közvetlenül egy ügyfélnek HTTP-en keresztül adja vissza, akkor a JSON tárolása megtakaríthatja a költséget azáltal, hogy elkerüli a deszerializálást egy másik formátumból, majd a szerializálást JSON-ra.

JSON használata egyrekordos üzenetekhez vagy olyan üzenetek sorozatához, amelyekben minden üzenet más sémával rendelkezik. Ne használjon JSON-t rekordok sorozatához, például idősoradatokhoz.

A JSON más változatai is léteznek, például bináris JSON (BSON). A BSON a MongoDB-vel való együttműködéshez igazított bináris kódolás.

CSV

A CSV szövegalapú táblázatos formátum. A tábla fejléce a mezőket jelöli. A CSV kiválóan alkalmas rekordok készletét tartalmazó üzenetekre.

A CSV hátránya a szabványosítás hiánya. Az elválasztókat, fejléceket és üres mezőket többféleképpen is kifejezheti.

Protokollpufferek

protokollpufferek (vagy protobuf) olyan szerializálási formátum, amely erősen gépelt definíciós fájlokat használ a sémák kulcs/érték párokban való definiálásához. Ezeket a definíciófájlokat ezután lefordítjuk az üzenetek szerializálására és deszerializálására használt nyelvspecifikus osztályokra.

Az üzenet egy kis méretű, tömörített bináris hasznos adatot tartalmaz, amely gyorsabb adatátvitelt eredményez. Ennek az a hátránya, hogy a hasznos teher nem ember által olvasható. Mivel a séma külsőleg van tárolva, ez a formátum nem ideális olyan forgatókönyvekhez, amelyekhez archivált adatok lekérésére van szükség.

Apache Avro

Az Apache Avro egy bináris szerializálási formátum, amely a protobufhoz hasonló definíciós fájlt használ, de fordítási lépés nélkül. Ehelyett a szerializált adatok mindig tartalmazzák a séma preambulumát.

A preambulum tartalmazhatja a fejlécet vagy a sémaazonosítót. Kisebb kódolási mérete miatt az Avro ajánlott streamelési adatokhoz. Mivel egy rekordkészletre vonatkozó fejléce is van, jól használható táblázatos adatokhoz.

Apache Parquet

Apache Parquet egy oszlopos tárolási fájlformátum, amely általában az Apache Hadoophoz és a kapcsolódó adatfeldolgozási keretrendszerekhez van társítva.

Az Apache Parquet támogatja az adattömörítést, és korlátozott képességekkel rendelkezik a sémafejlődéshez. Ezt a formátumot általában akkor használják, ha a számítási feladat egyéb big data technológiái megkövetelik az adatlétrehozáshoz vagy -felhasználáshoz.

MessagePack

A MessagePack egy bináris szerializálási formátum, amelyet úgy terveztek, hogy kompakt legyen a vezetéken keresztüli átvitelhez. A MessagePack nem rendelkezik sémadefinícióval és típusellenőrzéssel. Ez a formátum nem ajánlott tömeges tároláshoz.

CBOR

A CBOR (Specification) egy bináris formátum, amely kis kódolási méretet biztosít. A CBOR használatának előnye a MessagePack-kel szemben az, hogy megfelel az IETF RFC7049 szabványnak.

Következő lépések

• Azure Service Bus-üzenetek, hasznos adatok és szerializálás
• A válaszok tömörítése az ASP.NET Core-ban