Udostępnij za pośrednictwem

Porównanie i rozróżnienie kolejek magazynowych i kolejek usługi Service Bus

  • Artykuł

W tym artykule przedstawiono różnice i podobieństwa między dwoma typami kolejek oferowanych przez platformę Microsoft Azure: kolejki usługi Storage i kolejki usługi Service Bus. Korzystając z tych informacji, możesz podjąć bardziej świadomą decyzję o tym, które rozwiązanie najlepiej spełnia Twoje potrzeby.

Wprowadzenie

Azure obsługuje dwa typy mechanizmów kolejki: Kolejki magazynu i Kolejki usługi Service Bus.

Kolejki magazynu są częścią infrastruktury usługi Azure Storage . Umożliwiają one przechowywanie dużej liczby komunikatów. Uzyskujesz dostęp do komunikatów z dowolnego miejsca na świecie za pośrednictwem uwierzytelnionych wywołań przy użyciu protokołu HTTP lub HTTPS. Komunikat kolejki może mieć rozmiar do 64 KB. Kolejka może zawierać miliony komunikatów, aż do całkowitego limitu pojemności konta magazynowego. Kolejki są często używane do tworzenia listy prac w celu asynchronicznego przetwarzania. Aby uzyskać więcej informacji, zobacz Co to są kolejki usługi Azure Storage.

Kolejki usługi Service Bus są częścią szerszej infrastruktury obsługi komunikatów platformy Azure, która obsługuje kolejkowanie, publikowanie/subskrybowanie i bardziej zaawansowane wzorce integracji. Są one przeznaczone do integrowania aplikacji lub składników aplikacji, które mogą obejmować wiele protokołów komunikacyjnych, kontraktów danych, domen zaufania lub środowisk sieciowych. Aby uzyskać więcej informacji na temat kolejek/tematów/subskrypcji usługi Service Bus, zobacz kolejki, tematy i subskrypcje usługi Service Bus.

Zagadnienia dotyczące wyboru technologii

Kolejki usługi Storage i kolejki usługi Service Bus mają nieco inny zestaw funkcji. Możesz wybrać jedną lub obie, w zależności od potrzeb konkretnego rozwiązania.

Podczas określania, która technologia kolejkowania pasuje do celu danego rozwiązania, architekci rozwiązań i deweloperzy powinni rozważyć te zalecenia.

Rozważ użycie kolejek przechowywania

Jako architekt rozwiązań/deweloper powinieneś rozważyć użycie kolejek Storage gdy:

  • Aplikacja musi przechowywać ponad 80 gigabajtów komunikatów w kolejce.
  • Aplikacja chce śledzić postęp przetwarzania komunikatu w kolejce. Jest to przydatne, gdy pracownik przetwarzający wiadomość ulega awarii. Inny proces roboczy może następnie użyć tych informacji, aby kontynuować od miejsca, w którym poprzedni pracownik opuścił.
  • Wymagane są logi po stronie serwera wszystkich operacji na kolejkach.

Rozważ użycie kolejek usługi Service Bus

Jako architekt rozwiązań/deweloper należy rozważyć użycie kolejek usługi Service Bus, gdy:

  • Twoje rozwiązanie musi odbierać komunikaty bez potrzeby sondowania kolejki. Dzięki usłudze Service Bus można to osiągnąć, korzystając z operacji odbierania w trybie długiego sondowania i protokołów opartych na TCP, które obsługuje usługa Service Bus.
  • Rozwiązanie wymaga, aby kolejka zapewniała gwarantowane dostarczanie według zasady pierwszy na wejściu, pierwszy na wyjściu (FIFO).
  • Rozwiązanie musi obsługiwać automatyczne wykrywanie duplikatów.
  • Chcesz, aby Twoja aplikacja przetwarzała komunikaty jako równoległe długotrwale działające strumienie (komunikaty są skojarzone ze strumieniem przy użyciu właściwości identyfikatora sesji w komunikacie). W tym modelu każdy węzeł w aplikacji korzystającej konkuruje ze strumieniami, w przeciwieństwie do komunikatów. Gdy strumień zostanie przekazany do węzła konsumpcyjnego, węzeł może zbadać stan strumienia aplikacji za pomocą transakcji.
  • Rozwiązanie wymaga zachowania transakcyjnego i atomiczności podczas odbierania lub wysyłania wielu komunikatów z kolejki.
  • Aplikacja obsługuje komunikaty, które mogą przekraczać 64 KB, ale prawdopodobnie nie zbliży się do limitu 256 KB lub 1 MB, w zależności od wybranej warstwy usługi (chociaż kolejki usługi Service Bus mogą obsługiwać komunikaty do 100 MB).
  • Zajmujesz się wymaganiem, które wymaga zapewnienia modelu dostępu opartego na rolach do kolejek oraz różnych praw/uprawnień dla nadawców i odbiorców. Aby uzyskać więcej informacji, zobacz następujące artykuły:
  • Rozmiar kolejki nie będzie większy niż 80 GB.
  • Chcesz użyć protokołu obsługi komunikatów opartych na standardach protokołu AMQP 1.0. Aby uzyskać więcej informacji na temat protokołu AMQP, zobacz Service Bus AMQP Overview (Omówienie protokołu AMQP w usłudze Service Bus).
  • Przewidujesz ostateczną migrację z komunikacji punkt-punkt opartej na kolejce na wzorzec komunikacji typu publikacja-subskrypcja. Ten wzorzec umożliwia integrację dodatkowych odbiorników (subskrybentów). Każdy odbiorca otrzymuje oddzielne kopie niektórych lub wszystkich komunikatów wysyłanych do kolejki.
  • Rozwiązanie do obsługi komunikatów musi obsługiwać gwarancje dostarczania "Co najwyżej raz" i "Co najmniej raz" bez konieczności tworzenia dodatkowych składników infrastruktury.
  • Rozwiązanie musi publikować i wykorzystywać partie komunikatów.

Porównaj kolejki Storage i kolejki Service Bus

Tabele w poniższych sekcjach zawierają logiczne grupowanie funkcji kolejki. Umożliwiają one porównanie możliwości dostępnych zarówno w kolejkach usługi Azure Storage, jak i w kolejkach usługi Service Bus.

Podstawowe możliwości

W tej sekcji porównujemy niektóre z podstawowych możliwości kolejkowania udostępnianych przez Azure Storage queues i kolejki usługi Service Bus.

Kryteria porównania Kolejki magazynu Kolejki Service Bus
Gwarancja zamawiania Nie

Aby uzyskać więcej informacji, zobacz pierwszą notatkę w sekcji Dodatkowe informacje .
 Tak — pierwsze weszło, pierwsze wyszło (FIFO)

(przy użyciu sesji wiadomości)
Gwarancja dostarczania Co najmniej raz Co najmniej raz (przy użyciu trybu odbierania PeekLock. Jest to wartość domyślna)

Co najwyżej raz (przy użyciu trybu odbierania ReceiveAndDelete)

Dowiedz się więcej o różnych trybach odbierania
Obsługa operacji atomowych Nie. Tak
Zachowanie odbiorcze Nieblokujący

(kończy się natychmiast, jeśli nie znaleziono nowego komunikatu)		 Blokowanie z limitem czasu lub bez limitu czasu

(oferuje długie sondowanie lub "technikę Comet")

** Nieblokujący

(tylko przy użyciu zarządzanego interfejsu API platformy .NET)
Interfejs API typu push Nie. Tak

Nasze zestawy SDK dla .NET, Java, JavaScript i Go udostępniają interfejs API typu push.
Tryb odbierania Podgląd i dzierżawa Zaglądaj i blokuj

Odbierz i usuń
Tryb wyłącznego dostępu Oparte na dzierżawie Oparte na blokadach
Czas trwania dzierżawy/blokady 30 sekund (ustawienie domyślne)

7 dni (maksimum) (można odnowić lub zwolnić dzierżawę komunikatów przy użyciu interfejsu API UpdateMessage ).		 30 sekund (ustawienie domyślne)

Możesz odnawiać blokadę komunikatów ręcznie na tę samą długość czasu, lub skorzystać z funkcji automatycznego odnawiania blokady, w której klient zarządza odnawianiem blokady za Ciebie.
Precyzja dzierżawy/blokowania Poziom komunikatu

Każdy komunikat może mieć inną wartość limitu czasu, którą można następnie zaktualizować zgodnie z potrzebami podczas przetwarzania komunikatu przy użyciu interfejsu API UpdateMessage .		 Poziom kolejki

(każda kolejka ma dokładność blokady zastosowaną do wszystkich komunikatów, ale blokada może zostać odnowiona zgodnie z opisem w poprzednim wierszu)
Odbieranie wsadowe Tak

(jawne określanie liczby komunikatów podczas pobierania komunikatów, maksymalnie 32 komunikatów)		 Tak

(niejawnie włączanie właściwości pobierania wstępnego lub jawnie przy użyciu transakcji)
Wysyłanie wsadowe Nie. Tak

(przy użyciu transakcji lub grupowania po stronie klienta)

Dodatkowe informacje

  • Wiadomości w kolejkach pamięci masowej są zazwyczaj przetwarzane według zasady "pierwsze weszło, pierwsze wyszło", ale czasami mogą wyjść poza kolejność. Na przykład po wygaśnięciu czasu widoczności komunikatu, ponieważ aplikacja kliencka uległa awarii podczas przetwarzania komunikatu. Po wygaśnięciu limitu czasu widoczności komunikat staje się ponownie widoczny w kolejce, aby kolejny pracownik mógł ją ponownie pobrać. W tym momencie nowo widoczna wiadomość może zostać umieszczona w kolejce do ponownego wyjęcia z niej.
  • Gwarantowany wzorzec FIFO w kolejkach usługi Service Bus wymaga użycia sesji wiadomości. Jeśli aplikacja ulegnie awarii podczas przetwarzania wiadomości odebranej w trybie Podgląd i blokada, następnym razem, gdy odbiornik kolejki zaakceptuje sesję wiadomości, rozpocznie przetwarzanie od wiadomości, która zakończyła się niepowodzeniem po wygaśnięciu czasu trwania blokady sesji.
  • Kolejki pamięci są przeznaczone do wspierania standardowych scenariuszy kolejkowania, takich jak następujące:
    • Oddzielenie składników aplikacji w celu zwiększenia skalowalności i tolerancji awarii
    • Wyrównywanie obciążenia
    • Tworzenie przepływów procesów.
  • Niespójności dotyczące obsługi komunikatów w kontekście sesji usługi Service Bus można uniknąć, używając stanu sesji do przechowywania stanu aplikacji w stosunku do postępu obsługi sekwencji komunikatów sesji oraz przy użyciu transakcji dotyczących rozliczenia odebranych komunikatów i aktualizowania stanu sesji. Ta funkcja spójności jest czasami oznaczona etykietą dokładnie raz przetwarzania w produktach innych dostawców. Wszelkie błędy transakcji będą oczywiście powodować ponowne dostarczanie komunikatów i dlatego ten termin nie jest do końca adekwatny.
  • Kolejki magazynowania zapewniają jednolity i spójny model programowania w kolejkach, tabelach i BLOB-ach — zarówno dla deweloperów, jak i zespołów operacyjnych.
  • Kolejki systemu Service Bus zapewniają obsługę transakcji lokalnych w kontekście pojedynczej kolejki.
  • Tryb odbierania i usuwania obsługiwany przez usługę Service Bus umożliwia zmniejszenie liczby operacji obsługi komunikatów (i skojarzonych kosztów) w zamian za obniżoną gwarancję dostarczania.
  • Kolejki pamięci masowej zapewniają dzierżawom możliwość przedłużania okresu dzierżawy komunikatów. Ta funkcja umożliwia procesom roboczym utrzymywanie krótkich dzierżaw na wiadomościach. W związku z tym, jeśli proces roboczy ulegnie awarii, komunikat można szybko przetworzyć ponownie przez innego procesu roboczego. Ponadto pracownik może rozszerzyć dzierżawę na komunikat, jeśli musi przetworzyć go dłużej niż bieżący czas dzierżawy.
  • Kolejki magazynu oferują limit czasu widoczności, który można ustawić podczas kolejkowania lub usuwania kolejkowania komunikatu. Ponadto można zaktualizować komunikat o różnych wartościach dzierżawy w czasie wykonywania i zaktualizować różne wartości między komunikatami w tej samej kolejce. Limit czasu blokady usługi Service Bus jest definiowany w danych o kolejce. Można jednak ręcznie odnowić blokadę komunikatów dla wstępnie zdefiniowanego czasu trwania blokady lub użyć funkcji automatycznego odnawiania blokady, w której klient zarządza odnawianiem blokady.
  • Maksymalny limit czasu dla blokowania operacji odbierania w kolejkach usługi Service Bus wynosi 24 dni. Jednak limity czasu oparte na protokole REST mają maksymalną wartość 55 sekund.
  • Przetwarzanie wsadowe po stronie klienta udostępniane przez usługę Service Bus umożliwia klientowi kolejki dzielenie wielu komunikatów na partie w jedną operację wysyłania. Przetwarzanie wsadowe jest dostępne tylko dla operacji wysyłania asynchronicznego.
  • Funkcje, takie jak pułap 200 TB dla kolejek przechowywania (więcej, gdy wirtualizujesz konta) i nieograniczona liczba kolejek sprawiają, że jest to idealna platforma dla dostawców SaaS.
  • Kolejki przechowywania zapewniają elastyczny i wydajny mechanizm kontroli dostępu delegowanego.

Zaawansowane możliwości

W tej sekcji porównaliśmy zaawansowane możliwości zapewniane przez kolejki usługi Storage i kolejki usługi Service Bus.

Kryteria porównania Kolejki magazynu Kolejki usługi Service Bus
Zaplanowane dostarczanie Tak Tak
Automatyczne oznaczanie jako nieprzetwarzalne Nie. Tak
Zwiększanie wartości czasu kolejki na żywo Tak

(poprzez aktualizację czasu wygaśnięcia widoczności na miejscu)		 Tak

(udostępniane za pośrednictwem dedykowanej funkcji interfejsu API)
Obsługa komunikatów zatrutych Tak Tak
Aktualizacja na miejscu Tak Tak
Dziennik transakcji po stronie serwera Tak Nie.
Metryki magazynu Tak

Metryki minut udostępniają metryki czasu rzeczywistego dotyczące dostępności, TPS, liczby wywołań interfejsu API, liczby błędów i nie tylko. Wszystkie one są w czasie rzeczywistym, zagregowane na minutę i zgłaszane w ciągu kilku minut od tego, co właśnie wydarzyło się w środowisku produkcyjnym. Aby uzyskać więcej informacji, zobacz Informacje o metrykach analityki magazynu.		 Tak

Aby uzyskać informacje o metrykach obsługiwanych przez usługę Azure Service Bus, zobacz Metryki komunikatów.
Zarządzanie stanem Nie. Tak (Aktywne, Wyłączone, WysyłanieWyłączone, OdbieranieWyłączone. Aby uzyskać szczegółowe informacje na temat tych stanów, zobacz Stan kolejki)
Automatyczne przekazywanie wiadomości Nie. Tak
Funkcja czyszczenia kolejki Tak Tak
Grupy komunikatów Nie. Tak

(przy użyciu sesji obsługi komunikatów)
Stan aplikacji na grupę komunikatów Nie. Tak
Wykrywanie duplikatów Nie. Tak

(konfigurowalne po stronie nadawcy)
Przeglądanie grup wiadomości Nie. Tak
Pobieranie sesji wiadomości według ID Nie. Tak

Dodatkowe informacje

  • Obie technologie kolejkowania umożliwiają zaplanowanie dostarczania komunikatu w późniejszym czasie.
  • Automatyczne przekierowywanie kolejek umożliwia tysiącom kolejek automatyczne przesyłanie komunikatów do jednej kolejki, z której aplikacja odbiera komunikaty. Korzystając z tego mechanizmu, można zapewnić bezpieczeństwo, kontrolować przepływ oraz izolować przestrzeń magazynową między poszczególnymi wydawcami komunikatów.
  • Kolejki magazynu zapewniają obsługę aktualizowania zawartości komunikatów. Tej funkcji można używać do utrwalania informacji o stanie i przyrostowych aktualizacji postępu do komunikatu, aby można je było przetworzyć z ostatniego znanego punktu kontrolnego, zamiast rozpoczynać od podstaw. Kolejki usługi Service Bus umożliwiają włączenie tego samego scenariusza przy użyciu sesji komunikatów. Aby uzyskać więcej informacji, zobacz Stan sesji komunikatu.
  • Kolejki usługi Service Bus obsługują tworzenie utraconych komunikatów. Może to być przydatne w przypadku izolowania komunikatów spełniających następujące kryteria:
    • Nie można pomyślnie przetworzyć komunikatów przez odbieraną aplikację
    • Komunikaty nie mogą dotrzeć do miejsca docelowego z powodu wygasłej właściwości czasu wygaśnięcia (TTL). Wartość TTL (czas przechowywania) określa, jak długo komunikat pozostaje w kolejce. W usłudze Service Bus komunikat zostanie przeniesiony do specjalnej kolejki o nazwie $DeadLetterQueue po wygaśnięciu okresu TTL (czas życia).
  • Aby znaleźć komunikaty "trucizny" w kolejkach usługi Storage, podczas usuwania komunikatu z kolejki aplikacja sprawdza właściwość DequeueCount komunikatu. Jeśli wartość DequeueCount jest większa niż określony próg, aplikacja przenosi komunikat do zdefiniowanej przez aplikację kolejki „martwych listów”.
  • Kolejki pamięci masowej umożliwiają otrzymanie szczegółowego dziennika wszystkich transakcji wykonywanych w kolejce oraz zbiorczych danych metrycznych. Obie te opcje są przydatne do debugowania i zrozumienia sposobu korzystania z kolejek usługi Storage przez aplikację. Są one również przydatne w przypadku dostosowywania wydajności aplikacji i obniżania kosztów korzystania z kolejek.
  • Sesje komunikatów obsługiwane przez usługę Service Bus umożliwiają skojarzenie komunikatów należących do grupy logicznej z odbiornikiem. Tworzy powiązanie przypominające relację sesyjną między komunikatami a ich odpowiednimi odbiornikami. Tę zaawansowaną funkcję można włączyć w usłudze Service Bus, ustawiając właściwość identyfikatora sesji w komunikacie. Odbiorcy mogą następnie nasłuchiwać określonego identyfikatora sesji i odbierać komunikaty, które współużytkuje określony identyfikator sesji.
  • Funkcja wykrywania duplikacji kolejek usługi Service Bus automatycznie usuwa zduplikowane komunikaty wysyłane do kolejki lub tematu na podstawie wartości właściwości identyfikatora komunikatu.

Pojemność i limity przydziału

W tej sekcji porównujemy kolejki Storage i kolejki Service Bus z perspektywy pojemności i przydziałów, które mogą mieć zastosowanie.

Kryteria porównania Kolejki do przechowywania danych Kolejki Service Bus
Maksymalny rozmiar kolejki 5 PiB

(ograniczone do pojemności jednego konta magazynowego)		 Od 1 GB do 80 GB

(poziom Premium lub Standard z partycjonowaniem)
Maksymalny rozmiar komunikatu 64 KB

(48 KB w przypadku korzystania z kodowania Base 64)

Azure obsługuje duże komunikaty poprzez połączenie kolejek i obiektów blob — dzięki temu można umieścić w kolejce do 200 GB dla pojedynczego elementu.		 256 KB, 1 MB lub 100 MB

(w tym nagłówek i treść, maksymalny rozmiar nagłówka: 64 KB).

Zależy od warstwy usługi.
Maksymalny czas życia komunikatu Nieskończony (api-version 2017-07-27 lub nowszy) TimeSpan.MaxValue
Maksymalna liczba kolejek Nieograniczony 10 000 (Standard)
1000 / Jednostka obsługi komunikatów (warstwa Premium)
(na przestrzeń nazw dla każdej usługi)
Maksymalna liczba równoczesnych klientów Nieograniczony 5,000

Dodatkowe informacje

  • Usługa Service Bus wymusza limity rozmiaru kolejki. Maksymalny rozmiar kolejki jest określany podczas tworzenia kolejki. Może to być od 1 GB do 80 GB. Jeśli rozmiar kolejki osiągnie ten limit, dodatkowe komunikaty przychodzące zostaną odrzucone, a wywołujący otrzyma wyjątek. Aby uzyskać więcej informacji na temat przydziałów w usłudze Service Bus, zobacz Limity przydziału usługi Service Bus.
  • W warstwie Standardowej przesyłania wiadomości można tworzyć kolejki i tematy usługi Service Bus w rozmiarach 1 (wartość domyślna), 2, 3, 4 lub 5 GB. Po włączeniu partycjonowania w warstwie Standardowa usługa Service Bus tworzy 16 kopii (16 partycji) jednostki, z których każdy ma określony rozmiar. W związku z tym, jeśli tworzysz kolejkę o rozmiarze 5 GB, z 16 partycjami maksymalny rozmiar kolejki zmieni się (5 * 16) = 80 GB. Maksymalny rozmiar partycjonowanej kolejki lub tematu można zobaczyć w witrynie Azure Portal.
  • W przypadku kolejek usługi Storage, jeśli zawartość komunikatu nie jest bezpieczna dla kodu XML, musi być zakodowana w formacie Base64 . Jeśli komunikat jest zakodowany w formacie Base64, ładunek użytkownika może mieć maksymalnie 48 KB, a nie 64 KB.
  • W przypadku kolejek usługi Service Bus każdy komunikat przechowywany w kolejce składa się z dwóch części: nagłówka i treści. Całkowity rozmiar komunikatu nie może przekraczać maksymalnego rozmiaru komunikatu obsługiwanego przez warstwę usługi.
  • Gdy klienci komunikują się z kolejkami usługi Service Bus za pośrednictwem protokołu TCP, maksymalna liczba współbieżnych połączeń z pojedynczą kolejką usługi Service Bus jest ograniczona do 100. Ta liczba jest współdzielona między nadawcami i odbiorcami. Jeśli ten limit zostanie osiągnięty, żądania dotyczące dodatkowych połączeń zostaną odrzucone, a kod wywołujący otrzyma wyjątek. Ten limit nie jest nakładany na klientów łączących się z kolejkami przy użyciu interfejsu API opartego na protokole REST.
  • Aby skalować więcej niż 10 000 kolejek za pomocą jednostki Service Bus SKU Standard lub 1000 kolejek/jednostki obsługi komunikatów przy użyciu Service Bus SKU Premium, możesz również utworzyć dodatkowe przestrzenie nazw, korzystając z portalu Azure.

Zarządzanie i operacje

W tej sekcji porównaliśmy funkcje zarządzania udostępniane przez kolejki usługi Storage i kolejki usługi Service Bus.

Kryteria porównania Kolejki magazynu Kolejki w usłudze Service Bus
Protokół zarządzania REST za pośrednictwem protokołu HTTP/HTTPS REST za pośrednictwem protokołu HTTPS
Protokół środowiska uruchomieniowego REST za pośrednictwem protokołu HTTP/HTTPS REST za pośrednictwem protokołu HTTPS

AMQP 1.0 Standard (TCP z protokołem TLS)
.NET API Tak

(Interfejs API klienta usługi Storage platformy .NET)		 Tak

(API usługi Service Bus platformy .NET)
Natywny język C++ Tak Tak
Interfejs API języka Java Tak Tak
PHP API Tak Tak
Interfejs API Node.js Tak Tak
Obsługa dowolnych metadanych Tak Nie.
Zasady nazewnictwa kolejek Długość maksymalnie 63 znaków

(Litery w nazwie kolejki powinny być małymi literami).		 Długość maksymalnie 260 znaków

(Ścieżki i nazwy kolejek są bez uwzględniania wielkości liter).
Uzyskiwanie funkcji długości kolejki Tak

(Przybliżona wartość, jeśli komunikaty wygasają poza TTL bez usuwania).		 Tak

(Dokładna wartość w danym punkcie czasu)
Funkcja podglądu Tak Tak

Dodatkowe informacje

  • Kolejki pamięci masowej zapewniają obsługę dowolnych atrybutów, które można zastosować do opisu kolejki w postaci par nazwa/wartość.
  • Obie technologie kolejkowania oferują możliwość przeglądania komunikatu bez konieczności blokowania go, co może być przydatne podczas implementowania narzędzia eksploratora/przeglądarki kolejek.
  • Interfejsy API obsługi komunikatów .NET w ramach usługi Service Bus używają pełnodupleksowych połączeń TCP dla lepszej wydajności w porównaniu z protokołem REST działającym na HTTP i obsługują standardowy protokół AMQP 1.0.
  • Nazwy kolejek pamięci masowej mogą mieć długość od 3 do 63 znaków, mogą zawierać małe litery, cyfry i łączniki. Aby uzyskać więcej informacji, zobacz Nazewnictwo kolejek i metadanych.
  • Nazwy kolejek usługi Service Bus mogą mieć długość do 260 znaków i mają mniej restrykcyjne reguły nazewnictwa. Nazwy kolejek usługi Service Bus mogą zawierać litery, cyfry, kropki, łączniki i podkreślenia.

Uwierzytelnianie i autoryzacja

W tej sekcji omówiono funkcje uwierzytelniania i autoryzacji obsługiwane przez kolejki Storage i kolejki Service Bus.

Kryteria porównania Kolejki przechowywania Kolejki Service Bus
Uwierzytelnianie Klucz symetryczny i kontrola dostępu oparta na rolach (RBAC) Klucz symetryczny i kontrola dostępu oparta na rolach (RBAC)
Federacja dostawców tożsamości Tak Tak

Dodatkowe informacje

  • Każde żądanie do jednej z technologii kolejkowania musi być uwierzytelnione. Kolejki publiczne z dostępem anonimowym nie są obsługiwane.
  • Korzystając z uwierzytelniania sygnatury dostępu współdzielonego (SAS), można utworzyć regułę autoryzacji dostępu współdzielonego w kolejce, która może zapewnić użytkownikom dostęp tylko do zapisu, tylko do odczytu lub pełnego dostępu. Aby uzyskać więcej informacji, zobacz Azure Storage — uwierzytelnianie SAS i Azure Service Bus — uwierzytelnianie SAS.
  • Obie kolejki obsługują autoryzowanie dostępu przy użyciu identyfikatora Entra firmy Microsoft. Autoryzowanie użytkowników lub aplikacji przy użyciu tokenu OAuth 2.0 zwróconego przez identyfikator Entra firmy Microsoft zapewnia lepsze zabezpieczenia i łatwość użycia za pośrednictwem sygnatur dostępu współdzielonego (SAS). W przypadku identyfikatora Entra firmy Microsoft nie ma potrzeby przechowywania tokenów w kodzie i ryzyka potencjalnych luk w zabezpieczeniach. Aby uzyskać więcej informacji, zobacz Azure Storage — uwierzytelnianie Microsoft Entra oraz Azure Service Bus — uwierzytelnianie Microsoft Entra.

Podsumowanie

Dzięki uzyskaniu głębszego zrozumienia tych dwóch technologii możesz podjąć bardziej świadomą decyzję o tym, która technologia kolejki ma być używana, i kiedy. Decyzja o tym, kiedy należy używać kolejek usługi Storage lub kolejek usługi Service Bus, wyraźnie zależy od wielu czynników. Te czynniki w dużym stopniu zależą od indywidualnych potrzeb aplikacji i jej architektury.

Możesz preferować kolejki pamięci masowej z następujących powodów:

  • Jeśli aplikacja korzysta już z podstawowych możliwości platformy Microsoft Azure
  • Jeśli potrzebujesz podstawowej komunikacji i obsługi komunikatów między usługami
  • Potrzebujesz kolejek, które mogą być większe niż 80 GB rozmiaru

Kolejki usługi Service Bus udostępniają wiele zaawansowanych funkcji, takich jak poniższe. Dlatego mogą one być preferowanym wyborem, jeśli tworzysz aplikację hybrydową lub jeśli aplikacja w inny sposób wymaga tych funkcji.

Następne kroki

Poniższe artykuły zawierają więcej wskazówek i informacji na temat korzystania z kolejek usługi Storage lub kolejek usługi Service Bus.