Üzenetkódolási szempontok

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 válasszon 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 (mezőkre). A mezők értékeinek jellemzőinek meghatározása. A következő kérdéseket kell megfontolnia.

• Mi a leghatékonyabb adattípus?
• A teher mindig tartalmaz bizonyos mezőket?
• 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 a magasan strukturált adatok létrehozása, ha szükséges, az üzenet kódolásához és átviteléhez szükséges idő, valamint a payload elemzésének képessége. A kódolási formátumtól függően válasszon egy jól támogatott szerializálási kódtárat.

Az üzenet fogyasztójának tisztában kell lennie ezekkel a döntésekkel, hogy tudja, hogyan kell olvasni a bejövő üzeneteket.

Az üzenetek átviteléhez a gyártó kódolási formátumba szerializálja az üzenetet. A fogadó oldalon a fogyasztó deszerializálja az adatcsomagot az adatok használatához szükséges módon. Így mindkét entitás megosztja a modellt, és amíg az alakzat nem változik, 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émára való hivatkozás nélkül elemezhetők. Az ilyen formátumok azonban általában nagyobb üzeneteket eredményeznek. Más formátumok esetében előfordulhat, hogy az adatok nem lesznek olyan könnyen elemezve, de az üzenetek tömörek. Ez a cikk néhány olyan tényezőt mutat be, amelyek segíthetnek a 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átumválasztást. 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 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.

Az alábbiakban néhány szempontot érdemes figyelembe venni a kódolási formátum kiválasztásakor.

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 vannak, ezért egy személy kódtárak használata nélkül is megvizsgálhatja. Az emberi olvasható formátumok alkalmasak archiválási adatok tárolására. Mivel az ember képes olvasni a hasznos adatokat, a szöveges formátumok könnyebben hibakereshetők és naplókba küldhetők a problémák elhárítása érdekében.

A hátránya az, hogy a hasznos teher általában nagyobb. A hasznos adatok mérete gyakran csökkenthető egy minifikációs folyamat során, feltéve, hogy szükség esetén megfordítható az emberi olvashatóság érdekében. Gyakori szövegalapú formátumok a JSON és a YAML.

Titkosítás

Ha bizalmas adatok találhatók az üzenetekben, fontolja meg, hogy ezeket az üzeneteket teljes egészében kell-e titkosítani az azure Service Bus-adatok inaktív titkosításáról szóló útmutatóban leírtak szerint,. Másik lehetőségként, ha csak bizonyos mezőket kell titkosítania, és szeretné csökkenteni a felhőköltségeket, fontolja meg egy olyan kódtár használatát, mint NServiceBus.

Kódolási méret

Az üzenet mérete hatással van a hálózati I/O teljesítményre a vezetéken keresztül. A bináris formátumok tömörebbek, mint a szöveges formátumok. A bináris formátumok szerializálási/deszerializálási kódtárakat igényelnek. A hasznos adat csak akkor olvasható, ha dekódolva van.

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őnyei és hátrányai leírásra kerülnek a Kódolási formátumok kiválasztási lehetőségeicímű részben.

A hátránya, hogy a teher nem ember által 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 bináris formátumok esetében a technikailag szükségtelen szóközök és karakterek eltávolítása, miközben a formátum specifikációjának megfelelő igazítás megmarad, segíthet a kódolási méret csökkentésében. Értékelje ki a kódoló képességeit, hogy a minification legyen az alapértelmezett. Például JsonSerializerOptions.WriteIndented a következőből: . A NET System.Text.Json.JsonSerializer szabályozza az automatikus minifikációt JSON-szöveg létrehozásakor.

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 van:

címkézett metaadatok. Egyes kódolásokban, 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, a gyártó által megosztott adatmodellt alkalmaz. Ha például statikusan beírt 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/választható mezőket, a verzióinformációkat és a hasznos adatok szerkezetét. A gyártó a hasznos adatokat az író sémájának megfelelően küldi el. A fogyasztó egy olvasóséma alkalmazásával megkapja az adatcsomagot. Az üzenet szerializálva/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 válassza el a hasznos adatokat.

• 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, de 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ázisban. Az üzenet a sémára és a hasznos adatokra mutató hivatkozást tartalmaz. A gyártó elküldi a sémaazonosítót az üzenetben, és a fogyasztó lekéri a sémát úgy, 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ásán kívül 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.

A megközelítés kiválasztása előtt döntse el, mi a fontosabb: az adatátviteli adatok mérete vagy az archivált adatok későbbi elemzése.

A séma és a hasznos adatok tárolása nagyobb kódolási méretet eredményez, és az időszakos üzenetek esetében ajánlott. 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ó fenntartá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érete jelentősen megnőhet, és 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ődni fog. 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 aspektusa van:

• A fogyasztónak tisztában kell lennie a változásokkal.

  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 hasznos adatokat kapnak a régi verziónak megfelelően, a logikájuk megszakadhat, ha nem tudják figyelmen kívül hagyni az új mező hiányát. A fordított esetet figyelembe véve tegyük fel, hogy egy mező el lesz 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 beolvasni az adatokat.

  Az olyan kódolási formátumok, mint az Avro, lehetővé teszi 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

Gondolja át, hogy az adatok hogyan vannak elrendezve az adatcsomagban. Rekordsorozat vagy egy önálló, egyedi hasznos adat? Az adatcsomag szerkezete az alábbi modellek egyikébe sorolható:

• Tömb/szótár/érték: Egy vagy többdimenziós tömbök értékeit tartalmazó bejegyzéseket definiál. A bejegyzések egyedi kulcs-érték párokkal rendelkeznek. Kiterjeszthető, hogy az összetett struktúrákat képviselje. Ilyen például a JSON, az Apache Avro és a MessagePack.

  Ez az elrendezés akkor megfelelő, ha az üzenetek különböző sémákkal vannak kódolva. Ha több rekordja van, az adattartalom túl redundáns lehet, ami miatt az adattartalom felduzzadhat.

• 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 jelöli, é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 CSV az egyik legegyszerűbb 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 egy preambulummal rendelkezik, ami hasonló a CSV-fejléchez, de az Avro kompakt kódolási méretet is eredményez.

Könyvtár támogatása

Jól ismert formátumokat kell használnia egy védett modellen keresztül. 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 az írót és az olvasó sémát is megadja. 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 fogad az ügyfelektől, majd ezeket egy üzenetsorba helyezi aszinkron feldolgozás céljából, érdemes lehet JSON-t használni az üzenetkezeléshez, ahelyett, hogy újrakódolna 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

Íme néhány népszerű kódolási formátum. A formátum kiválasztása előtt vegye figyelembe a szempontokat.

JSON

JSON nyílt szabvány (IETF RFC8259). Ez egy szövegalapú formátum, amely a tömb-/szótár-/értékmodellt követi.

A JSON-t lehet használni a metaadatok címkézésére, és a hasznos adatokat séma nélkül lehet elemezni. A JSON támogatja az opcionális mezők megadását, ami segít az előre és a hátra kompatibilitásban.

A legnagyobb előnye, hogy univerzálisan elérhető. Ez a legtöbb üzenetkezelési szolgáltatás esetében a legátjárhatóbb és alapértelmezett kódolási formátum.

Mivel szövegalapú formátum, nem hatékony a vezetéken, és nem ideális választás olyan esetekben, amikor 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-n keresztül adja vissza, a JSON tárolása megtakaríthatja a deszerializálás költségét egy másik formátumból, majd a JSON-ra szerializálás költségét.

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), amely a MongoDB-vel való együttműködéshez igazított bináris kódolás.

Comma-Separated értékek (CSV)

A CSV szövegalapú táblázatos formátum. A tábla fejléce a mezőket jelöli. Előnyben részesített választás, ha az üzenet rekordokat tartalmaz.

A hátránya a szabványosítás hiánya. Az elválasztók, fejlécek és üres mezők többféleképpen is kifejeződnek.

Protokollpufferek (protobuf)

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 tömörített bináris kis hasznos adatcsomagot tartalmaz, amely gyorsabb átvitelt eredményez. A hátránya az, hogy az adatcsomag nem ember által olvasható. Mivel a séma külső, nem ajánlott olyan esetekben, amikor archivált adatokat kell lekérnie.

Apache Avro

Apache Avro 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 nincs. Ehelyett a szerializált adatok mindig tartalmazzák a séma preambulumát.

A preambulum a fejlécet vagy a sémaazonosítót is tartalmazhatja. A kisebb kódolási méret miatt az Avro ajánlott streamelési adatokhoz. Mivel egy rekordkészletre vonatkozó fejléccel rendelkezik, a táblázatos adatokhoz is jó választás.

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.

A formátum támogatja az adattömörítést, és korlátozott képességekkel rendelkezik a sémafejlődés támogatására. Ez a formátum egy olyan példa, amelyet valószínűleg csak a számítási feladat egyéb big data-technológiai lehetőségeinek köszönhetően használhat, amelyek az adatok létrehozásáért vagy felhasználásáért lesznek felelősek.

MessagePack

MessagePack bináris szerializálási formátum, amely úgy van kialakítva, hogy kompakt legyen a vezetéken keresztüli átvitelhez. Nincsenek üzenetséma vagy üzenettípus-ellenőrzés. Ez a formátum nem ajánlott tömeges tároláshoz.

CBOR

tömör bináris objektumábrázolás (CBOR) (specifikáció) olyan bináris formátum, amely kis kódolási méretet kínál. A CBOR előnye a MessagePackkel szemben, hogy megfelel az IETF-nek RFC7049.

Következő lépések

• Azure Service Bus-üzenetek, hasznos adatok és szerializálási
• Választömörítés ASP.NET Core