Porównanie kolejek magazynu i kolejek usługi Service Bus
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
pomoc techniczna platformy Azure 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 do całkowitego limitu pojemności konta magazynu. 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 magazynu 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 usługi Storage
Jako architekt rozwiązań/deweloper należy rozważyć użycie kolejek usługi 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, jeśli proces roboczy przetwarza komunikat 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ą dzienniki po stronie serwera wszystkich transakcji wykonywanych względem kolejek.
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:
- Rozwiązanie musi odbierać komunikaty bez konieczności sondowania kolejki. Dzięki usłudze Service Bus można to osiągnąć przy użyciu długotrwałej operacji sondowania odbierania przy użyciu protokołów opartych na protokole TCP, które obsługuje usługa Service Bus.
- Rozwiązanie wymaga, aby kolejka zapewniała gwarantowane dostarczanie uporządkowane na pierwszym w pierwszym wyjściu (FIFO).
- Rozwiązanie musi obsługiwać automatyczne wykrywanie duplikatów.
- Aplikacja ma przetwarzać komunikaty jako równoległe strumienie długotrwałe (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 zużywanego, węzeł może zbadać stan stanu strumienia aplikacji przy użyciu transakcji.
- Rozwiązanie wymaga zachowania transakcyjnego i niepodzielności podczas wysyłania lub odbierania 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, aby zapewnić model dostępu opartego na rolach do kolejek oraz różne prawa/uprawnienia 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-punkt na kolejkę ze wzorcem obsługi komunikatów publikowania-subskrybowania. Ten wzorzec umożliwia integrację dodatkowych odbiorników (subskrybentów). Każdy odbiorca odbiera niezależne 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ównanie kolejek magazynu i kolejek usługi 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ównaliśmy niektóre z podstawowych możliwości kolejkowania udostępnianych przez kolejki magazynu i kolejki usługi Service Bus.
| Kryteria porównania | Kolejki magazynu | Kolejki usługi Service Bus |
|---|---|---|
| Gwarancja zamawiania | Nie Aby uzyskać więcej informacji, zobacz pierwszą notatkę w sekcji Dodatkowe informacje . |
Tak — pierwszy na wyjście (FIFO) (przy użyciu sesji komunikatów) |
| 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 niepodzielnych | Nie. | Tak |
| Zachowanie odbierania | Brak blokowania (kończy się natychmiast, jeśli nie znaleziono nowego komunikatu) |
Blokowanie z limitem czasu lub bez limitu czasu (oferuje długie sondowanie lub "technikę komety") Brak blokowania (tylko przy użyciu zarządzanego interfejsu API platformy .NET) |
| Interfejs API w stylu wypychania | Nie. | Tak Nasze zestawy SDK .NET, Java, JavaScript i Go udostępniają interfejs API w stylu wypychania. |
| 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) Blokadę komunikatów można odnowić za każdym razem ręcznie lub użyć funkcji automatycznego odnawiania blokady, w której klient zarządza odnawianiem blokady. |
| 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 przetwarzania wsadowego po stronie klienta) |
Dodatkowe informacje
- Komunikaty w kolejkach usługi Storage są zazwyczaj najpierw na pierwszym wyjęciem, ale czasami mogą być poza kolejnością. Na przykład gdy czas trwania limitu czasu widoczności komunikatu wygaśnie, ponieważ aplikacja kliencka uległa awarii podczas przetwarzania komunikatu. Po wygaśnięciu limitu czasu widoczności komunikat stanie się ponownie widoczny w kolejce, aby inny proces roboczy go zdejmować. W tym momencie nowo widoczny komunikat może zostać umieszczony w kolejce do ponownego usunięcia z kolejki.
- Gwarantowany wzorzec FIFO w kolejkach usługi Service Bus wymaga użycia sesji obsługi komunikatów. Jeśli aplikacja ulegnie awarii podczas przetwarzania komunikatu odebranego w trybie Podgląd i blokada , następnym razem, gdy odbiornik kolejki zaakceptuje sesję obsługi komunikatów, rozpocznie się od komunikatu, który zakończył się niepowodzeniem po wygaśnięciu czasu trwania blokady sesji.
- Kolejki magazynu są przeznaczone do obsługi standardowych scenariuszy kolejkowania, takich jak następujące:
- Oddzielenie składników aplikacji w celu zwiększenia skalowalności i tolerancji awarii
- Bilansowanie obciążenia
- Tworzenie przepływów pracy 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 eliwerowanie komunikatów i dlatego termin nie jest dokładnie odpowiedni.
- Kolejki magazynu zapewniają jednolity i spójny model programowania w kolejkach, tabelach i blokach BLOB — zarówno dla deweloperów, jak i zespołów operacyjnych.
- Kolejki usługi 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 magazynu zapewniają dzierżawom możliwość rozszerzania dzierżaw dla komunikatów. Ta funkcja umożliwia procesom roboczym utrzymywanie krótkich dzierżaw w komunikatach. W związku z tym, jeśli proces roboczy ulegnie awarii, komunikat można szybko przetworzyć ponownie przez innego procesu roboczego. Ponadto proces roboczy 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. Limity czasu blokady usługi Service Bus są definiowane w metadanych kolejki. 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 limit 200 TB kolejek magazynu (więcej w przypadku wirtualizacji kont) i nieograniczone kolejki sprawiają, że jest to idealna platforma dla dostawców SaaS.
- Kolejki magazynu 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 zakleszczenia | Nie. | Tak |
| Zwiększanie wartości czasu kolejki na żywo | Tak (za pośrednictwem aktualizacji w miejscu limitu czasu widoczności) |
Tak (udostępniane za pośrednictwem dedykowanej funkcji interfejsu API) |
| Obsługa komunikatów zatrutych | Tak | Tak |
| Aktualizacja w 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 About analityka magazynu Metrics (Informacje o metrykach analityka 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, SendDisabled, ReceiveDisabled. Aby uzyskać szczegółowe informacje na temat tych stanów, zobacz Stan kolejki) |
| Autoforwarding komunikatów | Nie. | Tak |
| Przeczyszczanie funkcji 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 komunikatów według identyfikatora | Nie. | Tak |
Dodatkowe informacje
- Obie technologie kolejkowania umożliwiają zaplanowanie dostarczania komunikatu w późniejszym czasie.
- Automatyczne skalowanie kolejek umożliwia tysiącom kolejek automatyczne wysyłanie komunikatów do pojedynczej kolejki, z której aplikacja odbierającą korzysta z komunikatu. Za pomocą tego mechanizmu można uzyskać zabezpieczenia, przepływ sterowania i izolować magazyn 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ść czasu wygaśnięcia 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 wygaśnięcia.
- Aby znaleźć komunikaty "trucizny" w kolejkach usługi Storage, podczas kolejkowania komunikatu aplikacja sprawdza właściwość DequeueCount komunikatu. Jeśli wartość DequeueCount jest większa niż określony próg, aplikacja przenosi komunikat do kolejki "utraconych" zdefiniowanych przez aplikację.
- Kolejki magazynu umożliwiają uzyskanie szczegółowego dziennika wszystkich transakcji wykonywanych w kolejce i zagregowanych metryk. 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 koligację przypominającą sesję między komunikatami a 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ównaliśmy kolejki usługi Storage i kolejki usługi Service Bus z perspektywy pojemności i przydziałów , które mogą mieć zastosowanie.
| Kryteria porównania | Kolejki magazynu | Kolejki usługi Service Bus |
|---|---|---|
| Maksymalny rozmiar kolejki | 500 TB (ograniczone do pojemności pojedynczego konta magazynu) |
Od 1 GB do 80 GB (Jednostka SKU w warstwie Premium lub jednostka SKU w warstwie Standardowa z partycjonowaniem) |
| Maksymalny rozmiar komunikatu | 64 KB (48 KB w przypadku korzystania z kodowania Base 64) pomoc techniczna platformy Azure dużych komunikatów przez połączenie kolejek i obiektów blob — w tym momencie można zapisać 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 wygaśnięcia komunikatu | Nieskończony (api-version 2017-07-27 lub nowszy) | TimeSpan.MaxValue |
| Maksymalna liczba kolejek | Nieograniczony | 10 000 (jednostka SKU w warstwie Standardowa) 1000 / Jednostka obsługi komunikatów (jednostka SKU Premium) (na przestrzeń nazw 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 obiekt 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 Obsługa komunikatów w warstwie Standardowa można tworzyć kolejki i tematy usługi Service Bus w rozmiarach 1 (wartość domyślna), 2, 3, 4 lub 5 GB. Podczas włączania 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 przydziału zostanie osiągnięty, żądania dotyczące dodatkowych połączeń zostaną odrzucone, a wyjątek zostanie odebrany przez kod wywołujący. 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 przy użyciu jednostki SKU usługi Service Bus w warstwie Standardowa lub 1000 kolejek/jednostki obsługi komunikatów przy użyciu jednostki SKU Usługi Service Bus w warstwie Premium, możesz również utworzyć dodatkowe przestrzenie nazw przy użyciu witryny Azure Portal.
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 usługi 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) |
| Interfejs API .NET | Tak (Interfejs API klienta usługi Storage platformy .NET) |
Tak (Interfejs 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. |
| Reguły nazewnictwa kolejek | Długość maksymalnie 63 znaków (Litery w nazwie kolejki muszą 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ść typu punkt w czasie). |
| Peek, funkcja | Tak | Tak |
Dodatkowe informacje
- Kolejki magazynu 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 obsługiwanych przez brokera usługi Service Bus używają połączeń TCP pełnodupleksowych w celu zwiększenia wydajności w porównaniu z interfejsem REST za pośrednictwem protokołu HTTP i obsługują standardowy protokół AMQP 1.0.
- Nazwy kolejek magazynu 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 usługi Storage i kolejki usługi Service Bus.
| Kryteria porównania | Kolejki magazynu | Kolejki usługi Service Bus |
|---|---|---|
| Uwierzytelnianie | Klucz symetryczny i kontrola dostępu oparta na rolach (RBAC) | Klucz symetryczny i kontrola dostępu oparta na rolach (RBAC) |
| Federacja dostawcy 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 — Microsoft Entra authentication (Uwierzytelnianie usługi Microsoft Entra) i Azure Service Bus — Microsoft Entra authentication (Uwierzytelnianie w usłudze 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.
Wolisz wybrać kolejki magazynu 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.
- Sesje
- Transakcje
- Wykrywanie duplikatów
- Automatyczne usuwanie utraconych komunikatów
- Możliwości publikowania i subskrybowania trwałe
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.