Sdílet prostřednictvím

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

  • Článek

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

Kritéria porovnání Fronty úložiště Fronty služby Service Bus
Záruka objednávání Ne

Další informace najdete v první poznámce v části Další informace .
 Ano – první první out (FIFO)

(pomocí relací zpráv)
Záruka doručení Alespoň jednou Alespoň jednou (pomocí režimu příjmu PeekLock. Je to výchozí)

Maximálně jednou (pomocí režimu příjmu ReceiveAndDelete)

Další informace o různých režimech příjmu
Podpora atomických operací No Ano
Chování příjmu Neblokující

(dokončí se okamžitě, pokud se nenajde žádná nová zpráva)		 Blokování s vypršením časového limitu nebo bez časového limitu

(nabízí dlouhé dotazování nebo "kometu techniky")

Neblokující

(pouze s využitím spravovaného rozhraní API .NET)
Rozhraní API ve stylu push No Ano

Naše sady .NET, Java, JavaScript a Go SDK poskytují rozhraní API ve stylu push.
Režim příjmu Náhled a zapůjčení Náhled a zámek

Přijmout a odstranit
Výhradní režim přístupu Na základě zapůjčení Na základě zámku
Doba trvání zapůjčení/uzamčení 30 sekund (výchozí)

7 dnů (maximum) (zapůjčení zpráv můžete prodloužit nebo uvolnit pomocí rozhraní UpdateMessage API.)		 30 sekund (výchozí)

Zámek zprávy můžete obnovit po stejnou dobu trvání pokaždé ručně nebo můžete použít funkci automatického prodlužování uzamčení, ve které za vás klient spravuje prodlužování platnosti zámku.
Přesnost zapůjčení/uzamčení Úroveň zprávy

Každá zpráva může mít jinou hodnotu časového limitu, kterou pak můžete aktualizovat podle potřeby při zpracování zprávy pomocí rozhraní UpdateMessage API.		 Úroveň fronty

(každá fronta má pro všechny zprávy nastavenou přesnost zámku, ale zámek lze obnovit, jak je popsáno v předchozím řádku).
Dávkové přijímání Ano

(explicitní určení počtu zpráv při načítání zpráv, maximálně 32 zpráv)		 Ano

(implicitně povolení předem načtené vlastnosti nebo explicitně pomocí transakcí)
Dávkové odesílání No Ano

(pomocí transakcí nebo dávkování na straně klienta)

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.

Kritéria porovnání Fronty úložiště Fronty služby Service Bus
Naplánované doručení Ano Yes
Automatické nedoručených dopisů No Ano
Zvýšení hodnoty TTL (Time to Live) fronty Ano

(prostřednictvím místní aktualizace časového limitu viditelnosti)		 Ano

(poskytované prostřednictvím vyhrazené funkce rozhraní API)
Podpora otrávené zprávy Ano Yes
Místní aktualizace Ano Yes
Protokol transakcí na straně serveru Yes No
Metriky úložiště Ano

Minute Metrics poskytuje metriky v reálném čase pro dostupnost, TPS, počty volání rozhraní API, počty chyb a další. Všechny jsou v reálném čase agregované za minutu a během několika minut od toho, co se právě stalo v produkčním prostředí. Další informace najdete v tématu o metrikách Analýza úložiště.		 Ano

Informace o metrikách podporovaných službou Azure Service Bus najdete v tématu Metriky zpráv.
Správa stavu No Ano (Aktivní, Zakázáno, SendDisabled, ReceiveDisabled. Podrobnosti o těchto stavech najdete v tématu Stav fronty.
Automatické vytváření zpráv No Ano
Funkce vyprázdnění fronty Yes No
Skupiny zpráv No Ano

(pomocí relací zasílání zpráv)
Stav aplikace na skupinu zpráv No Ano
Vyhledávání duplicit No Ano

(konfigurovatelné na straně odesílatele)
Procházení skupin zpráv No Ano
Načítání relací zpráv podle ID No Ano

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.

Kritéria porovnání Fronty úložiště Fronty služby Service Bus
Maximální velikost fronty 500 TB

(omezeno na jednu kapacitu účtu úložiště)		 1 GB až 80 GB

(definované při vytváření fronty a povolení dělení – viz část Další informace)
Maximální velikost zprávy 64 kB

(48 kB při použití kódování Base 64)

podpora Azure velké zprávy zkombinováním front a objektů blob – v tomto okamžiku můžete vytvořit fronty až 200 GB pro jednu položku.		 256 kB nebo 100 MB

(včetně záhlaví i textu, maximální velikosti záhlaví: 64 kB).

Závisí na úrovni služby.
Maximální hodnota TTL zprávy Infinite (api-version 2017-07-27 nebo novější) Timespan.maxvalue
Maximální počet front Bez omezení 10,000

(podle oboru názvů služby)
Maximální počet souběžných klientů Bez omezení 5 000

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 v jednom oboru názvů služby Service Bus potřebujete více než 10 000 front, můžete kontaktovat podpora Azure tým a požádat o zvýšení. Pokud chcete škálovat více než 10 000 front pomocí služby Service Bus, 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.

Kritéria porovnání Fronty úložiště Fronty služby Service Bus
Protokol pro správu REST přes HTTP/HTTPS REST přes HTTPS
Protokol modulu runtime REST přes HTTP/HTTPS REST přes HTTPS

AMQP 1.0 Standard (TCP s TLS)
.NET API Ano

(.NET Storage Client API)		 Ano

(.NET Service Bus API)
Nativní C++ Ano Yes
Rozhraní API Javy Ano Yes
PHP API Ano Yes
Node.js API Ano Yes
Podpora libovolných metadat Yes No
Pravidla pojmenování fronty Maximálně 63 znaků

(Písmena v názvu fronty musí být malá písmena.)		 Maximálně 260 znaků

(Cesty a názvy front jsou nerozlišující malá a velká písmena.)
Získání funkce délky fronty Ano

(Přibližná hodnota, pokud vyprší platnost zpráv nad rámec hodnoty TTL bez odstranění.)		 Ano

(Přesná hodnota k určitému bodu v čase.)
Náhled funkce Ano Yes

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.

Kritéria porovnání Fronty úložiště Fronty služby Service Bus
Ověřování Symetrický klíč a řízení přístupu na základě role (RBAC) Symetrický klíč a řízení přístupu na základě role (RBAC)
Federace zprostředkovatele identity Ano Yes

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.

Další kroky

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