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

  • 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 használatával megalapozottabb döntést hozhat arról, hogy melyik megoldás felel meg a legjobban az igényeinek.

Introduction

Azure-támogatás kétféle üzenetsor-mechanizmust alkalmaz: Tárolási üzenetsorok és Service Bus-üzenetsorok.

A tárolási üzenetsorok az Azure Storage-infrastruktúra részét képezik. Lehetővé teszik, hogy nagy mennyiségű üzenetet tároljon. A világ bármely pontjáról elérheti az üzeneteket 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. Az üzenetsorokat gyakran használják az aszinkron feldolgozáshoz használt teendőlista létrehozásához. 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 a sorba állítást, 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. A Service Bus-üzenetsorokról/témakörökről/előfizetésekről további információt a Service Bus-üzenetsorok, témakörök és előfizetések című témakörben talál.

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.

Annak meghatározásakor, hogy melyik sorkezelé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ő üzenet feldolgozásának előrehaladását. Hasznos, ha az üzenetet feldolgozó feldolgozó munkavégző ö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 a 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 az üzenetsor lekérdezése nélkül kell üzeneteket fogadnia. 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ú protokollokkal.
  • A megoldáshoz az üzenetsornak biztosítania kell a garantált első előtti (FIFO) megrendeléses kézbesítést.
  • A megoldásnak támogatnia kell az automatikus duplikált észlelést.
  • Azt szeretné, hogy az alkalmazás párhuzamosan futó, hosszan futó streamekként dolgozza fel az üzeneteket (az üzenetek egy streamhez vannak társítva az üzenet munkamenet-azonosító tulajdonságával). Ebben a modellben a fogyasztó alkalmazás minden csomópontja verseng a streamekért, és nem 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 atomiságot 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 éri el a 256 KB-os vagy az 1 MB-os korlátot (bár a Service Bus-üzenetsorok legfeljebb 100 MB-ig képesek kezelni az üzeneteket).
  • Azzal a követelménysel kell foglalkoznia, hogy szerepköralapú hozzáférési modellt biztosítson az üzenetsorokhoz, valamint különböző jogosultságokat/engedélyeket a feladók és fogadók számára. További információkért lásd a következő cikkeket:
  • Az üzenetsor mérete nem nő 80 GB-nál.
  • Az AMQP 1.0 szabványalapú üzenetkezelési protokollt szeretné használni. Az AMQP-ről további információt a Service Bus AMQP áttekintésében talál.
  • Az üzenetsor-alapú pont–pont kommunikációból egy közzététel-feliratkozás üzenetküldési mintába való végleges migrálást képzel el. Ez a minta lehetővé teszi a további fogadók (előfizetők) integrációját. Minden fogadó független másolatot kap az üzenetsorba küldött egyes üzenetekről vagy az összes üzenetrő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 szüksége lenne a további infrastruktúra-összetevők létrehozására.
  • A megoldásnak üzenetkötegeket kell közzétennie és felhasználnia.

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

A következő szakaszok táblái 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 a Storage-üzenetsorok és a Service Bus-üzenetsorok által biztosított alapvető üzenetsor-kezelési képességeket hasonlítja össze.

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

További információkért tekintse meg a További információk szakaszban található első megjegyzést.
 Igen – Első lépésben (FIFO)

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

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

További információ a különböző fogadási módokról
Atomi műveletek 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 technika")

Nem blokkoló

(csak .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 Betekintő > bérlet Betekintő > zárolás

Fogadás > Törlés
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 használatával megújíthatja vagy felszabadíthatja az üzenetbérletet.)		 30 másodperc (alapértelmezett)

Az üzenetzárat minden alkalommal manuálisan is megújíthatja ugyanahhoz a zárolási időtartamhoz, 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

Az egyes üzenetek eltérő időtúllépési értékkel rendelkezhetnek, amelyet az UpdateMessage API használatával szükség szerint frissíthet az üzenet feldolgozása során.		 Üzenetsor szintje

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

(explicit módon adja meg az üzenetek számát az üzenetek beolvasásakor, legfeljebb 32 üzenettel)		 Igen

(implicit módon egy előleolvasá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ók

  • A Storage-üzenetsorokban lévő üzenetek általában elsőként jelennek meg, de néha előfordulhat, hogy nem lesznek sorrendben. Ha például egy üzenet láthatósági időtúllépési időtartama lejár, mert egy ügyfélalkalmazás összeomlott egy üzenet feldolgozása során. 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érte azt. Ezen a ponton előfordulhat, hogy az újonnan látható üzenet az üzenetsorba kerül, hogy ismét lekérdezhető legyen.
  • A Service Bus-üzenetsorok garantált FIFO-mintája megköveteli az üzenetkezelési munkamenetek használatát. Ha az alkalmazás összeomlik a Betekintő és zárolás módban fogadott üzenetek feldolgozása közben, a következő alkalommal, amikor egy üzenetsor-fogadó elfogadja az üzenetkezelési munkamenetet, a sikertelen üzenettel kezdődik, miután a munkamenet zárolási időtartama lejár.
  • A tárolási üzenetsorok szabványos sorbaállási forgatókönyvek, például a következő helyzetek támogatására lettek kialakítva:
    • 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és simítá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 irányuló tranzakciók használatával. Az ilyen típusú konzisztenciafunkciót néha pontosan akkor címkézik, amikor más gyártók termékeiben dolgoznak fel. 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 konzisztens programozási modellt biztosítanak az üzenetsorok, táblák és BLOB-k 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 üzenetkezelési műveletek számának (és a kapcsolódó költségeknek) a csökkentését a csökkentett kézbesítési garanciáért cserébe.
  • A tárolási üzenetsorok bérleteket biztosítanak az üzenetek bérleteinek meghosszabbításához. Ez a funkció lehetővé teszi, hogy a feldolgozó folyamatok rövid bérleteket tartsanak fenn az üzeneteken. Így ha egy feldolgozó összeomlik, az üzenetet gyorsan újra 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 az üzenet lekérdezésekor vagy lekérdezésekor állíthat be. Emellett futtatáskor frissíthet különböző bérletértékekkel rendelkező üzeneteket, és frissítheti az üzenetek különböző értékeit ugyanabban az üzenetsorban. A Service Bus zárolási időtúllépéseit az üzenetsor metaadatai határozzák meg. Az üzenetzárat 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, amelyben 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 egy üzenetsor-ügyfél több üzenetet kötegeljen egyetlen küldési műveletbe. A kötegelés csak aszinkron küldési műveletekhez érhető el.
  • Az olyan funkciók, mint a Storage-üzenetsorok 200 TB-os plafonja (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 biztosított speciális képességeket hasonlítja össze.

Összehasonlító feltételek Tárolási üzenetsorok Service Bus queues
Ütemezett kézbesítés Igen Igen
Automatikus holtbetűsítés Nem Igen
Az üzenetsor élettartamának növelése Igen

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

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

A percmetrikák valós idejű metrikákat biztosítanak a rendelkezésre álláshoz, a TPS-hez, az API-hívások számához, a hibaszámokhoz és egyebekhez. Ezek 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 a 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, Letiltott, SendDisabled, ReceiveDisabled. Az állapotokkal kapcsolatos részletekért lásd : Üzenetsor állapota)
Automatikus üzenetátvétel Nem Igen
Üzenetsor kiürítése függvény Igen Nem
Üzenetcsoportok Nem Igen

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

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

További információk

  • Mindkét sorba állítási technológia lehetővé teszi, hogy egy üzenet későbbi kézbesítésre legyen ütemezve.
  • Az üzenetsor automatikus befelé történő beállítása lehetővé teszi, hogy több ezer üzenetsor automatikusan egy üzenetsorba nyissa az üzeneteket, amelyből a fogadó alkalmazás felhasználja az üzenetet. Ezzel a mechanizmussal biztonságos, szabályozható a folyamat, é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 üzenettartalmak frissítését. Ezzel a funkcióval megőrizheti az állapotinformációkat és a növekményes előrehaladási frissítéseket az üzenetben, hogy azok az utolsó ismert ellenőrzőpontról dolgozhatók fel, ahelyett, hogy az alapoktól indulnak. A Service Bus-üzenetsorokkal ugyanezt a forgatókönyvet engedélyezheti üzenet-munkamenetek használatával. További információ: Üzenet munkamenet állapota.
  • A Service Bus-üzenetsorok támogatják a halott betűket. 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 azt 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 lejár a TTL-időszak.
  • Ha "méreg" üzeneteket szeretne keresni a Storage-üzenetsorokban, egy ü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 "holt betű" üzenetsorba.
  • A tárolási üzenetsorok lehetővé teszik, hogy részletes naplót kapjon az üzenetsoron végrehajtott összes tranzakcióról és az összesített metrikákról. 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 logikai csoporthoz tartozó üzenetek fogadóhoz való társításához. 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 a munkamenet-azonosító tulajdonságot egy üzeneten. A fogadók ezután meghallgathatnak 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 Tárolási üzenetsorokat és a Service Bus-üzenetsorokat az esetlegesen alkalmazható kapacitás és kvóták szempontjából.

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

(egyetlen tárfiók kapacitására korlátozódik)		 1 GB-ról 80 GB-ra

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

(48 KB a Base 64 kódolás használatakor)

Azure-támogatás a nagy üzeneteket az üzenetsorok és a blobok kombinálásával – 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 fejléc maximális mérete: 64 KB).

A szolgáltatási szinttől függ.
Üzenet maximális TTL-je Végtelen (api-verzió: 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ók

  • A Service Bus kényszeríti az üzenetsor méretkorlátjait. Az üzenetsor létrehozásakor meg van adva a várólista 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 rendszer további bejövő üzeneteket is elutasít, és a hívó kivételt kap. A Service Bus kvótáiról további információt a Service Bus kvótái című témakörben talál.
  • 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 az entitás 16 példányát (16 partícióját) hozza létre, amelyek mindegyike azonos méretű. Így ha 5 GB méretű üzenetsort hoz létre, 16 partícióval a várólista maximális mérete (5 * 16) = 80 GB lesz. A particionált üzenetsor vagy témakör maximális méretét az Azure Portalon tekintheti meg.
  • Tárolási üzenetsorok esetén, ha az üzenet tartalma nem XML-biztonságos, akkor base64 kódolásúnak kell lennie. Ha a Base64 kódolja az üzenetet, a felhasználói hasznos adatok 64 KB helyett legfeljebb 48 KB-ot tartalmazhatnak.
  • A Service Bus-üzenetsorok esetében az üzenetsorokban tárolt összes üzenet két részből áll: 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 való egyidejű kapcsolatok maximális száma 100-ra korlátozódik. Ez a szám meg van osztva a feladók és a fogadók között. Ha eléri ezt a kvótát, a rendszer elutasítja a további kapcsolatokra vonatkozó kérelmeket, és kivételt kap a híváskó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 csapatával, és kérhet növekedést. Ha több mint 10 000 üzenetsort szeretne skálázni a Service Bus használatával, további névtereket is létrehozhat az Azure Portal használatával.

Felügyelet és műveletek

Ez a szakasz a Tárolási üzenetsorok és a Service Bus-üzenetsorok által biztosított felügyeleti funkciókat hasonlítja össze.

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

AMQP 1.0 Standard (TCP TLS-lel)
.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ályai Legfeljebb 63 karakter hosszú

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

(Az üzenetsor elérési útjai és nevei nem érzékenyek a kis- és nagybetűkre.)
Üzenetsor hossza függvény lekérése Igen

(Hozzávetőleges érték, ha az üzenetek a TTL-n túl járnak le 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ók

  • 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 által közvetített üzenetkezelési API-k teljes kétoldalas TCP-kapcsolatokat használnak a jobb teljesítmény érdekében a HTTP-n keresztüli REST-hez képest, é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ó: Elnevezési üzenetsorok és metaadatok.
  • A Service Bus-üzenetsorok neve legfeljebb 260 karakter hosszú lehet, és kevésbé korlátozó elnevezési szabályokkal rendelkezik. A Service Bus-üzenetsorok neve tartalmazhat betűket, számokat, pontokat, kötőjeleket és aláhúzásjeleket.

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

Ez a szakasz a Tárolási ü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 queues
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ók

  • A sorba állítási technológiák bármelyikére irányuló kéréseket 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ód (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 a Microsoft Entra ID használatával. A Microsoft Entra ID által visszaadott OAuth 2.0 jogkivonatot használó felhasználók vagy alkalmazások engedélyezése kiváló biztonságot és egyszerű használatot biztosít a közös hozzáférésű jogosultságkódokkal (SAS) szemben. A Microsoft Entra-azonosítóval nincs szükség a jogkivonatok kódban való tárolására, és nem kockáztathatja a biztonsági réseket. További információ: Azure Storage – Microsoft Entra-hitelesítés és Azure Service Bus – Microsoft Entra-hitelesítés.

Összefoglalás

A két technológia mélyebb megismerésével megalapozottabb döntést hozhat arról, hogy melyik üzenetsor-technológiát és mikor érdemes használni. A Storage-üzenetsorok vagy a Service Bus-üzenetsorok használatának eldöntése egyértelműen számos tényezőtől függ. Ezek a tényezők nagymértékben függenek az alkalmazás és architektúrája egyedi igényeitől.

Érdemes lehet a Storage-üzenetsorokat választani az alábbi okokból:

  • 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ébként igényli ezeket a funkciókat.

További 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.