fronty Storage a fronty Service Bus – porovnání a kontrast

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

Úvod

Azure podporuje dva typy mechanismů fronty: Storage fronty a Service Bus fronty.

fronty Storage jsou součástí infrastruktury Azure Storage . Umožňují ukládat velký počet zpráv. Přístup ke zprávám 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 vytváření nevyřízených položek pro asynchronní zpracování. další informace najdete v tématu co jsou Azure Storage fronty.

fronty Service Bus jsou součástí širší infrastruktury zasílání zpráv Azure , která podporuje řazení do fronty, publikování a odběru a pokročilejší způsoby integrace. Jsou navržené tak, aby se integroval aplikace nebo součásti aplikací, které můžou zahrnovat víc komunikačních protokolů, kontraktů dat, důvěřujících domén nebo síťových prostředí. další informace o Service Bus frontách, tématech a předplatných najdete v tématu Service Bus fronty, témata apředplatná.

Požadavky na výběr technologie

fronty Storage a Service Bus fronty mají mírně odlišnou sadu funkcí. V závislosti na potřebách konkrétního řešení si můžete vybrat buď jednu, nebo obě.

Při určování technologie zařazené do fronty vyhovuje účelu daného řešení, architekti a vývojářům řešení by měli tato doporučení vzít v úvahu.

zvažte použití front Storage.

jako architekt nebo vývojář řešení byste měli zvážit použití Storagech front v těchto případech:

• Vaše aplikace musí ukládat více než 80 gigabajtů zpráv ve frontě.
• Vaše aplikace chce sledovat průběh zpracování zprávy ve frontě. To je užitečné v případě, že pracovní proces zpracovává selhání zprávy. Další pracovník pak může tyto informace použít k pokračování z místa, kde předchozí pracovní proces skončil.
• Vyžadujete, aby byly v protokolech na straně serveru všechny transakce spouštěny na vašich frontách.

zvažte použití front Service Bus.

jako architekt nebo vývojář řešení byste měli zvážit použití Service Busch front v těchto případech:

• Vaše řešení musí přijímat zprávy bez nutnosti cyklického dotazování fronty. pomocí Service Bus můžete dosáhnout pomocí dlouhotrvajících protokolů založených na protokolu TCP, které Service Bus podporuje.
• Vaše řešení vyžaduje, aby fronta poskytovala zaručené doručování FIFO (First-in-first-out).
• Vaše řešení musí podporovat automatickou detekci duplicit.
• Chcete, aby aplikace zpracovala zprávy jako paralelní dlouhodobé proudy (zprávy jsou přidruženy ke streamu pomocí vlastnosti ID relace ve zprávě). V tomto modelu každý uzel v náročné aplikaci soutěží na datové proudy, nikoli na zprávy. Když je datový proud přidělen k náročnému uzlu, uzel může prošetřit stav stavu datového proudu aplikace pomocí transakcí.
• Vaše řešení vyžaduje transakční chování a nedělitelnost při odesílání nebo přijímání více zpráv z fronty.
• Vaše aplikace zpracovává zprávy, které mohou překročit 64 KB, ale nezpůsobí přístup k limitu 256-KB.
• Vyřešíte požadavek na poskytování modelu přístupu na základě role do front a různá práva a oprávnění 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 standardu AMQP 1,0. další informace o AMQP najdete v tématu přehled služby Service Bus AMQP.
• V konečném důsledku je jakákoli migrace z typu Point-to-Point na základě fronty na vzor zasílání zpráv pro publikování a odběr. Tento model umožňuje integraci dalších přijímačů (předplatitelů). Každý příjemce obdrží nezávislé kopie buď některých nebo všech zpráv odesílaných do fronty.
• Vaše řešení pro zasílání zpráv musí podporovat záruku doručení "na nejvyšší úrovni", aniž byste museli sestavovat další součásti infrastruktury.
• Vaše řešení potřebuje publikovat a využívat dávky zpráv.

porovnání front Storage a front Service Bus

Tabulky v následujících částech poskytují logické seskupení funkcí fronty. umožňují vám na první pohled porovnávat možnosti dostupné v Azure Storage frontách a Service Busch frontách.

Základní možnosti

v této části jsou porovnávány některé základní možnosti služby řízení front, které poskytuje Storage fronty a Service Bus fronty.

Další informace

• zprávy ve frontách Storage jsou obvykle první, kdy jsou první, ale někdy můžou být mimo pořadí. Například když vyprší doba trvání viditelnosti zprávy, protože při zpracování zprávy došlo k chybě v klientské aplikaci. Po vypršení časového limitu viditelnosti se zpráva znovu zobrazí ve frontě, aby ji jiný pracovní proces vyřadí do fronty. V tomto okamžiku je možné nově zobrazovanou zprávu umístit do fronty pro opětovné vyřazení z fronty.
• model garantované služby FIFO v Service Bus fronty vyžaduje použití relací zasílání zpráv. Pokud aplikace selže, zatímco zpracovává zprávu přijatou v režimu náhledu & zámku , při dalším přijímači fronty po dobu platnosti relace zasílání zpráv se po vypršení časového limitu TTL (Time-to-Live) zahájí zpráva, která selhala.
• fronty Storage jsou navržené tak, aby podporovaly standardní scénáře zařazování do fronty, například následující:
  • Oddělení součástí aplikace za účelem zvýšení škálovatelnosti a tolerance selhání
  • Vyrovnávání zatížení
  • Vytváření pracovních postupů procesu.
• nekonzistence týkající se zpracování zpráv v kontextu Service Bus relací se mohou vyhnout pomocí stavu relace k uložení stavu aplikace relativně ke způsobu zpracování sekvence zpráv relace a pomocí transakcí týkajících se nedostatku přijatých zpráv a aktualizace stavu relace. Tento druh funkce konzistence je někdy označený přesně po zpracování v produktech jiných dodavatelů. Jakékoli chyby transakcí způsobí, že se zprávy znovu dostanou a že jsou důvody, proč se termín neshoduje.
• fronty Storage poskytují jednotný a konzistentní programovací model napříč frontami, tabulkami a objekty blob – jak pro vývojáře, tak pro provozní týmy.
• fronty Service Bus poskytují podporu pro místní transakce v kontextu jedné fronty.
• režim přijímání a odstraňování podporovaný nástrojem Service Bus poskytuje možnost snížit počet operací zasílání zpráv (a související náklady) v systému exchange pro zajištění nižšího objemu doručování.
• fronty Storage poskytují zapůjčení s možností rozšiřování zapůjčení pro zprávy. Tato funkce umožňuje pracovním procesům udržovat krátká zapůjčení zpráv. Pokud tedy dojde k selhání pracovního procesu, může být zpráva znovu zpracována jiným pracovním procesem. Pracovník může také prodloužit zapůjčení zprávy v případě, že je potřebuje zpracovat delší dobu, než je aktuální zapůjčení.
• Storage fronty nabízejí časový limit viditelnosti, který můžete nastavit na enqueuing nebo v zařazování zpráv do fronty. Můžete také aktualizovat zprávu s různými hodnotami zapůjčení za běhu a aktualizovat různé hodnoty napříč zprávami ve stejné frontě. v metadatech fronty jsou definovány Service Bus vypršení časových limitů zámků. Zámek zprávy pro předem definovanou dobu trvání zámku ale můžete obnovit ručně nebo použít funkci automatického obnovení zámků, kde klient spravuje obnovení zámků za vás.
• maximální časový limit pro blokování operace přijímání v Service Bus frontách je 24 dní. Vypršení časového limitu založeného na REST ale mají maximální hodnotu 55 sekund.
• dávkování na straně klienta, které poskytuje Service Bus, umožňuje klientovi fronty dávkovat více zpráv do jediné operace odeslání. Dávkování je k dispozici pouze pro operace asynchronního odeslání.
• funkce, jako je 200 mez-TB Storagech front (více při virtualizaci účtů) a neomezené fronty, usnadňují pro poskytovatele SaaS ideální platformu.
• fronty Storage poskytují flexibilní a výkonné mechanismy řízení přístupu.

Pokročilé možnosti

tato část porovnává rozšířené možnosti poskytované Storage frontami a Service Bus front.

Další informace

• Obě technologie pro řízení front umožňují, aby byla zpráva naplánována na doručení později.
• Při autopřesměrovávání do fronty je možné, že tisíce front mají na jednu frontu automatickou přeposílání zpráv do jediné fronty, ze které přijímající aplikace tuto zprávu spotřebovává. Tento mechanismus můžete použít k zajištění zabezpečení, řízení toku a izolace úložiště mezi jednotlivými vydavateli zpráv.
• fronty Storage poskytují podporu pro aktualizaci obsahu zprávy. Tuto funkci můžete použít pro trvalé informace o stavu a přírůstkové aktualizace průběhu do zprávy tak, aby se mohly zpracovat z posledního známého kontrolního bodu, a ne od začátku. u Service Busch front můžete pomocí relací zpráv povolit stejný scénář. Další informace najdete v tématu stav relace zpráv.
• fronty Service Bus podporují nedoručené dopisy. Může být užitečný pro izolaci zpráv, které splňují následující kritéria:
  • Zprávy nelze úspěšně zpracovat přijímající aplikací.
  • Zprávy se nemohou dostat do svého cíle z důvodu vypršení platnosti vlastnosti TTL (Time to Live). Hodnota TTL určuje, jak dlouho zpráva zůstane ve frontě. při Service Bus bude zpráva přesunuta do speciální fronty nazvané $DeadLetterQueue po vypršení časového limitu TTL.
• pokud chcete ve frontách Storage najít "poškozené" zprávy při vyřazení zprávy, aplikace ověří 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é aplikací.
• fronty Storage umožňují získat podrobný protokol všech transakcí provedených proti frontě a agregované metriky. obě tyto možnosti jsou užitečné pro ladění a porozumění způsobu, jakým vaše aplikace používá Storage fronty. Jsou také užitečné pro vyladění výkonu aplikace a snížení nákladů na používání front.
• relace zpráv podporované nástrojem Service Bus umožňují, aby byly zprávy patřící do logické skupiny přidružené k přijímači. Vytvoří spřažení podobné relaci mezi zprávami a jejich příslušnými přijímači. tuto rozšířenou funkci můžete v Service Bus povolit nastavením vlastnosti ID relace ve zprávě. Přijímačé pak mohou naslouchat konkrétnímu ID relace a přijímat zprávy, které sdílejí zadaný identifikátor relace.
• funkce detekce duplicitních dat ve frontách Service Bus automaticky odstraní duplicitní zprávy odeslané do fronty nebo tématu, a to na základě hodnoty vlastnosti ID zprávy.

Kapacita a kvóty

v této části se porovnávají Storage fronty a Service Bus fronty z perspektivy kapacity a kvót , které mohou platit.

Další informace

• Service Bus vynutila omezení velikosti fronty. Maximální velikost fronty je určena při vytváření fronty. Může být v rozmezí 1 GB až 80 GB. Pokud velikost fronty dosáhne tohoto limitu, další příchozí zprávy se odmítnou a volající obdrží výjimku. další informace o kvótách v Service Bus najdete v tématu kvóty Service Bus.
• dělení není v Premium vrstvěpodporováno. na úrovni Standard pro zasílání zpráv můžete vytvořit Service Bus fronty a témata ve velikosti 1 (výchozí), 2, 3, 4 nebo 5 GB. když je zapnuté dělení, Service Bus vytvoří 16 kopií (16 oddílů) entity, každé zadané velikosti. Pokud vytvoříte frontu o velikosti 5 GB, přičemž 16 oddílů se změní na maximální velikost fronty (5 × 16) = 80 GB. V Azure Portalmůžete zobrazit maximální velikost rozdělené fronty nebo tématu.
• v případě Storagech front, pokud obsah zprávy není zabezpečený kódem XML, musí být kódovaný v kódování Base64 . Pokud zprávu zakódujete ve formátu base64, může být datová část uživatele až 48 kb namísto 64 KB.
• u Service Busch front se každá zpráva uložená ve frontě skládá ze dvou částí: záhlaví a tělo. Celková velikost zprávy nepřekračuje maximální velikost zprávy podporované vrstvou služby.
• pokud klienti komunikují s Service Bus frontami přes protokol TCP, maximální počet souběžných připojení k jedné frontě Service Bus je omezený na 100. Toto číslo je sdíleno mezi odesílateli a přijímači. Pokud je dosažena tato kvóta, žádosti o další připojení budou odmítnuty a volající kód bude přijímat výjimku. Toto omezení není uloženo u klientů připojujících se k frontám pomocí rozhraní API založeného na REST.
• pokud potřebujete více než 10 000 front v jednom oboru názvů Service Bus, můžete kontaktovat tým podpory Azure a požádat o zvýšení. pokud chcete škálovat více než 10 000 front pomocí Service Bus, můžete také vytvořit další obory názvů pomocí Azure Portal.

Správa a operace

v této části jsou porovnávány funkce pro správu, které poskytuje Storage fronty a Service Bus fronty.

Další informace

• fronty Storage poskytují podporu pro libovolné atributy, které lze použít na popis fronty, ve formě párů název/hodnota.
• Obě technologie front nabízejí možnost prohlížet zprávu, aniž by ji museli zamknout, což může být užitečné při implementaci Průzkumníka/nástroje fronty.
• rozhraní api pro zprostředkované zasílání zpráv Service Bus používají plně duplexní připojení TCP pro zlepšení výkonu ve srovnání s REST přes protokol HTTP a podporují standardní protokol AMQP 1,0.
• názvy front Storage můžou být 3-63 znaků dlouhé, můžou obsahovat malá písmena, číslice a spojovníky. Další informace najdete v tématu pojmenování front a metadat.
• názvy front Service Bus mohou mít délku až 260 znaků a mají méně omezující pravidla pojmenování. názvy front Service Bus můžou obsahovat písmena, číslice, tečky, spojovníky a podtržítka.

Ověřování a autorizace

tato část popisuje funkce pro ověřování a autorizaci, které podporuje Storage fronty a Service Bus fronty.

Další informace

• Každý požadavek na jednu z technologií služby Řízení front zpráv musí být ověřen. Veřejné fronty s anonymním přístupem se nepodporují. Pomocí SASmůžete vyřešit tento scénář publikováním SAS pouze pro zápis, SAS jen pro čtení nebo i pomocí SAS s úplným přístupem.
• schéma ověřování poskytované Storage frontami zahrnuje použití symetrického klíče. Tento klíč je ověřovací kód zprávy založený na hodnotě hash (HMAC), vypočítaný pomocí algoritmu SHA-256 a zakódovaný jako řetězec Base64 . další informace o příslušném protokolu najdete v tématu ověřování pro službu Azure Storage Services. fronty Service Bus podporují podobný model pomocí symetrických klíčů. Další informace najdete v tématu ověřování pomocí sdíleného přístupového podpisu s Service Bus.

Závěr

Díky lepšímu porozumění těmto dvěma technologiím si můžete učinit podrobnější rozhodnutí o tom, která technologie fronty se má použít, a kdy. rozhodnutí o tom, kdy používat fronty Storage nebo Service Bus fronty, je jasně závislá na mnoha faktorech. Tyto faktory můžou záviset na jednotlivých potřebách vaší aplikace a její architektury.

můžete chtít zvolit Storage fronty z důvodů, jako jsou následující:

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

fronty Service Bus poskytují mnoho pokročilých funkcí, jako jsou následující. To může být Upřednostňovaná volba, pokud vytváříte hybridní aplikaci nebo pokud vaše aplikace jinak vyžaduje tyto funkce.

• Relace
• Transakce
• Vyhledávání duplicit
• Automatické nedoručené písmeno
• Trvalé možnosti publikování a odběru

Další kroky

v následujících článcích najdete další doprovodné materiály a informace o používání front 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 zlepšení výkonu pomocí Service Bus zprostředkovaných zpráv