Tárolási üzenetsorok és Service Bus-üzenetsorok – összehasonlítva és összehasonlítva

  • Cikk

Ez a cikk a Microsoft Azure által kínált két üzenetsortípus közötti különbségeket és hasonlóságokat elemzi: Storage-üzenetsorok és Service Bus-üzenetsorok. Ezen információk segítségével megalapozottabb döntést hozhat arról, hogy melyik megoldás felel meg a legjobban az igényeinek.

Bevezetés

Az Azure kétféle üzenetsor-mechanizmust támogat: tárolási üzenetsorokat és Service Bus-üzenetsorokat.

A tárolási üzenetsorok az Azure Storage-infrastruktúra részét képezik. Lehetővé teszik nagy mennyiségű üzenet tárolását. Az üzeneteket a világ bármely pontjáról elérheti hitelesített hívásokon keresztül HTTP vagy HTTPS használatával. Az üzenetsor-üzenetek mérete legfeljebb 64 KB lehet. Az üzenetsorok több millió üzenetet tartalmazhatnak, akár a tárfiók teljes kapacitáskorlátját is megszabva. Az üzenetsorokat gyakran használják a feladatok hátralékának létrehozására az aszinkron feldolgozáshoz. További információ: Mik azok az Azure Storage-üzenetsorok?

A Service Bus-üzenetsorok egy szélesebb körű Azure üzenetkezelési infrastruktúra részét képezik, amely támogatja az üzenetsorok használatát, a közzétételt/feliratkozást és a fejlettebb integrációs mintákat. Olyan alkalmazásokat vagy alkalmazás-összetevőket integrálnak, amelyek több kommunikációs protokollra, adatszerződésre, megbízhatósági tartományra vagy hálózati környezetre is kiterjedhetnek. További információ a Service Bus-üzenetsorokról/témakörökről/előfizetésekről: Service Bus-üzenetsorok, témakörök és előfizetések.

Technológiai kiválasztási szempontok

A tárolási üzenetsorok és a Service Bus-üzenetsorok funkciókészlete kissé eltérő. Az adott megoldás igényeitől függően választhat egyet vagy mindkettőt.

Amikor meghatározza, hogy melyik üzenetsor-kezelési technológia felel meg egy adott megoldás céljának, a megoldástervezőknek és a fejlesztőknek figyelembe kell venniük ezeket a javaslatokat.

Fontolja meg a Storage-üzenetsorok használatát

Megoldástervezőként/fejlesztőként érdemes megfontolnia a Storage-üzenetsorok használatát , ha:

  • Az alkalmazásnak több mint 80 gigabájtnyi üzenetet kell tárolnia egy üzenetsorban.
  • Az alkalmazás nyomon szeretné követni az üzenetsorban lévő üzenetek feldolgozásának előrehaladását. Hasznos, ha az üzenetet feldolgozó feldolgozó összeomlik. Ezután egy másik feldolgozó felhasználhatja ezeket az információkat, hogy onnan folytassa, ahol az előző feldolgozó abbahagyta.
  • Kiszolgálóoldali naplókra van szükség az üzenetsorokon végrehajtott összes tranzakcióról.

Fontolja meg Service Bus-üzenetsorok használatát

Megoldástervezőként/fejlesztőként érdemes megfontolni a Service Bus-üzenetsorok használatát , ha:

  • A megoldásnak anélkül kell üzeneteket fogadnia, hogy le kellene kérdeznie az üzenetsort. A Service Bus használatával egy hosszú lekérdezéses fogadási művelettel érheti el a Service Bus által támogatott TCP-alapú protokollok használatával.
  • A megoldás megköveteli, hogy az üzenetsor garantált, elsőként kézbesített (FIFO) kézbesítést biztosítson.
  • A megoldásnak támogatnia kell az automatikus duplikált észlelést.
  • Azt szeretné, hogy az alkalmazás párhuzamosan futó, hosszú ideig futó streamekként dolgozza fel az üzeneteket (az üzenetek az üzenet munkamenet-azonosító tulajdonságával vannak társítva egy streamhez). Ebben a modellben a fogyasztó alkalmazás minden csomópontja verseng a streamekért, nem pedig az üzenetekért. Amikor streamet ad egy fogyasztó csomópontnak, a csomópont tranzakciók használatával megvizsgálhatja az alkalmazás streamállapotának állapotát.
  • A megoldás tranzakciós viselkedést és atomitást igényel, amikor több üzenetet küld vagy fogad egy üzenetsorból.
  • Az alkalmazás a választott szolgáltatási szinttől függően kezeli a 64 KB-ot meghaladó üzeneteket, de valószínűleg nem közelíti meg a 256 KB-os vagy 1 MB-os korlátot (bár a Service Bus-üzenetsorok legfeljebb 100 MB-os üzeneteket képesek kezelni).
  • Azzal a követelménysel kell foglalkoznia, hogy szerepköralapú hozzáférési modellt biztosítson az üzenetsorokhoz, valamint különböző jogokat/engedélyeket a feladók és fogadók számára. További információért tekintse át a következő cikkeket:
  • Az üzenetsor mérete nem nő 80 GB-nál nagyobbra.
  • Az AMQP 1.0 szabványalapú üzenetkezelési protokollt szeretné használni. További információ az AMQP-ről: Service Bus AMQP – áttekintés.
  • Az üzenetsor-alapú pont–pont kommunikációból egy közzétételi-feliratkozási üzenetküldési mintába való végleges migrálást fog elképzelni. Ez a minta további fogadók (előfizetők) integrációját teszi lehetővé. Minden fogadó független másolatokat kap az üzenetsorba küldött üzenetek némelyikéről vagy mindegyikéről.
  • Az üzenetkezelési megoldásnak támogatnia kell az "At-Most-Once" és az "At-Least-Once" kézbesítési garanciákat anélkül, hogy további infrastruktúra-összetevőket kellene létrehoznia.
  • A megoldásnak üzenetek kötegeit kell közzétennie és használnia.

Tárolási üzenetsorok és Service Bus-üzenetsorok összehasonlítása

A következő szakaszok táblázatai az üzenetsor-funkciók logikai csoportosítását biztosítják. Egy pillantással összehasonlíthatja az Azure Storage-üzenetsorokban és a Service Bus-üzenetsorokban elérhető képességeket.

Alapvető képességek

Ez a szakasz összehasonlítja a Storage-üzenetsorok és a Service Bus-üzenetsorok által biztosított alapvető üzenetsor-kezelési képességeket.

Összehasonlítási feltételek Tárolási üzenetsorok Service Bus-üzenetsorok
Megrendelési garancia Nem

További információt a További információk szakaszban található első megjegyzésben talál.
 Igen – Első az elsőn kívül (FIFO)

( üzenet-munkamenetek használatával)
Kézbesítési garancia Legalább egyszer At-Least-Once (PeekLock fogadási mód használata). Ez az alapértelmezett)

At-Most-Once (a ReceiveAndDelete fogadási mód használatával)

További információ a különböző fogadási módokról
Atomművelet támogatása Nem Igen
Fogadási viselkedés Nem blokkoló

(azonnal befejeződik, ha nem található új üzenet)		 Blokkolás időtúllépéssel vagy anélkül

(hosszú lekérdezést kínál, vagy az "Üstökös technikát")

Nem blokkoló

(csak a .NET által felügyelt API használata)
Leküldéses stílusú API Nem Igen

A .NET-, Java-, JavaScript- és Go SDK-k leküldéses stílusú API-t biztosítanak.
Fogadási mód Bérlet betekintője & Betekintő & zárolása

Törlés fogadása &
Kizárólagos hozzáférési mód Bérletalapú Zárolásalapú
Bérlet/zárolás időtartama 30 másodperc (alapértelmezett)

7 nap (maximum) (Az UpdateMessage API-val megújíthat vagy kiadhat egy üzenetbérletet.)		 30 másodperc (alapértelmezett)

Az üzenetzárolást bármikor megújíthatja ugyanazzal a zárolási időtartamon belül manuálisan, vagy használhatja az automatikus zárolásmegújítási funkciót, ahol az ügyfél kezeli a zárolásmegújítást.
Bérlet/zárolás pontossága Üzenetszint

Minden üzenetnek más időtúllépési értéke lehet, amelyet szükség szerint frissíthet az üzenet feldolgozása során az UpdateMessage API használatával.		 Üzenetsor szintje

(minden üzenetsor zárolási pontosságot alkalmaz az összes üzenetére, de a zárolás az előző sorban leírtak szerint megújítható)
Kötegelt fogadás Igen

(explicit módon adja meg az üzenetek számát az üzenetek lekérésekor, legfeljebb 32 üzenetig)		 Igen

(implicit módon egy előhívási tulajdonság engedélyezése vagy explicit módon tranzakciók használatával)
Kötegelt küldés Nem Igen

(tranzakciók vagy ügyféloldali kötegelés használatával)

További információ

  • A Storage-üzenetsorokban lévő üzenetek általában elsőként jelennek meg, de néha előfordulhat, hogy sorrendjük nem megfelelő. Ha például egy üzenet láthatósági és időtúllépési időtartama lejár, mert egy ügyfélalkalmazás összeomlott egy üzenet feldolgozása közben. Amikor a láthatósági időtúllépés lejár, az üzenet ismét láthatóvá válik az üzenetsoron, hogy egy másik feldolgozó lekérdezhesse azt. Ekkor előfordulhat, hogy az újonnan látható üzenet az üzenetsorba kerül, és ismét le lesz vonva.
  • A Service Bus-üzenetsorok garantált FIFO-mintája megköveteli az üzenetkezelési munkamenetek használatát. Ha az alkalmazás összeomlik, miközben a Betekintő & zárolási módban fogadott üzenetet dolgoz fel, a következő alkalommal, amikor egy üzenetsor-fogadó elfogad egy üzenetküldési munkamenetet, a sikertelen üzenettel kezdődik a munkamenet zárolási időtartamának lejárta után.
  • A tárolási üzenetsorok szabványos üzenetsor-kezelési forgatókönyvek támogatására lettek kialakítva, például a következő esetekben:
    • Alkalmazásösszetevők leválasztása a hibák skálázhatóságának és tűrésének növelése érdekében
    • Terhelésszintezés
    • Folyamat-munkafolyamatok létrehozása.
  • A Service Bus-munkamenetek kontextusában az üzenetkezeléssel kapcsolatos inkonzisztenciák elkerülhetők azáltal, hogy munkamenet-állapottal tárolják az alkalmazás állapotát a munkamenet üzenetütemezésének kezelésének előrehaladásához képest, valamint a fogadott üzenetek rendezésére és a munkamenet állapotának frissítésére vonatkozó tranzakciók használatával. Az ilyen konzisztenciafunkciót néha pontosan egyszer címkézik más szállító termékeinek feldolgozásakor . A tranzakciós hibák nyilvánvalóan az üzenetek újraküldését okozzák, ezért a kifejezés nem pontosan megfelelő.
  • A tárolási üzenetsorok egységes és egységes programozási modellt biztosítanak az üzenetsorok, táblák és blobok között – fejlesztők és üzemeltetési csapatok számára egyaránt.
  • A Service Bus-üzenetsorok egyetlen üzenetsor kontextusában támogatják a helyi tranzakciókat.
  • A Service Bus által támogatott fogadási és törlési mód lehetővé teszi az üzenetküldési műveletek számának (és a kapcsolódó költségeknek) a csökkentését a kézbesítési garanciáért cserébe.
  • A tárolási üzenetsorok bérleteket biztosítanak az üzenetek bérleteinek meghosszabbítására. Ez a funkció lehetővé teszi, hogy a feldolgozói folyamatok rövid bérleteket tartsanak fenn az üzeneteken. Így ha egy feldolgozó összeomlik, az üzenetet gyorsan feldolgozhatja egy másik feldolgozó. Emellett a feldolgozó meghosszabbíthatja a bérletet egy üzeneten, ha azt az aktuális bérletnél hosszabb ideig kell feldolgoznia.
  • A tárolási üzenetsorok láthatósági időtúllépést biztosítanak, amelyet beállíthat az üzenetek lekérdezésekor vagy törlésekor. Emellett futtatáskor frissíthet különböző bérletértékekkel rendelkező üzeneteket, és különböző értékeket frissíthet az ugyanabban az üzenetsorban lévő üzenetek között. A Service Bus zárolási időtúllépéseit az üzenetsor metaadatai határozzák meg. Az üzenetzárolást azonban manuálisan is megújíthatja az előre meghatározott zárolási időtartamra, vagy használhatja az automatikus zárolásmegújítási funkciót, ahol az ügyfél kezeli a zárolásmegújítást.
  • A Service Bus-üzenetsorok blokkolási fogadási műveletének maximális időtúllépése 24 nap. A REST-alapú időtúllépések maximális értéke azonban 55 másodperc.
  • A Service Bus által biztosított ügyféloldali kötegelés lehetővé teszi, hogy az üzenetsor-ügyfél több üzenetet egyetlen küldési műveletbe köteseljen. A kötegelés csak aszinkron küldési műveletekhez érhető el.
  • Az olyan funkciók, mint a Storage-üzenetsorok 200 TB-os felső határa (a fiókok virtualizálásakor többet), és a korlátlan üzenetsorok ideális platformot biztosítanak az SaaS-szolgáltatók számára.
  • A tárolási üzenetsorok rugalmas és nagy teljesítményű delegált hozzáférés-vezérlési mechanizmust biztosítanak.

Speciális képességek

Ez a szakasz a Storage-üzenetsorok és a Service Bus-üzenetsorok által nyújtott speciális képességeket hasonlítja össze.

Összehasonlítási feltételek Tárolási üzenetsorok Service Bus-üzenetsorok
Ütemezett kézbesítés Igen Igen
Automatikus kézbesítetlen levelek Nem Igen
Az üzenetsor élettartam-értékének növelése Igen

(a láthatóság időtúllépésének helyszíni frissítésével)		 Igen

(dedikált API-függvényen keresztül)
Méregüzenetek támogatása Igen Igen
Helyben történő frissítés Igen Igen
Kiszolgálóoldali tranzakciónapló Igen Nem
Tárolási metrikák Igen

A Minute Metrics valós idejű metrikákat biztosít a rendelkezésre álláshoz, a TPS-hez, az API-hívások számához, a hibák számához és egyebekhez. Mind valós időben vannak, percenként összesítve, és néhány percen belül jelentik az éles környezetben történt eseményeket. További információ: Tudnivalók Storage Analytics metrikákról.		 Igen

Az Azure Service Bus által támogatott metrikákkal kapcsolatos információkért lásd: Üzenetmetrikák.
Állapotkezelés Nem Igen (Aktív, Letiltva, SendDisabled, ReceiveDisabled. Az állapotokkal kapcsolatos részletekért lásd: Üzenetsor állapota)
Automatikus üzenetátvétel Nem Igen
Üzenetsor végleges törlése függvény Igen Nem
Üzenetcsoportok Nem Igen

(üzenetkezelési munkamenetek használatával)
Alkalmazásállapot üzenetcsoportonként Nem Igen
Duplikálás észlelése Nem Igen

(a feladó oldalán konfigurálható)
Böngészési üzenetcsoportok Nem Igen
Üzenet-munkamenetek beolvasása azonosító alapján Nem Igen

További információ

  • Mindkét üzenetsor-kezelési technológia lehetővé teszi az üzenetek későbbi kézbesítésre való ütemezését.
  • Az automatikus üzenetsor-továbbítás lehetővé teszi, hogy több ezer üzenetsor automatikusan egy üzenetsorba nyissa az üzenetsort, amelyből a fogadó alkalmazás felhasználja az üzenetet. Ezzel a mechanizmussal biztonsági és vezérlési folyamatokat érhet el, és elkülönítheti a tárolót az egyes üzenet közzétevők között.
  • A tárolási üzenetsorok támogatják az üzenettartalom frissítését. Ezzel a funkcióval megőrizheti az állapotinformációkat és a növekményes állapotfrissítéseket az üzenetben, hogy az a nulláról kiindulás helyett az utolsó ismert ellenőrzőpontról is feldolgozható legyen. A Service Bus-üzenetsorok esetében ugyanezt a forgatókönyvet üzenet-munkamenetek használatával engedélyezheti. További információ: Üzenet-munkamenet állapota.
  • A Service Bus-üzenetsorok támogatják a kézbesítetlen levelek írását. Az alábbi feltételeknek megfelelő üzenetek elkülönítéséhez lehet hasznos:
    • A fogadó alkalmazás nem tudja sikeresen feldolgozni az üzeneteket
    • Az üzenetek egy lejárt élettartam (TTL) tulajdonság miatt nem érik el a céljukat. A TTL érték határozza meg, hogy egy üzenet mennyi ideig maradjon az üzenetsorban. A Service Bus használatával az üzenet egy $DeadLetterQueue nevű speciális üzenetsorba kerül, amikor a TTL-időszak lejár.
  • Ha "méreg" üzeneteket szeretne keresni a Storage-üzenetsorokban, az üzenet lekérdezésekor az alkalmazás megvizsgálja az üzenet DequeueCount tulajdonságát. Ha a DequeueCount nagyobb egy adott küszöbértéknél, az alkalmazás áthelyezi az üzenetet egy alkalmazás által definiált "kézbesítetlen levél" üzenetsorba.
  • A tárolási üzenetsorok lehetővé teszik az üzenetsoron végrehajtott összes tranzakció és az összesített metrikák részletes naplójának lekérését. Mindkét lehetőség hasznos a hibakereséshez és annak megértéséhez, hogy az alkalmazás hogyan használja a Storage-üzenetsorokat. Az alkalmazás teljesítményhangolásához és az üzenetsorok használatának költségeinek csökkentéséhez is hasznosak.
  • A Service Bus által támogatott üzenet-munkamenetek lehetővé teszik a fogadóhoz társított logikai csoporthoz tartozó üzeneteket. Munkamenet-szerű affinitást hoz létre az üzenetek és a hozzájuk tartozó fogadók között. Ezt a speciális funkciót a Service Busban úgy engedélyezheti, hogy beállítja egy üzenet munkamenet-azonosító tulajdonságát. A fogadók ezután figyelhetnek egy adott munkamenet-azonosítót, és fogadhatnak olyan üzeneteket, amelyek megosztják a megadott munkamenet-azonosítót.
  • A Service Bus-üzenetsorok duplikálásészlelési funkciója automatikusan eltávolítja az üzenetsorba vagy témakörbe küldött ismétlődő üzeneteket az üzenetazonosító tulajdonság értéke alapján.

Kapacitás és kvóták

Ez a szakasz összehasonlítja a Storage-üzenetsorokat és a Service Bus-üzenetsorokat a kapacitás és az esetlegesen alkalmazandó kvóták szempontjából.

Összehasonlítási feltételek Tárolási üzenetsorok Service Bus-üzenetsorok
Üzenetsor maximális mérete 500 TB

( egyetlen tárfiók kapacitására korlátozva)		 1 GB és 80 GB között

(az üzenetsor létrehozásakor és a particionálás engedélyezésekor definiálva – lásd a "További információk" szakaszt)
Üzenet maximális mérete 64 KB

(48 KB Base64 kódolás használatakor)

Az Azure üzenetsorok és blobok kombinálásával támogatja a nagy méretű üzeneteket – ekkor akár 200 GB-ot is leküldhet egyetlen elemhez.		 256 KB vagy 100 MB

(beleértve az élőfejet és a törzset is, a maximális fejlécméret: 64 KB).

A szolgáltatási szinttől függ.
Maximális üzenet TTL-je Infinite (api-version 2017-07-27 vagy újabb) TimeSpan.MaxValue
Üzenetsorok maximális száma Korlátlan 10,000

(szolgáltatásnévtérenként)
Egyidejű ügyfelek maximális száma Korlátlan 5000

További információ

  • A Service Bus kényszeríti az üzenetsor méretkorlátait. Az üzenetsor létrehozásakor meg van adva az üzenetsor maximális mérete. Ez 1 GB és 80 GB között lehet. Ha az üzenetsor mérete eléri ezt a korlátot, a további bejövő üzeneteket a rendszer elutasítja, és a hívó kivételt kap. További információ a Service Bus kvótáiról: Service Bus-kvóták.
  • A Standard üzenetkezelési szinten Service Bus-üzenetsorokat és témaköröket hozhat létre 1 (alapértelmezett), 2, 3, 4 vagy 5 GB-os méretben. Amikor engedélyezi a particionálást a Standard szinten, a Service Bus 16 példányt (16 partíciót) hoz létre az entitásból, amelyek mindegyike azonos méretű. Így ha 5 GB méretű üzenetsort hoz létre, 16 partícióval a maximális üzenetsorméret (5 * 16) = 80 GB lesz. A particionált üzenetsor vagy témakör maximális méretét a Azure Portal tekintheti meg.
  • A Storage-üzenetsorok esetében, ha az üzenet tartalma nem XML-biztonságos, akkor Base64 kódolásúnak kell lennie. Ha Base64-kódolással kódolja az üzenetet, a felhasználó hasznos adatai 64 KB helyett akár 48 KB-ot is tartalmazhatnak.
  • A Service Bus-üzenetsorok esetében az üzenetsorokban tárolt üzenetek két részből állnak: egy fejlécből és egy törzsből. Az üzenet teljes mérete nem haladhatja meg a szolgáltatási szint által támogatott maximális üzenetméretet.
  • Amikor az ügyfelek a TCP protokollon keresztül kommunikálnak a Service Bus-üzenetsorokkal, az egy Service Bus-üzenetsorhoz kapcsolódó egyidejű kapcsolatok maximális száma 100-ra korlátozódik. Ez a szám meg van osztva a feladók és a címzettek között. Ha eléri ezt a kvótát, a rendszer elutasítja a további kapcsolatokra vonatkozó kéréseket, és kivételt kap a hívási kód. Ez a korlát nem vonatkozik az üzenetsorokhoz REST-alapú API-val csatlakozó ügyfelekre.
  • Ha több mint 10 000 üzenetsorra van szüksége egyetlen Service Bus-névtérben, felveheti a kapcsolatot a Azure-támogatás csapattal, és kérheti a növelését. Ha több mint 10 000 üzenetsort szeretne skálázni a Service Bus használatával, további névtereket is létrehozhat a Azure Portal használatával.

Felügyelet és műveletek

Ez a szakasz összehasonlítja a Storage-üzenetsorok és a Service Bus-üzenetsorok által biztosított felügyeleti funkciókat.

Összehasonlítási feltételek Tárolási üzenetsorok Service Bus-üzenetsorok
Felügyeleti protokoll REST HTTP/HTTPS protokollon keresztül REST HTTPS-en keresztül
Futtatókörnyezeti protokoll REST HTTP/HTTPS protokollon keresztül REST HTTPS-en keresztül

AMQP 1.0 Standard (TCP és TLS)
.NET API Igen

(.NET Storage-ügyfél API)		 Igen

(.NET Service Bus API)
Natív C++ Igen Igen
Java API Igen Igen
PHP API Igen Igen
Node.js API Igen Igen
Tetszőleges metaadatok támogatása Igen Nem
Üzenetsor-elnevezési szabályok Legfeljebb 63 karakter hosszú

(Az üzenetsor nevének betűinek kisbetűnek kell lenniük.)		 Legfeljebb 260 karakter hosszú

(Az üzenetsorok elérési útjai és nevei nem érzéketlenek.)
Üzenetsor hossza függvény lekérése Igen

(Hozzávetőleges érték, ha az üzenetek a TTL-t követően lejárnak törlés nélkül.)		 Igen

(Pontos, időponthoz kötött érték.)
Betekintő függvény Igen Igen

További információ

  • A tárolási üzenetsorok támogatják az üzenetsor leírására alkalmazható tetszőleges attribútumokat név/érték párok formájában.
  • Mindkét üzenetsor-technológia lehetővé teszi, hogy zárolás nélkül betekintsen egy üzenetbe, ami hasznos lehet egy üzenetsor-kezelő/böngésző eszköz implementálásakor.
  • A Service Bus .NET közvetítőalapú üzenetküldési API-k teljes kétirányú TCP-kapcsolatokat használnak a HTTP-n keresztüli REST-hez képest jobb teljesítmény érdekében, és támogatják az AMQP 1.0 standard protokollt.
  • A Storage-üzenetsorok nevei 3–63 karakter hosszúak lehetnek, kisbetűket, számokat és kötőjeleket tartalmazhatnak. További információ: Üzenetsorok és metaadatok elnevezése.
  • A Service Bus-üzenetsorok neve legfeljebb 260 karakter hosszú lehet, és kevésbé korlátozó elnevezési szabályokkal rendelkezik. A Service Bus-üzenetsorok nevei betűket, számokat, időszakokat, kötőjeleket és aláhúzásokat tartalmazhatnak.

Hitelesítés és engedélyezés

Ez a szakasz a Storage-üzenetsorok és a Service Bus-üzenetsorok által támogatott hitelesítési és engedélyezési funkciókat ismerteti.

Összehasonlító feltételek Tárolási üzenetsorok Service Bus-üzenetsorok
Hitelesítés Szimmetrikus kulcs és szerepköralapú hozzáférés-vezérlés (RBAC) Szimmetrikus kulcs és szerepköralapú hozzáférés-vezérlés (RBAC)
Identitásszolgáltató összevonása Igen Igen

További információ

  • A sorkezelési technológiák egyikére irányuló minden kérést hitelesíteni kell. A névtelen hozzáféréssel rendelkező nyilvános üzenetsorok nem támogatottak.
  • A közös hozzáférésű jogosultságkódok (SAS) hitelesítésének használatával létrehozhat egy megosztott hozzáférés-engedélyezési szabályt egy üzenetsoron, amely írásvédett, írásvédett vagy teljes hozzáférést biztosíthat a felhasználóknak. További információ: Azure Storage – SAS-hitelesítés és Azure Service Bus – SAS-hitelesítés.
  • Mindkét üzenetsor támogatja a hozzáférés engedélyezését az Azure Active Directory (Azure AD) használatával. A felhasználók vagy alkalmazások Azure AD által visszaadott OAuth 2.0-jogkivonat használatával történő engedélyezése kiváló biztonságot és könnyű használatot biztosít a közös hozzáférésű jogosultságkódokkal (SAS) szemben. A Azure AD esetén nem kell a kódban tárolni a jogkivonatokat, és fennállnak a biztonsági rések. További információ: Azure Storage – Azure AD hitelesítés és Azure Service Bus – Azure AD hitelesítés.

Összegzés

A két technológia mélyebb megértésével megalapozottabb döntést hozhat arról, hogy melyik üzenetsor-technológiát és mikor kell használnia. A Storage-üzenetsorok vagy a Service Bus-üzenetsorok használatának eldöntése számos tényezőtől függ. Ezek a tényezők nagymértékben függhetnek az alkalmazás egyéni igényeitől és architektúrájától.

Érdemes lehet a Storage-üzenetsorokat választani, például a következő okok miatt:

  • Ha az alkalmazás már használja a Microsoft Azure alapvető képességeit
  • Ha alapszintű kommunikációra és üzenetküldésre van szüksége a szolgáltatások között
  • 80 GB-nál nagyobb méretű üzenetsorokra van szükség

A Service Bus-üzenetsorok számos speciális funkciót biztosítanak, például az alábbiakat. Ezért előnyben részesített választás lehet, ha hibrid alkalmazást hoz létre, vagy ha az alkalmazás egyéb módon igényli ezeket a funkciókat.

Következő lépések

Az alábbi cikkek további útmutatást és információt nyújtanak a Storage-üzenetsorok vagy a Service Bus-üzenetsorok használatáról.