Tárolási üzenetsorok és Service Bus-üzenetsorok – összehasonlítva és összehasonlítva
Ez a cikk a Microsoft Azure által kínált két üzenetsortípus, a Storage-üzenetsorok és a Service Bus-üzenetsorok közötti különbségeket és hasonlóságokat elemzi. 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. Nagy mennyiségű üzenet tárolását teszik lehetővé. 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, a tárfiókok teljes kapacitásának korlátig. Az üzenetsorokat általában aszinkron feldolgozásra szolgáló hátralékok létrehozására használják. 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. Úgy lettek kialakítva, hogy olyan alkalmazásokat vagy alkalmazás-összetevőket integráljanak, 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 ü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 üzenetsor üzeneteinek feldolgozásának előrehaladását. Ez akkor hasznos, ha az üzenetet feldolgozó feldolgozó összeomlik. Ezután egy másik feldolgozó felhasználhatja ezt az információt arra, hogy onnan folytassa a munkát, ahol az előző munkavállaló 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 megfontolnia a Service Bus-üzenetsorok használatát , ha:
- A megoldásnak üzeneteket kell fogadnia anélkül, hogy le kellene kérdeznie az üzenetsort. A Service Bus használatával ezt 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 történő kézbesítést (FIFO) biztosítson.
- A megoldásnak támogatnia kell az automatikus duplikátumészlelést.
- Azt szeretné, hogy az alkalmazás párhuzamosan futó, hosszú ideig futó streamekként dolgozza fel az üzeneteket (az üzenetek egy adatfolyamhoz 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, nem pedig az üzenetekért. Amikor streamet ad egy felhasználó csomópontnak, a csomópont tranzakciók használatával megvizsgálhatja az alkalmazás streamá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ó, 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 méretű üzeneteket képesek kezelni).
- Azzal a követelménnyel 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óért tekintse át 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.
- Egy végleges migrálást képzel el az üzenetsor-alapú pont–pont kommunikációról egy közzétételi-feliratkozási üzenetkezelési mintára. Ez a minta lehetővé teszi a további fogadók (előfizetők) integrációját. Minden fogadó megkapja az üzenetsorba küldött üzenetek egy részének vagy mindegyikének független másolatait.
- 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.
Storage-ü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 a Storage-üzenetsorok és a Service Bus-üzenetsorok által biztosított alapvető üzenetsor-kezelési képességeket hasonlítja össze.
| Összehasonlítási feltételek | Tárolási üzenetsorok | Service Bus-üzenetsorok |
|---|---|---|
| Megrendelési garancia | No További információt a További információk szakasz első megjegyzésében talál. |
Igen – Elsőként 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 (ReceiveAndDelete fogadási mód használatával) 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 technikát) Nem blokkoló (csak .NET által felügyelt API használatával) |
| 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á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 felszabadíthat egy üzenetbérletet.) |
30 másodperc (alapértelmezett) Az üzenetzárat bármikor megújíthatja ugyanazon zárolási időtartamon belül manuálisan, 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. |
| Bérlet/Zárolás pontossága | Üzenetszint Az egyes üzenetek eltérő időtúllépési értékkel rendelkezhetnek, 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 | Yes (az üzenetek számának explicit megadása az üzenetek lekérésekor, legfeljebb 32 üzenettel) |
Yes (implicit módon engedélyez egy előlehívási tulajdonságot, 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 sorrendjük is lehet. 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. Ha 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ó lefejezhesse azt. Ekkor előfordulhat, hogy az újonnan látható üzenet az üzenetsorba kerül, és ismét le lesz vonva.
- A Garantált FIFO-minta a Service Bus-üzenetsorokban üzenetkezelési munkamenetek használatát igényli. 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ó elfogadja az üzenetküldési munkamenetet, a sikertelen üzenettel kezdődik az üzenet élettartamának (TTL) 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 az alábbiakra:
- Az alkalmazás összetevőinek 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 folyamatá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 egyszer címkézik más szállító termékeiben történő feldolgozáskor . A tranzakciós hibák nyilvánvalóan az üzenetek újraküldését okozzák, ezért a kifejezés nem teljesen megfelelő.
- A tárolási üzenetsorok egységes és konzisztens programozási modellt biztosítanak az üzenetsorok, táblák és blobok között – mind a fejlesztők, mind az üzemeltetési csapatok számára.
- 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) csökkentését az alacsonyabb 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ói 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 üzenetek enqueuing vagy dequeuing értékeként állíthat be. Emellett frissítheti a különböző bérletértékekkel rendelkező üzeneteket futásidőben, és frissítheti az ugyanabban az üzenetsorban lévő üzenetek különböző értékeit. A Service Bus zárolási időtúllépései az üzenetsor metaadataiban vannak meghatározva. 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, ahol az ügyfél kezeli a zárolásmegújítást.
- A Service Bus-üzenetsorokban a fogadást blokkoló művelet 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 felső határa (a fiókok virtualizálása során 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ási feltételek | Tárolási üzenetsorok | Service Bus-üzenetsorok |
|---|---|---|
| Ütemezett kézbesítés | Igen | Yes |
| Automatikus kézbesíthetetlen levelek | Nem | Igen |
| Az üzenetsor élettartam-értékének növelése | Yes (a láthatósági időtúllépés helyben történő frissítésével) |
Yes (dedikált API-függvényen keresztül) |
| Méregüzenetek támogatása | Igen | Yes |
| Helyben történő frissítés | Igen | Yes |
| Kiszolgálóoldali tranzakciónapló | Igen | Nem |
| Tárolási metrikák | Yes 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. Mindegyik valós időben történik, percenként összesítve, és néhány percen belül jelentve attól, ami az éles környezetben történt. További információ: Tudnivalók a Storage Analytics-metrikákról. |
Yes Az Azure Service Bus által támogatott metrikákkal kapcsolatos információkért tekintse meg az Üzenetmetrikákat. |
| Állapotkezelés | No | Igen (Aktív, Letiltva, SendDisabled, ReceiveDisabled. Az állapotokkal kapcsolatos részletekért lásd az üzenetsor állapotát) |
| Automatikus üzenetátadás | 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ó szerint | 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 egyetlen üzenetsorba nyissa az üzenetsort, 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ői 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 azokat az utolsó ismert ellenőrzőpontról dolgozhassa fel, ahelyett, hogy az alapoktól kezdené. 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 kézbesítetlen 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 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 "kézbesítetlen levél" ü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. Emellett 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 üzenetben. 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 Storage-üzenetsorokat és a Service Bus-üzenetsorokat az esetlegesen alkalmazható kapacitások és 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 az üzenetsorok és blobok kombinálásával támogatja a nagymé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 fejléc maximális mérete: 64 KB). A szolgáltatási szinttől függ. |
| Üzenet élettartamának maximális száma | 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 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 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 particionálás a Prémium szinten nem támogatott. 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. Ha a particionálás engedélyezve van, 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 base64 kódolással kódolja az üzenetet, a felhasználói hasznos adat 64 KB helyett legfeljebb 48 KB lehet.
- 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-üzenetsor egyidejű kapcsolatainak 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éréseket, és kivételt kap a híváskód. Ez a korlát nem vonatkozik a REST-alapú API-val az üzenetsorokhoz csatlakozó ügyfelekre.
- Ha több mint 10 000 üzenetsorra van szüksége egyetlen Service Bus-névtérben, felveheti a kapcsolatot az Azure támogatási csapatával, és kérheti a szám 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 az Azure Portal használatával.
Felügyelet és műveletek
Ez a szakasz a Storage-üzenetsorok és a Service Bus-üzenetsorok által biztosított felügyeleti funkciókat hasonlítja össze.
| Ö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 TLS-lel) |
| .NET API | Yes (.NET Storage-ügyfél API) |
Yes (.NET Service Bus API) |
| Natív C++ | Igen | Yes |
| Java API | Igen | Yes |
| PHP API | Igen | Yes |
| Node.js API | Igen | Yes |
| Tetszőleges metaadatok támogatása | Igen | Nem |
| Üzenetsor-elnevezési szabályok | Legfeljebb 63 karakter hosszú (Az üzenetsor nevében szereplő betűknek kisbetűknek kell lenniük.) |
Legfeljebb 260 karakter hosszú (Az üzenetsorok elérési útjai és nevei nem megkülönböztetik a kis- és nagybetűket.) |
| Várólista hosszának lekérése függvény | Yes (Hozzávetőleges érték, ha az üzenetek a TTL-n kívül járnak le törlés nélkül.) |
Yes (Pontos, időponthoz kötött érték.) |
| Betekintő függvény | Igen | Yes |
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 az üzenetekbe, 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 szabvány 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 nevei legfeljebb 260 karakter hosszúak lehetnek, és kevésbé korlátozó elnevezési szabályokkal rendelkeznek. A Service Bus-üzenetsorok nevei betűket, számokat, vesszőket, kötőjeleket és aláhúzásjeleket 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ási 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 | Yes |
További információ
- Az üzenetsor-kezelési technológiák egyikének minden kérését hitelesíteni kell. A névtelen hozzáféréssel rendelkező nyilvános üzenetsorok nem támogatottak.
- Közös hozzáférésű jogosultságkódos (SAS)-hitelesítéssel létrehozhat egy megosztott hozzáférés-engedélyezési szabályt egy üzenetsoron, amely írási, írási és 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. Az Azure AD által visszaadott OAuth 2.0-jogkivonatot használó felhasználók vagy alkalmazások engedélyezése kimagasló biztonságot és egyszerű használatot biztosít a közös hozzáférésű jogosultságkódokkal (SAS) szemben. Az Azure AD-vel nem kell a kódban tárolni a jogkivonatokat, és kockáztatni a potenciális biztonsági réseket. 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 egyértelműen számos tényezőtől függ. Ezek a tényezők nagymértékben függhetnek az alkalmazás és az architektúra egyéni igényeitől.
Érdemes lehet a Storage-üzenetsorokat választani, például az alábbi okok miatt:
- Ha az alkalmazás már használja a Microsoft Azure alapvető képességeit
- Ha alapszintű kommunikációra és üzenetkezelé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 érdemes választani, ha hibrid alkalmazást hoz létre, vagy ha az alkalmazás más módon igényli ezeket a funkciókat.
- Munkamenetek
- Tranzakciók
- Duplikálás észlelése
- Automatikus kézbesíthetetlen levelek
- Tartós közzétételi és előfizetési képességek
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.