Megfontolandó szempontok az üzenetek kódolása kapcsán

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 a hasznos adatok 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 hasznos adatait meghatározó alakzat vagy struktúra.
• A hasznos adatnak megfelelő kódolási formátum.
• Szerializálási kódtá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. Fontolja meg: Mi a leghatékonyabb adattípus? A hasznos adatoknak mindig vannak bizonyos mezői? A hasznos adatnak egyetlen rekordja vagy ismétlődő értékkészlete lesz?

Ezután válasszon egy kódolási formátumot az igényeinek megfelelően. Bizonyos tényezők közé tartozik a magas 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 hasznos adatok elemzése. 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ó végén a fogyasztó deszerializálja a hasznos adatokat az adatok használatához. Így mindkét entitás megosztja a modellt, és amíg az alakzat nem változik, az üzenetkezelés problémamentesen folytatódik. A szerződés módosításakor a kódolási formátumnak képesnek kell lennie a módosítás kezelésére a fogyasztó feltörése 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én előfordulhat, hogy az adatok nem elemezhetők olyan könnyen, 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 hibakeresést és küldést végezhetnek a naplókba a hibaelhárítási hibák elhárításához.

A hátránya az, hogy a hasznos adatok általában nagyobbak. Gyakori szövegalapú formátum a JSON.

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 inaktív adatainak 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ítani, és szeretné csökkenteni a felhőköltségeket, fontolja meg egy olyan kódtár használatát, mint az 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őnyeit és hátrányait ebben a szakaszban ismertetjük.

A hátránya, hogy a hasznos adatok nem olvashatók. 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 hasznos adatok ismerteté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ók, mivel az értékek szótárába elemezhetők 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. A gyártó például JSON-ban küld hasznos adatokat. A fogyasztó egy szótárba elemzi a JSON-t, és ellenőrzi a mezők meglétét a hasznos adatok 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 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/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 kapja meg a hasznos adatokat. 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 hasznos adatok 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. Előfordulhat, hogy jelentősen megnő az üzenetek mérete, és hatással lehet a tárolási költségekre.

Séma verziószámozása

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 a hasznos adatok között. Rekordsorozat vagy különálló egyetlen hasznos adat? A hasznos adatstruktúra 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, a hasznos adatok túl redundánsak lehetnek, ami miatt a hasznos adatok felbomlhatnak.

• 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 preambuluma hasonló a CSV-fejléchez, de kompakt kódolási méretet hoz létre.

Kódtár támogatása

Érdemes lehet jól ismert formátumokat használni 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 a kódtárak által biztosított API-tervezési lehetőségek némelyikén kell dolgoznia.

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.

Együttműködési lehetőség

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

Példa:

• Az Azure Stream Analytics natív támogatást nyújt a JSON, a CSV és az Avro számára. A Stream Analytics használata esetén célszerű ezek közül a formátumok közül választani, ha lehetséges. Ha nem, egyéni deszerializálót is megadhat, de ez további összetettséggel bővíti a megoldást.

• 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, nem pedig újrakódolni 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 lesznek, 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

A JSON egy 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 használható a metaadatok címkézéséhez, és séma nélkül elemezheti a hasznos adatokat. 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 a gyorsítótárazott elemeket közvetlenül egy ügyfélnek http-en 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 szerializálhatja a 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 a bináris JSON (BSON), amely a MongoDB-vel való együttműködéshez igazított bináris kódolás.

Vesszővel tagolt é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)

A protokollpufferek (vagy protobuf) olyan szerializálási formátumok, amelyek erősen gépelt definíciós fájlokat használnak a kulcs/érték párok sémáinak 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 a hasznos adatok nem olvashatók. Mivel a séma külső, nem ajánlott olyan esetekben, amikor archivált adatokat kell lekérnie.

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

MessagePack

A MessagePack egy olyan bináris szerializálási formátum, amely kellőképpen kis méretű a hálózaton keresztüli átvitelhez. A MessagePack nem alkalmaz üzenetsémákat vagy üzenettípus-ellenőrzést. Ez a formátum nem ajánlott tömeges tároláshoz.

CBOR

A tömör bináris objektumábrázolás (CBOR) (specifikáció) egy 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

• A felhőalkalmazások üzenetkezelési tervezési mintáinak megismerése.