Üzenetek, hasznos adatforgalom és szerializáció

  • Cikk

Az Azure Service Bus kezeli az üzeneteket. Az üzenetek hasznos adatokat és metaadatokat hordoznak. A metaadatok kulcs-érték párok formájában találhatók, és ismertetik a hasznos adatokat, és kezelési utasításokat adnak a Service Busnak és az alkalmazásoknak. Időnként ez a metaadatok elegendőek a feladó által a fogadókkal kommunikálni kívánt információk hordozásához, és a hasznos adatok üresek maradnak.

A .NET-hez és Java-hoz készült hivatalos Service Bus-ügyfelek objektummodellje az absztrakt Service Bus-üzenetstruktúrát tükrözi, amely a Service Bus által támogatott vezetékes protokollokra van leképezve.

A Service Bus-üzenetek egy bináris hasznos adatszakaszból állnak, amelyet a Service Bus soha nem kezel semmilyen formában a szolgáltatás oldalán, és két tulajdonságkészletből. A közvetítő tulajdonságait a rendszer előre definiálja. Ezek az előre definiált tulajdonságok vagy az üzenetszintű funkciókat vezérli a közvetítőn belül, vagy általános és szabványosított metaadatelemekre vannak leképezve. A felhasználói tulajdonságok kulcs-érték párok gyűjteményei, amelyeket az alkalmazás definiálhat és állíthat be.

Az előre definiált közvetítőtulajdonságok az alábbi táblázatban találhatók. A nevek az összes hivatalos ügyfél API-ban és a HTTP protokollleképezés BrokerProperties JSON objektumában is használatosak.

Az AMQP protokoll szintjén használt egyenértékű nevek zárójelben jelennek meg. Bár a következő nevek pascal burkolatot használnak, vegye figyelembe, hogy a JavaScript- és Python-ügyfelek teve- és kígyóházat használnak.

Tulajdonság neve Leírás
ContentType (tartalomtípus) Opcionálisan az üzenet hasznos adatait írja le egy leíróval, amely a RFC2045 5. szakaszának formátumát követi; például application/json.
CorrelationId (korrelációs azonosító) Lehetővé teszi, hogy egy alkalmazás kontextust adjon meg az üzenethez korreláció céljából; például egy megválaszolt üzenet Üzenetazonosítóját tükrözi.
DeadLetterSource Csak azokat az üzeneteket adja meg, amelyeket a kézbesítetlen levelek üzenetsorából később automatikusan egy másik entitásnak ítélnek oda. Azt az entitást jelzi, amelyben az üzenet elhalt betűs volt. Ez a tulajdonság írásvédett.
DeliveryCount

Az üzenethez megkísérelt kézbesítések száma. A szám növekszik, ha egy üzenet zárolása lejár, vagy a fogadó explicit módon megszakítja az üzenetet. Ez a tulajdonság írásvédett.

A kézbesítések száma nem növekszik a mögöttes AMQP-kapcsolat bezárásakor.
EnqueuedSequenceNumber Az automatikusan odaítélt üzenetek esetében ez a tulajdonság azt a sorszámot tükrözi, amelyet először hozzárendeltek az üzenethez az eredeti beküldési ponton. Ez a tulajdonság írásvédett.
EnqueuedTimeUtc Az az UTC-pillanat, amelyen az üzenetet elfogadták és tárolták az entitásban. Ez az érték mérvadó és semleges érkezési időjelzőként használható, ha a fogadó nem szeretne megbízni a feladó órájában. Ez a tulajdonság írásvédett.
Expires​AtUtc (abszolút lejárati idő) Az az UTC-pillanat, amelyen az üzenet eltávolításra van megjelölve, és a lejárata miatt már nem érhető el az entitásból való lekérésre. A lejáratot a TimeToLive tulajdonság szabályozza, és ezt a tulajdonságot az EnqueuedTimeUtc+TimeToLive függvényből számítja ki. Ez a tulajdonság írásvédett.
Label vagy Subject (tárgy) Ez a tulajdonság lehetővé teszi, hogy az alkalmazás szabványosított módon jelezze az üzenet célját a fogadónak, hasonlóan az e-mail tárgysorához.
Locked​Until​Utc A zárolás alatt (betekintő-zárolás fogadási mód, nem előre beállított) lekért üzenetek esetében ez a tulajdonság azt az UTC-pillanatot tükrözi, amíg az üzenet zárolva nem lesz az üzenetsorban/előfizetésben. Amikor a zárolás lejár, a DeliveryCount növekszik, és az üzenet ismét elérhető lesz a lekéréshez. Ez a tulajdonság írásvédett.
Lock​Token A zárolási jogkivonat egy hivatkozás arra a zárolásra, amelyet a közvetítő a betekintő-zárolás fogadási módban tart. A jogkivonat használatával véglegesen rögzítheti a zárolást a Halasztás API-val, és ezzel kiveheti az üzenetet a normál kézbesítési állapotból. Ez a tulajdonság írásvédett.
Message​Id (üzenetazonosító) Az üzenetazonosító egy alkalmazás által definiált érték, amely egyedileg azonosítja az üzenetet és a hasznos adatokat. Az azonosító egy szabad formátumú sztring, amely az alkalmazáskörnyezetből származó GUID-t vagy azonosítót tükrözhet. Ha engedélyezve van, az ismétlődő észlelési funkció azonos MessageId azonosítóval azonosítja és eltávolítja az üzenetek második és további elküldéseit.
Partition​Key Particionált entitások esetén ez az érték lehetővé teszi a kapcsolódó üzenetek hozzárendelését ugyanahhoz a belső partícióhoz, hogy a küldési sorrend helyesen legyen rögzítve. A partíciót egy kivonatfüggvény választja ki ezen az értéken keresztül, és nem lehet közvetlenül kiválasztani. Munkamenet-tudatos entitások esetén a SessionId tulajdonság felülírja ezt az értéket.
Reply​To (válasz) Ez az opcionális és alkalmazás által definiált érték szabványos módszer az üzenet fogadójának válaszútvonalának kifejezésére. Amikor a feladó választ vár, az értéket annak az üzenetsornak vagy témakörnek az abszolút vagy relatív elérési útjára állítja be, amelyre a válasz elküldése várható.
Reply​To​Session​Id (válasz-csoportazonosító) Ez az érték kibővíti a Válaszadat-adatokat , és meghatározza, hogy a válasz entitásnak küldött válaszhoz melyik SessionId legyen beállítva.
Scheduled​Enqueue​Time​Utc Az olyan üzenetek esetében, amelyek csak késleltetett lekérésre lettek elérhetővé téve, ez a tulajdonság határozza meg azt az UTC-pillanatot, amelynél az üzenet logikailag lekérdezhető, sorrendbe rendezve lesz, és így lekérésre elérhetővé válik.
Sequence​Number A sorszám egy egyedi, 64 bites egész szám, amely egy üzenethez van rendelve, mivel a közvetítő elfogadja és tárolja, és valódi azonosítóként működik. Particionált entitások esetén a legfelső 16 bit a partícióazonosítót tükrözi. A sorszámok monoton módon növekednek, és hézagmentesek. A 48–64 bites tartomány kimerülése esetén 0-ra gördülnek. Ez a tulajdonság írásvédett.
Session​Id (csoportazonosító) A munkamenet-tudatos entitások esetében ez az alkalmazás által definiált érték határozza meg az üzenet munkamenet-kapcsolatát. Az azonos munkamenet-azonosítóval rendelkező üzenetekre összefoglaló zárolás vonatkozik, és lehetővé teszik a pontos sorrendben történő feldolgozást és a demultiplexinget. Az olyan entitások esetében, amelyek nem munkamenet-tudatosak, a rendszer figyelmen kívül hagyja ezt az értéket.
Time​To​Live Ez az érték a relatív időtartam, amely után az üzenet lejár, attól a pillanattól kezdve, amikor a közvetítő elfogadta és tárolta az EnqueueTimeUtc-ban rögzített módon. Ha nincs explicit módon beállítva, a feltételezett érték a megfelelő üzenetsor vagy témakör DefaultTimeToLive értéke. Az üzenetszintű TimeToLive érték nem lehet hosszabb az entitás DefaultTimeToLive beállításánál. Ha hosszabb, csendesen be van állítva.
To (to) Ez a tulajdonság az útválasztási forgatókönyvekben való jövőbeli használatra van fenntartva, és jelenleg maga a közvetítő figyelmen kívül hagyja. Az alkalmazások ezt az értéket szabályalapú automatikus láncolásos forgatókönyvekben használhatják az üzenet kívánt logikai célhelyének jelzésére.
Via​Partition​Key Ha egy tranzakció hatókörében egy átviteli üzenetsoron keresztül küld üzenetet, ez az érték kiválasztja az átviteli várólista partícióját.

Az absztrakt üzenetmodell lehetővé teszi az üzenet üzenetsorba való közzétételét HTTPS-en keresztül, és az AMQP-n keresztül is lekérhető. Az üzenet mindkét esetben normálnak tűnik az adott protokoll kontextusában. A rendszer szükség szerint lefordítja a közvetítő tulajdonságait, és a felhasználói tulajdonságok a megfelelő helyre vannak leképezve a megfelelő protokollüzenet-modellben. A HTTP-ben a felhasználói tulajdonságok közvetlenül a HTTP-fejlécek felé és onnan származnak; az AMQP-ben az alkalmazástulajdonságok térképére és onnan vannak leképelve.

Üzenet útválasztása és korrelációja

A korábban ismertetett közvetítőtulajdonságok egy részhalmaza, konkrétan To, ReplyTo, ReplyToSessionId, MessageIdCorrelationIdés SessionId, az üzenetek adott célhelyekre való átirányításának elősegítésére szolgál. A funkció szemléltetéséhez fontolja meg néhány mintát:

  • Egyszerű kérés/válasz: A közzétevő üzenetet küld egy üzenetsorba, és választ vár az üzenet fogyasztójától. A válasz fogadásához a közzétevőnek van egy üzenetsora, amelybe a válaszok kézbesítését várja. Az üzenetsor címe a kimenő üzenet Választo tulajdonságában van kifejezve. Amikor a fogyasztó válaszol, átmásolja a kezelt üzenet MessageId azonosítóját a válaszüzenet Korrelációs azonosító tulajdonságába, és elküldi az üzenetet a Választulajdonság által megjelölt célhelyre. Egy üzenet az alkalmazás környezetétől függően több választ is adhat.
  • Csoportos küldési kérés/válasz: A korábbi minta változataként a közzétevő elküldi az üzenetet egy témakörbe, és több előfizető is jogosulttá válik az üzenet használatára. Az egyes előfizetők a korábban ismertetett módon válaszolhatnak. Ezt a mintát felderítési vagy roll-call forgatókönyvekben használják, és a válaszadó általában egy felhasználói tulajdonsággal vagy a hasznos adaton belül azonosítja magát. Ha a ReplyTo egy témakörre mutat, a felderítési válaszok ilyen készlete terjeszthető a közönség számára.
  • Multiplexing: Ez a munkamenet-funkció lehetővé teszi a kapcsolódó üzenetek streamjeinek multiplexálását egyetlen üzenetsoron vagy előfizetésen keresztül, így a kapcsolódó üzenetek minden munkamenetét (vagy csoportját) a rendszer egy adott fogadóhoz irányítja, miközben a fogadó zárolva tartja a munkamenetet. A munkamenetek részleteiről itt olvashat bővebben.
  • Multiplexed request/reply: Ez a munkamenet-funkció lehetővé teszi a multiplexált válaszokat, így több közzétevő is megoszthat egy válaszsort. A ReplyToSessionId beállításával a közzétevő utasíthatja a fogyasztó(ka)t, hogy másolja ezt az értéket a válaszüzenet SessionId tulajdonságába. A közzétételi üzenetsornak vagy a témakörnek nem kell munkamenet-tudatosnak lennie. Az üzenet elküldésekor a közzétevő kifejezetten megvárhatja az adott SessionId azonosítóval rendelkező munkamenetet, hogy egy munkamenet fogadójának feltételes elfogadásával megvalósuljon az üzenetsoron.

A Service Bus-névtéren belüli útválasztás automatikus láncolással és témakör-előfizetési szabályokkal valósítható meg. A névterek közötti útválasztás az Azure LogicApps használatával valósítható meg. Ahogy az előző listában is látható, a To tulajdonság jövőbeli használatra van fenntartva, és a közvetítő végül egy speciálisan engedélyezett funkcióval értelmezheti. Az útválasztást implementálni kívánó alkalmazásoknak a felhasználói tulajdonságok alapján kell ezt megtennie, és nem a To tulajdonságra kell támaszkodnia, azonban ez most nem okoz kompatibilitási problémákat.

Hasznos adatok szerializálása

Amikor a Service Buson belül vannak tárolva, a hasznos adatok mindig átlátszatlan bináris blokkok. A ContentType tulajdonság lehetővé teszi az alkalmazások számára a hasznos adatok leírását, a tulajdonságértékek javasolt formátuma például az IETF RFC2045 szerinti MIME-tartalomtípus leírása, application/json;charset=utf-8például.

A Java vagy a .NET Standard változatoktól eltérően a Service Bus API .NET-keretrendszer verziója támogatja a BrokeredMessage-példányok létrehozását úgy, hogy tetszőleges .NET-objektumokat ad át a konstruktornak.

2026. szeptember 30-án kivonjuk az Azure Service Bus SDK-kódtárakat a WindowsAzure.ServiceBus, a Microsoft.Azure.ServiceBus és a com.microsoft.azure.servicebus kódtárakból, amelyek nem felelnek meg az Azure SDK irányelveinek. Az SBMP protokoll támogatását is megszüntetjük, így 2026. szeptember 30. után már nem használhatja ezt a protokollt. Migrálás a legújabb Azure SDK-kódtárakba, amelyek kritikus fontosságú biztonsági frissítéseket és továbbfejlesztett képességeket kínálnak ezen dátum előtt.

Bár a régebbi kódtárak 2026. szeptember 30-tól továbbra is használhatók, a Microsoft már nem kap hivatalos támogatást és frissítéseket. További információkért lásd a támogatási nyugdíjazási bejelentést.

Az örökölt SBMP protokoll használata esetén a rendszer ezeket az objektumokat szerializálja az alapértelmezett bináris szerializálóval vagy egy külsőleg megadott szerializálóval. Az objektum AMQP-objektummá szerializálva van. A fogadó a GetBody<T>() metódussal lekérheti ezeket az objektumokat, és megadja a várt típust. Az AMQP használatával az objektumok AMQP-gráfjába ArrayList és IDictionary<string,object> objektumaiba szerializálódnak, és bármely AMQP-ügyfél dekódolhatja őket.

2026. szeptember 30-án megszüntetjük az Azure Service Bus SBMP protokolljának támogatását, így 2026. szeptember 30-tól már nem fogja tudni használni ezt a protokollt. Migrálás a legújabb Azure Service Bus SDK-kódtárakba az AMQP protokoll használatával, amely kritikus biztonsági frissítéseket és továbbfejlesztett képességeket kínál ezen dátum előtt.

További információkért lásd a támogatási nyugdíjazási bejelentést.

Bár ez a rejtett szerializálási varázslat kényelmes, az alkalmazásoknak explicit módon kell irányítaniuk az objektum szerializálását, és streamekké kell alakítaniuk az objektumgráfjaikat, mielőtt üzenetté alakítanák őket, és megfordítják a fogadó oldalán. Ez interoperábilis eredményeket eredményez. Bár az AMQP hatékony bináris kódolási modellel rendelkezik, az AMQP üzenetkezelési ökoszisztémához van kötve, és a HTTP-ügyfeleknek problémájuk lesz az ilyen hasznos adatok dekódolásával.

A .NET Standard és a Java API-változatok csak bájttömböket fogadnak el, ami azt jelenti, hogy az alkalmazásnak kezelnie kell az objektumszerializálási vezérlőt.

Ha egy üzenet hasznos adattartalma nem deszerializálható, akkor ajánlott az üzenet elhalt betűvel való megjelölése.

Következő lépések

A Service Bus üzenetkezelésével kapcsolatos további információkért tekintse meg az alábbi témaköröket: