Fronty úložiště a fronty služby Service Bus – porovnání a kontrast

Tento článek analyzuje rozdíly a podobnosti mezi dvěma typy front nabízených Microsoft Azure: frontami služby Storage a frontami Service Bus. Pomocí těchto informací můžete učinit informovanější rozhodnutí o tom, které řešení nejlépe vyhovuje vašim potřebám.

Úvod

podpora Azure dva typy mechanismů fronty: Fronty úložiště a fronty služby Service Bus

Fronty úložiště jsou součástí infrastruktury služby Azure Storage . Umožňují ukládat velký počet zpráv. Ke zprávům se dostanete odkudkoli na světě prostřednictvím ověřených volání pomocí protokolu HTTP nebo HTTPS. Zpráva fronty může mít velikost až 64 kB. Fronta může obsahovat miliony zpráv až do celkového limitu kapacity účtu úložiště. Fronty se běžně používají k vytvoření backlogu práce pro asynchronní zpracování. Další informace najdete v tématu Co jsou fronty Azure Storage.

Fronty služby Service Bus jsou součástí širší infrastruktury zasílání zpráv Azure, která podporuje řazení do front, publikování a odběr a pokročilejší vzory integrace. Jsou navržené tak, aby integrovali aplikace nebo komponenty aplikací, které můžou zahrnovat více komunikačních protokolů, kontraktů dat, domén důvěryhodnosti nebo síťových prostředí. Další informace o frontách, tématech a odběrech služby Service Bus najdete ve frontách, tématech a odběrech služby Service Bus.

Aspekty výběru technologií

Fronty úložiště a fronty služby Service Bus mají mírně odlišnou sadu funkcí. V závislosti na potřebách konkrétního řešení můžete zvolit jednu nebo obě.

Při určování, která technologie řízení front odpovídá účelu daného řešení, by architekti řešení a vývojáři měli tato doporučení zvážit.

Zvažte použití front služby Storage.

Jako architekt řešení nebo vývojář byste měli zvážit použití front služby Storage v následujících případech:

• Aplikace musí ukládat do fronty více než 80 gigabajtů zpráv.
• Vaše aplikace chce sledovat průběh zpracování zprávy ve frontě. Je užitečné, když pracovní proces zpracovává zprávu, která se chybově ukončí. Jiný pracovník pak může tyto informace použít k tomu, aby pokračoval tam, kde předchozí pracovník skončil.
• Vyžadujete protokoly na straně serveru všech transakcí spuštěných ve frontách.

Zvažte použití front Service Bus

Jako architekt řešení nebo vývojář byste měli zvážit použití front Service Bus v následujících případech:

• Vaše řešení potřebuje přijímat zprávy, aniž byste museli dotazovat frontu. Pomocí služby Service Bus ji můžete dosáhnout pomocí dlouhotrvající operace příjmu dotazování pomocí protokolů založených na protokolu TCP, které Service Bus podporuje.
• Vaše řešení vyžaduje, aby fronta poskytovala garantované doručování typu first-in-first-out (FIFO).
• Vaše řešení musí podporovat automatické zjišťování duplicit.
• Chcete, aby vaše aplikace zpracovávala zprávy jako paralelní dlouhotrvající streamy (zprávy jsou přidružené ke streamu pomocí vlastnosti ID relace ve zprávě). V tomto modelu každý uzel v aplikaci, která využívá, se na rozdíl od zpráv konkuruje datovým proudům. Pokud je datový proud předán spotřebě uzlu, může uzel prozkoumat stav stavu datového proudu aplikace pomocí transakcí.
• Vaše řešení vyžaduje transakční chování a atomicitu při odesílání nebo přijímání více zpráv z fronty.
• Vaše aplikace zpracovává zprávy, které můžou překročit 64 kB, ale pravděpodobně nebudou přistupovat k limitu 256 kB nebo 1 MB v závislosti na zvolené úrovni služby (i když fronty Service Bus můžou zpracovávat zprávy až 100 MB).
• Řešíte požadavek na poskytnutí modelu přístupu na základě role frontám a různým právům a oprávněním pro odesílatele a příjemce. Další informace najdete v následujících článcích:
  • Ověřování pomocí spravovaných identit
  • Ověření z aplikace
• Velikost fronty nebude větší než 80 GB.
• Chcete použít protokol zasílání zpráv založený na standardech AMQP 1.0. Další informace o AMQP naleznete v tématu Přehled AMQP služby Service Bus.
• Představte si případnou migraci z komunikace typu point-to-point založené na frontě na model zasílání zpráv publikování a odběru. Tento model umožňuje integraci dalších příjemců (odběratelů). Každý příjemce obdrží nezávislé kopie některých nebo všech zpráv odeslaných do fronty.
• Řešení zasílání zpráv musí podporovat záruky doručení "At-Most-Once" a "Alespoň jednou", aniž byste museli vytvářet další komponenty infrastruktury.
• Vaše řešení musí publikovat a využívat dávky zpráv.

Porovnání front služby Storage a front Service Bus

Tabulky v následujících částech poskytují logické seskupení funkcí fronty. Umožňují vám na první pohled porovnat možnosti dostupné ve frontách Azure Storage i ve frontách Service Bus.

Základní možnosti

Tato část porovnává některé základní možnosti řazení front, které poskytují fronty služby Storage a fronty Service Bus.

Další informace

• Zprávy ve frontách služby Storage jsou obvykle první v prvním místě, ale někdy můžou být mimo pořadí. Pokud například vyprší doba trvání vypršení časového limitu viditelnosti zprávy, protože při zpracování zprávy došlo k chybovému ukončení klientské aplikace. Po vypršení časového limitu viditelnosti se zpráva znovu zobrazí ve frontě, aby ji jiný pracovní proces odřadil. V tomto okamžiku může být nově viditelná zpráva umístěna do fronty, aby se znovu odřadila.
• Zaručený vzor FIFO ve frontách služby Service Bus vyžaduje použití relací zasílání zpráv. Pokud dojde k chybovému ukončení aplikace při zpracování zprávy přijaté v režimu Náhled a zámek , při příštím přijetí relace fronty příjemcem zasílání zpráv začne se zprávou, která selhala po vypršení doby trvání uzamčení relace.
• Fronty úložiště jsou navržené tak, aby podporovaly standardní scénáře řazení do front, například tyto:
  • Oddělení komponent aplikace za účelem zvýšení škálovatelnosti a tolerance pro selhání
  • Vyrovnávání zatížení
  • Vytváření pracovních postupů procesu
• Nekonzistence týkající se zpracování zpráv v kontextu relací služby Service Bus se dá vyhnout použitím stavu relace k uložení stavu aplikace vzhledem k průběhu zpracování pořadí zpráv relace a použitím transakcí kolem vyrovnání přijatých zpráv a aktualizace stavu relace. Tento druh funkce konzistence se někdy označuje přesně jednou za zpracování v produktech jiného dodavatele. Jakákoli selhání transakcí samozřejmě způsobí, že se zprávy znovu obnoví a proto termín není přesně odpovídající.
• Fronty úložiště poskytují jednotný a konzistentní programovací model napříč frontami, tabulkami a bloby – jak pro vývojáře, tak pro provozní týmy.
• Fronty služby Service Bus poskytují podporu místních transakcí v kontextu jedné fronty.
• Režim příjmu a odstranění podporovaný službou Service Bus umožňuje snížit počet operací zasílání zpráv (a související náklady) výměnou za účelem snížení záruky doručení.
• Fronty úložiště poskytují zapůjčení s možností rozšířit zapůjčení zpráv. Tato funkce umožňuje pracovním procesům udržovat krátké zapůjčení zpráv. Takže pokud dojde k chybovému ukončení pracovního procesu, může zprávu rychle zpracovat jiný pracovník. Pracovní proces může také prodloužit zapůjčení zprávy, pokud ji potřebuje zpracovat déle než aktuální čas zapůjčení.
• Fronty úložiště nabízejí časový limit viditelnosti, který můžete nastavit při zařazení zprávy do fronty nebo jeho vyřazení z fronty. Můžete také aktualizovat zprávu o různých hodnotách zapůjčení za běhu a aktualizovat různé hodnoty mezi zprávami ve stejné frontě. Časové limity uzamčení služby Service Bus jsou definovány v metadatech fronty. Zámek zprávy však můžete prodloužit pro předdefinované doby trvání zámku ručně nebo můžete použít funkci automatického prodlužování uzamčení, ve které za vás klient spravuje obnovení zámku.
• Maximální časový limit blokující operace příjmu ve frontách služby Service Bus je 24 dní. Časové limity založené na REST ale mají maximální hodnotu 55 sekund.
• Dávkování na straně klienta poskytované službou Service Bus umožňuje klientovi fronty dávkot více zpráv do jedné operace odeslání. Dávkování je k dispozici pouze pro asynchronní operace odesílání.
• Díky funkcím, jako je strop 200 TB front úložiště (více při virtualizaci účtů) a neomezené fronty, je ideální platformou pro poskytovatele SaaS.
• Fronty úložiště poskytují flexibilní a výkonný mechanismus delegovaného řízení přístupu.

Pokročilé možnosti

Tato část porovnává pokročilé funkce poskytované frontami služby Storage a frontami služby Service Bus.

Další informace

• Obě technologie řízení front umožňují naplánování doručení zprávy později.
• Automatické přechánění front umožňuje tisícům front automaticky přecházet zprávy do jedné fronty, ze které přijímající aplikace zprávu využívá. Pomocí tohoto mechanismu můžete dosáhnout zabezpečení, toku řízení a izolovat úložiště mezi každým vydavatelem zpráv.
• Fronty úložiště poskytují podporu pro aktualizaci obsahu zpráv. Tuto funkci můžete použít k zachování informací o stavu a přírůstkových aktualizacích průběhu do zprávy, aby bylo možné ji zpracovat z posledního známého kontrolního bodu, a ne začít úplně od začátku. Pomocí front Service Bus můžete stejný scénář povolit pomocí relací zpráv. Další informace naleznete v tématu Stav relace zprávy.
• Fronty služby Service Bus podporují nedoručených dopisů. Může být užitečné pro izolování zpráv, které splňují následující kritéria:
  • Přijímající aplikace nemůže úspěšně zpracovat zprávy.
  • Zprávy se nemůžou spojit s cílem kvůli vlastnosti TTL (Time to Live) s vypršenou platností. Hodnota TTL určuje, jak dlouho zpráva zůstává ve frontě. Se službou Service Bus se zpráva přesune do speciální fronty s názvem $DeadLetterQueue, když vyprší doba TTL.
• Chcete-li najít "jed" zprávy ve frontách služby Storage, při vyřazení zprávy aplikace prozkoumá vlastnost DequeueCount zprávy. Pokud je dequeueCount větší než daná prahová hodnota, aplikace přesune zprávu do fronty "nedoručených zpráv" definovaných aplikací.
• Fronty úložiště umožňují získat podrobný protokol všech transakcí spuštěných ve frontě a agregované metriky. Obě tyto možnosti jsou užitečné pro ladění a pochopení způsobu, jakým vaše aplikace používá fronty služby Storage. Jsou také užitečné pro optimalizaci výkonu aplikace a snížení nákladů na používání front.
• Relace zpráv podporované službou Service Bus umožňují, aby zprávy, které patří do logické skupiny, byly přidruženy k příjemci. Vytvoří spřažení podobné relaci mezi zprávami a příslušnými příjemci. Tuto pokročilou funkci ve službě Service Bus můžete povolit nastavením vlastnosti ID relace ve zprávě. Příjemci pak můžou naslouchat konkrétnímu ID relace a přijímat zprávy, které sdílejí zadaný identifikátor relace.
• Funkce detekce duplicit front Service Bus automaticky odebere duplicitní zprávy odeslané do fronty nebo tématu na základě hodnoty vlastnosti ID zprávy.

Kapacita a kvóty

Tato část porovnává fronty služby Storage a fronty služby Service Bus z pohledu kapacity a kvót , které by se mohly použít.

Další informace

• Service Bus vynucuje omezení velikosti fronty. Při vytváření fronty se zadává maximální velikost fronty. Může to být mezi 1 GB a 80 GB. Pokud velikost fronty dosáhne tohoto limitu, další příchozí zprávy budou odmítnuty a volající obdrží výjimku. Další informace o kvótách ve službě Service Bus najdete v tématu Kvóty služby Service Bus.
• Ve standardní úrovni zasílání zpráv můžete vytvářet fronty a témata služby Service Bus ve 1 (výchozí), 2, 3, 4 nebo 5 GB velikostí. Při povolování dělení na úrovni Standard vytvoří Service Bus 16 kopií (16 oddílů) entity, přičemž každá má zadanou velikost. Pokud tedy vytvoříte frontu o velikosti 5 GB, stane se maximální velikost fronty 16 oddílů (5 × 16) = 80 GB. Maximální velikost dělené fronty nebo tématu můžete zobrazit na webu Azure Portal.
• Pokud obsah zprávy není bezpečný pro službu Storage, musí být kódovaný ve službě Base64 . Pokud zprávu zakódujete pomocí kódování Base64, datová část uživatele může být až 48 kB, a ne 64 kB.
• Ve frontách služby Service Bus se každá zpráva uložená ve frontě skládá ze dvou částí: záhlaví a textu. Celková velikost zprávy nesmí překročit maximální velikost zprávy podporovanou úrovní služby.
• Když klienti komunikují s frontami služby Service Bus přes protokol TCP, maximální počet souběžných připojení k jedné frontě služby Service Bus je omezený na 100. Toto číslo se sdílí mezi odesílateli a příjemci. Pokud dosáhnete této kvóty, žádosti o další připojení budou odmítnuty a volající kód obdrží výjimku. Tento limit se neukládají na klienty připojující se k frontám pomocí rozhraní REST API.
• Pokud chcete škálovat nad rámec 10 000 front pomocí skladové položky Service Bus Standard nebo 1000 front / jednotky zasílání zpráv pomocí skladové položky Service Bus Premium, můžete také vytvořit další obory názvů pomocí webu Azure Portal.

Správa a provoz

Tato část porovnává funkce správy poskytované frontami služby Storage a frontami služby Service Bus.

Další informace

• Fronty úložiště poskytují podporu pro libovolné atributy, které lze použít pro popis fronty ve formě párů název/hodnota.
• Obě technologie front nabízejí možnost zobrazit si zprávu bez nutnosti ji uzamknout, což může být užitečné při implementaci nástroje průzkumníka front nebo prohlížeče.
• Rozhraní API zprostředkovaného zasílání zpráv service Bus používají plně duplexní připojení TCP pro lepší výkon v porovnání s rozhraním REST přes PROTOKOL HTTP a podporují standardní protokol AMQP 1.0.
• Názvy front služby Storage můžou mít délku 3 až 63 znaků, můžou obsahovat malá písmena, číslice a pomlčky. Další informace najdete v tématu Pojmenování front a metadat.
• Názvy front služby Service Bus můžou mít délku až 260 znaků a mají méně omezující pravidla pojmenování. Názvy front služby Service Bus můžou obsahovat písmena, číslice, tečky, pomlčky a podtržítka.

Ověřování a autorizace

Tato část popisuje funkce ověřování a autorizace podporované frontami služby Storage a frontami služby Service Bus.

Další informace

• Každý požadavek na některou z technologií front musí být ověřený. Veřejné fronty s anonymním přístupem se nepodporují.
• Pomocí ověřování sdíleného přístupového podpisu (SAS) můžete vytvořit pravidlo autorizace sdíleného přístupu ve frontě, které uživatelům umožňuje přístup jen pro zápis, jen pro čtení nebo úplný přístup. Další informace najdete v tématu Azure Storage – Ověřování SAS a Azure Service Bus – Ověřování SAS.
• Obě fronty podporují autorizaci přístupu pomocí ID Microsoft Entra. Autorizace uživatelů nebo aplikací pomocí tokenu OAuth 2.0 vráceného id Microsoft Entra poskytuje vynikající zabezpečení a snadné použití u sdílených přístupových podpisů (SAS). S ID Microsoft Entra není nutné ukládat tokeny do kódu a riskovat potenciální ohrožení zabezpečení. Další informace najdete v tématu Azure Storage – Ověřování Microsoft Entra a Azure Service Bus – Ověřování Microsoft Entra.

Závěr

Když získáte hlubší přehled o těchto dvou technologiích, můžete informovanější rozhodnutí o tom, jakou technologii fronty použít, a kdy. Rozhodnutí o tom, kdy použít fronty služby Storage nebo fronty služby Service Bus, jasně závisí na mnoha faktorech. Tyto faktory závisí hodně na individuálních potřebách vaší aplikace a její architektuře.

Fronty služby Storage můžete raději zvolit z následujících důvodů:

• Pokud vaše aplikace už používá základní funkce Microsoft Azure
• Pokud potřebujete základní komunikaci a zasílání zpráv mezi službami
• Potřebujete fronty, které můžou mít velikost větší než 80 GB.

Fronty služby Service Bus poskytují mnoho pokročilých funkcí, jako jsou například následující. Proto mohou být upřednostňovanou volbou, pokud vytváříte hybridní aplikaci nebo pokud vaše aplikace jinak tyto funkce vyžaduje.

• Přednášky
• Transakce
• Vyhledávání duplicit
• Automatické nedoručených dopisů
• Možnosti trvalého publikování a přihlášení k odběru

Další kroky

Následující články obsahují další pokyny a informace o používání front služby Storage nebo front Service Bus.

• Začínáme s frontami služby Service Bus
• Jak používat službu Queue Storage
• Osvědčené postupy pro vylepšení výkonu pomocí zprostředkovaného zasílání zpráv ve službě Service Bus