Zprávy, zátěže a serializace

Azure Service Bus zpracovává zprávy. Zprávy obsahují datovou část a metadata. Metadata jsou ve formě párů klíč-hodnota. Popisuje datový náklad a poskytuje pokyny k jeho zpracování službou Service Bus a aplikacemi. Občas jsou metadata dostatečná k přenosu informací, které odesílatel chce sdělit příjemcům, takže datová část zůstane prázdná.

Objektový model oficiálního klienta Service Bus pro .NET a Javu odráží abstraktní strukturu zpráv service bus. Tato struktura se mapuje na drátové protokoly, které Service Bus podporuje.

Zpráva služby Service Bus se skládá z oddílu binární datové části, kterou Service Bus nikdy nezpracuje v žádném formuláři na straně služby, a dvě sady vlastností. Vlastnosti zprostředkovatele jsou předdefinovány systémem. Tyto předdefinované vlastnosti řídí funkce na úrovni zpráv uvnitř zprostředkovatele nebo se mapují na běžné a standardizované položky metadat. Vlastnosti uživatele jsou kolekce párů klíč-hodnota, které může aplikace definovat a nastavit.

Následující tabulka uvádí předdefinované vlastnosti zprostředkovatele. Všechna oficiální klientská rozhraní API používají tyto názvy. Objekt BrokerProperties JSON mapování protokolu HTTP také používá tyto názvy.

Ekvivalentní názvy používané na úrovni protokolu AMQP (Advanced Message Queuing Protocol) jsou uvedeny v závorkách. Zatímco následující názvy používají pascal casing, klienti v JavaScriptu a Pythonu používají camel a snake casing.

Název vlastnosti Popis
ContentType (content-type) Volitelně popisuje datovou část zprávy pomocí popisovače ve formátu z oddílu 5 dokumentu RFC2045; například application/json.
CorrelationId (correlation-id) Umožňuje aplikaci určit kontext zprávy pro účely korelace; Například reflektující ID zprávy , na kterou se odpovídá.
DeadLetterSource Pouze ve zprávách, které jsou odmítnuté a později automaticky přesměrované z fronty odmítnutých zpráv do jiné entity. Označuje entitu, ve které byla zpráva nedoručována. Tato vlastnost je pouze pro čtení.
DeliveryCount

Počet doručení, které se systém pokusil uskutečnit pro tuto zprávu. Počet se zvýší, když vyprší platnost zámku zprávy nebo příjemce zprávu explicitně opustí. Tato vlastnost je pouze pro čtení.

Po zavření základního připojení AMQP se počet doručení nezvýší.
EnqueuedSequenceNumber U zpráv, které systém automaticky překládá, tato vlastnost odráží pořadové číslo, které systém poprvé přiřadil ke zprávě v původním okamžiku odeslání. Tato vlastnost je pouze pro čtení.
EnqueuedTimeUtc Okamžik UTC, ve kterém je zpráva přijata a uložena v entitě. Tuto hodnotu použijte jako autoritativní a neutrální indikátor času doručení, pokud příjemce nechce důvěřovat hodině odesílatele. Tato vlastnost je pouze pro čtení.
Expires​AtUtc (absolute-expiry-time) Okamžik ve formátu UTC, ve kterém je zpráva označena k odstranění, a již není dostupná k získání z entity kvůli vypršení platnosti záznamu. Vypršení platnosti je řízeno vlastností TimeToLive. Systém vypočítá tuto vlastnost z EnqueuedTimeUtc+TimeToLive. Tato vlastnost je pouze pro čtení.
Label nebo Subject (subject) Tato vlastnost umožňuje aplikaci indikovat účel zprávy příjemci standardizovaným způsobem, podobně jako řádek předmětu e-mailu.
Locked​Until​Utc U zpráv načtených pod zámkem (režim příjmu s nahlédnutím a uzamčením, není předem potvrzeno) tato vlastnost odráží okamžik do UTC, dokud je zpráva uzamčena ve frontě nebo předplatném. Po vypršení platnosti zámku se hodnota DeliveryCount zvýší a zpráva bude opět k dispozici pro načtení. Tato vlastnost je pouze pro čtení.
Lock​Token Token zámku je referencí na zámek, který broker uchovává v režimu příjmu peek-lock. Pomocí tokenu můžete zámek trvale připnout prostřednictvím rozhraní API Deferral a tím zprávu vynechejte z běžného toku stavu doručení. Tato vlastnost je pouze pro čtení.
Message​Id (message-id) Identifikátor zprávy je hodnota definovaná aplikací, která jednoznačně identifikuje zprávu a její datovou část. Identifikátor je řetězec volného formuláře a může odrážet identifikátor GUID nebo identifikátor odvozený z kontextu aplikace. Pokud je tato možnost povolená, funkce detekce duplicit identifikuje a odebere druhé a další odeslání zpráv se stejným ID zprávy.
Partition​Key U dělených entit umožňuje nastavení této hodnoty přiřazení souvisejících zpráv ke stejnému internímu oddílu, aby bylo správně zaznamenáno pořadí odeslání. Oddíl je zvolen funkcí hash nad touto hodnotou a nelze ho vybrat přímo. U entit pracujících s relacemi vlastnost SessionId tuto hodnotu přepíše.
Reply​To (reply-to) Tato volitelná hodnota a hodnota definovaná aplikací je standardní způsob vyjádření cesty odpovědi příjemci zprávy. Když odesílatel očekává odpověď, nastaví hodnotu na absolutní nebo relativní cestu fronty nebo tématu, kam očekává, že bude odpověď odeslána.
Reply​To​Session​Id (reply-to-group-id) Tato hodnota rozšiřuje informace ReplyTo a určuje, které konkrétní Id relace se má nastavit pro odpověď při odeslání do entity odpovědi.
Scheduled​Enqueue​Time​Utc U zpráv, které jsou k dispozici pouze pro načtení po zpoždění, tato vlastnost definuje instanci UTC, ve které bude zpráva logicky zařazována, sekvencována a tudíž zpřístupněna pro načtení.
Sequence​Number Pořadové číslo je jedinečné 64bitové celé číslo přiřazené ke zprávě, protože zprostředkovatel ho přijímá a ukládá. Funguje jako skutečný identifikátor zprávy. U dělených entit nejvyšších 16 bitů představuje identifikátor oddílu. Pořadová čísla se monotonicky zvětšují a jsou bez mezer. Při vyčerpání 48-64bitového rozsahu se nastaví zpět na 0. Tato vlastnost je pouze pro čtení.
Session​Id (group-id) U entit citlivých na relace určuje tato aplikací definovaná hodnota spojení relace se zprávou. Zprávy se stejným identifikátorem relace podléhají souhrnnému uzamčení a umožňují přesné zpracování v pořadí a demultiplexování. U entit, které nejsou relace-schopné, je tato hodnota ignorována.
Time​To​Live Tato hodnota je relativní doba trvání, po které vyprší platnost zprávy, počínaje časem, kdy zprostředkovatel přijme a uloží zprávu, jak je zachyceno v enqueueTimeUtc. Pokud tuto hodnotu explicitně nenastavíte, systém použije DefaultTimeToLive pro příslušnou frontu nebo téma. Hodnota TimeToLive na úrovni zprávy nesmí být delší než výchozí nastavení DefaultTimeToLive pro danou entitu. Pokud je delší, systém ho bezobslužně upraví.
To (to) Tato vlastnost je vyhrazena pro budoucí použití ve scénářích směrování a zprostředkovatel ji v současné době ignoruje. Aplikace můžou tuto hodnotu použít ve scénářích automatického řetězení řízeného pravidlem k označení zamýšleného logického cíle zprávy.
Via​Partition​Key Pokud je zpráva odeslána prostřednictvím fronty pro přenos v rámci transakce, tato hodnota vybere oddíl této fronty.

Abstraktní model zpráv umožňuje odeslání zprávy do fronty prostřednictvím PROTOKOLU HTTPS a načtení prostřednictvím AMQP. V obou případech zpráva vypadá normálně v kontextu příslušného protokolu. Systém přeloží vlastnosti zprostředkovatele podle potřeby. Vlastnosti uživatele se mapují na nejvhodnější lokalizaci v příslušném modelu zpráv protokolu. V protokolu HTTP se vlastnosti uživatelů mapují přímo na hlavičky HTTP a z hlaviček HTTP. V AMQP se mapují z mapy a na mapu application-properties.

Směrování zpráv a korelace

Podmnožina vlastností zprostředkovatele popsaných výše, konkrétně To, ReplyTo, ReplyToSessionIdMessageId, CorrelationId, a SessionId, pomáhá aplikacím směrovat zprávy do konkrétních cílů. Pro ilustraci této funkce zvažte několik vzorů:

  • Jednoduchý požadavek/odpověď: Vydavatel odešle zprávu do fronty a očekává odpověď od příjemce zprávy. Pro přijetí odpovědi má vydavatel frontu, do které očekává doručení odpovědí. Adresa fronty je vyjádřena ve vlastnosti ReplyTo odchozí zprávy. Když příjemce odpoví, zkopíruje MessageId zpracovávané zprávy do vlastnosti CorrelationId zprávy odpovědi a doručí zprávu do cíle označeného vlastností ReplyTo. Jedna zpráva může v závislosti na kontextu aplikace přinést více odpovědí.
  • Žádost/odpověď vícesměrového vysílání: Jako varianta předchozího vzoru odešle vydavatel zprávu do tématu a více odběratelů může zprávu využívat. Každý z odběratelů může reagovat způsobem popsaným výše. Tento vzorec se používá v rámci scénáře zjišťování nebo svolávání účastníků a respondent se obvykle identifikuje pomocí vlastnosti uživatele nebo v rámci datového balíku. Pokud ReplyTo ukazuje na téma, může být taková sada odpovědí na zjišťování distribuována publiku.
  • Multiplexing: Tato funkce relace umožňuje multiplexování datových proudů souvisejících zpráv prostřednictvím jedné fronty nebo odběru, aby každá relace (nebo skupina) souvisejících zpráv identifikovaná odpovídajícími hodnotami SessionId byla směrována konkrétnímu příjemci, zatímco příjemce uchovává relaci pod zámkem. Další informace o relacích najdete tady.
  • Multiplexed request/reply: Tato funkce relace umožňuje multiplexované odpovědi, což umožňuje několika vydavatelům sdílet frontu odpovědí. Nastavením ReplyToSessionId může vydavatel dát příjemcům pokyn, aby tuto hodnotu zkopírovali do vlastnosti SessionId zprávy odpovědi. Fronta nebo téma publikování nemusí brát v potaz relace. Při odesílání zprávy pak vydavatel může konkrétně počkat na relaci s daným SessionId, aby se materializovala ve frontě tím, že podmíněně přijme příjemce relace.

Směrování uvnitř oboru názvů služby Service Bus lze realizovat pomocí pravidel automatického přeposílání a pravidel pro odběr témat. Směrování mezi obory názvů je možné realizovat pomocí Azure LogicApps. Jak je uvedeno v předchozím seznamu, vlastnost To je vyhrazena pro budoucí použití a může být v budoucnu interpretována zprostředkovatelem s použitím speciálně povolené funkce. Aplikace, které chtějí implementovat směrování, by to měly provést na základě vlastností uživatele a nemají se spoléhat na vlastnost To ; ale teď nezpůsobí problémy s kompatibilitou.

Serializace datové části

Při přenosu nebo uložení uvnitř služby Service Bus je datová část vždy neprůrůzdný binární blok. Vlastnost ContentType umožňuje aplikacím popisovat datovou část s doporučeným formátem hodnot, který je popisem typu obsahu MIME podle IETF RFC2045, například application/json;charset=utf-8.

Na rozdíl od variant Java nebo .NET Standard podporuje verze rozhraní .NET Framework rozhraní API služby Service Bus vytváření instancí BrokeredMessage předáním libovolných objektů .NET do konstruktoru.

30. září 2026 vyřadíme knihovny sady SDK služby Azure Service Bus pro WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus a com.microsoft.azure.servicebus, které nevyhovují pokynům sady Azure SDK. Také ukončíme podporu protokolu SBMP, takže tento protokol už nebudete moct používat po 30. září 2026. Před tímto datem migrujte na nejnovější knihovny sady Azure SDK, které nabízejí důležité aktualizace zabezpečení a vylepšené funkce.

I když starší knihovny je možné používat i po 30. září 2026, nebudou už od Microsoftu dostávat oficiální podporu a aktualizace. Další informace najdete v oznámení o vyřazení podpory.

Pokud používáte starší protokol SBMP, tyto objekty jsou následně serializovány pomocí výchozího binárního serializátoru nebo pomocí sériového serializátoru, který zadáte externě. Objekt je serializován do objektu AMQP. Příjemce může tyto objekty načíst pomocí GetBody<T>() metody a zadat očekávaný typ. Pomocí AMQP se objekty serializují do grafu ArrayList AMQP a IDictionary<string,object> objektů a jakýkoli klient AMQP je může dekódovat.

Important

Dne 30. září 2026 vyřadíme podporu protokolu SBMP pro Azure Service Bus, takže tento protokol už nebudete moct používat po 30. září 2026. Migrujte na nejnovější knihovny sady AZURE SERVICE BUS SDK pomocí protokolu AMQP (Advanced Message Queuing Protocol), který nabízí důležité aktualizace zabezpečení a vylepšené funkce před tímto datem.

Další informace najdete v oznámení o vyřazení podpory.

I když je toto skryté serializační kouzlo pohodlné, aplikace by měly převzít explicitní kontrolu nad serializací objektů a převést jejich objektové grafy na datové proudy předtím, než je zahrnou do zprávy, a postupovat obráceně na straně příjemce. Výsledkem jsou interoperabilní výsledky. I když má AMQP výkonný model binárního kódování, je svázaný s ekosystémem zasílání zpráv AMQP a klienti HTTP mají potíže s dekódováním takových datových částí.

Varianty rozhraní .NET Standard a Java API přijímají pouze bajtová pole, což znamená, že aplikace musí zpracovávat ovládací prvek serializace objektů.

Při zpracování deserializace objektu z datové části zprávy by vývojáři měli vzít v úvahu, že zprávy mohou přicházet z více zdrojů pomocí různých metod serializace. K této situaci může také dojít při vývoji jedné aplikace, kde staré verze nadále běží společně s novějšími verzemi. V těchto případech zvažte další metody deserializace, které se mají vyzkoušet, pokud první pokus o deserializaci selže. Jednou z knihoven, která tento přístup podporuje, je NServiceBus. Pokud všechny metody deserializace selžou, pak umístit zprávu do fronty nevyřízených zpráv.

Další kroky

Další informace o zasílání zpráv služby Service Bus najdete v následujících tématech:

  • Last updated on