Porównanie kolejek magazynu i kolejek usługi Service Bus
W tym artykule przeanalizować różnice i podobieństwa między dwoma typami kolejek oferowanych przez 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
Platforma 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. Dostęp do komunikatów z dowolnego miejsca na świecie można uzyskać za pośrednictwem uwierzytelnionych wywołań przy użyciu protokołu HTTP lub HTTPS. Rozmiar komunikatu w kolejce może wynosić 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 wziąć pod uwagę 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ć w kolejce ponad 80 gigabajtów komunikatów.
- 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 proces roboczy został przerwany.
- 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 odbierania sondowania 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 w pierwszej kolejności (FIFO, first-in-first-out).
- Twoje rozwiązanie musi obsługiwać automatyczne wykrywanie duplikatów.
- Chcesz, aby aplikacja przetwarzała komunikaty jako równoległe długotrwałe 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ń jest podawany 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 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 przesyłania 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 do punktu w kolejce ze wzorcem obsługi komunikatów publikowania i subskrybowania. Ten wzorzec umożliwia integrację dodatkowych odbiorników (subskrybentów). Każdy odbiornik 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 kolejkach usługi Service Bus.
Podstawowe możliwości
W tej sekcji porównaliśmy niektóre podstawowe możliwości kolejkowania zapewniane 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 nowej wiadomości) |
Blokowanie z przekroczeniem limitu czasu lub bez (oferuje długą 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 | Zobacz dzierżawę & | & Podgląd blokady Odbieranie & usunięcia |
| 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żesz odnowić lub zwolnić dzierżawę komunikatów przy użyciu interfejsu API UpdateMessage ). |
30 sekund (ustawienie domyślne) Możesz odnowić blokadę komunikatów dla tego samego czasu trwania blokady 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 precyzję blokady zastosowaną do wszystkich komunikatów, ale blokadę można odnowić 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 magazynu 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 staje się ponownie widoczny w kolejce, aby inny proces roboczy go usunąć z kolejki. W tym momencie nowo widoczny komunikat może zostać ponownie umieszczony w kolejce do 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 & blokady , 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 wygaśnięcia komunikatu (TTL).
- 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 względem postępu obsługi sekwencji komunikatów sesji oraz przy użyciu transakcji dotyczących rozliczeń 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ć ponownego dostarczenia 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żenie zapewnienia dostarczania.
- Kolejki magazynu zapewniają dzierżawy z możliwością rozszerzania dzierżaw dla komunikatów. Ta funkcja umożliwia procesom roboczym utrzymywanie krótkich dzierżaw komunikatów. Dlatego jeśli proces roboczy ulegnie awarii, komunikat może zostać szybko przetworzony ponownie przez innego procesu roboczego. Ponadto pracownik może przedłużyć dzierżawę komunikatu, jeśli będzie musiał 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 przy użyciu różnych wartości 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ę komunikatu 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 operacji odbierania blokującego 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 do wygaśnięcia kolejki | 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, modułu TPS, liczby wywołań interfejsu API, liczby błędów i nie tylko. Wszystkie 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 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 |
| Funkcja przeczyszczania kolejki | Tak | Nie |
| 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 (możliwe do skonfigurowania 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 zapisywanie w kolejce umożliwia tysiącom kolejek automatyczne wysyłanie komunikatów do pojedynczej kolejki, z której aplikacja odbierającą korzysta z komunikatu. Tego mechanizmu można użyć do osiągnięcia zabezpieczeń, przepływu sterowania i izolowania magazynu między każdym wydawcą 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 w komunikacie, aby można było je przetworzyć z ostatniego znanego punktu kontrolnego, zamiast rozpoczynać się 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 komunikatów" zdefiniowanych przez aplikację.
- Kolejki magazynu umożliwiają uzyskanie szczegółowego dziennika wszystkich transakcji wykonywanych względem kolejki 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 do dostrajania 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 ich odpowiednimi odbiornikami. Możesz włączyć tę zaawansowaną funkcję w usłudze Service Bus, ustawiając właściwość identyfikatora sesji w komunikacie. Odbiorniki mogą następnie nasłuchiwać określonego identyfikatora sesji i odbierać komunikaty współużytkujące określony identyfikator sesji.
- Funkcja wykrywania duplikowania 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ą być stosowane.
| 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 (zdefiniowane podczas tworzenia kolejki i włączania partycjonowania — zobacz sekcję "Dodatkowe informacje") |
| Maksymalny rozmiar komunikatu | 64 KB (48 KB w przypadku korzystania z kodowania Base64) Platforma Azure obsługuje duże komunikaty, łącząc kolejki i obiekty blob — w tym momencie można zapisać do 200 GB dla pojedynczego elementu. |
256 KB 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 | Nieograniczona liczba | 10 000 (na przestrzeń nazw usługi) |
| Maksymalna liczba równoczesnych klientów | Nieograniczona liczba | 5000 |
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 Service Bus Quotas (Limity przydziału usługi Service Bus).
- W warstwie Standardowa obsługi komunikatów można tworzyć kolejki i tematy usługi Service Bus w rozmiarze 1 (domyślnie), 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 Azure Portal.
- W przypadku kolejek usługi Storage, jeśli zawartość komunikatu nie jest bezpieczna w formacie 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 jedną kolejką usługi Service Bus jest ograniczona do 100. Ta liczba jest współdzielona między nadawcami i odbiornikami. Jeśli ten limit przydziału zostanie osiągnięty, żądania dotyczące dodatkowych połączeń zostaną odrzucone i zostanie odebrany wyjątek 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.
- Jeśli potrzebujesz więcej niż 10 000 kolejek w jednej przestrzeni nazw usługi Service Bus, możesz skontaktować się z zespołem pomoc techniczna platformy Azure i poprosić o zwiększenie. Aby skalować więcej niż 10 000 kolejek za pomocą usługi Service Bus, możesz również utworzyć dodatkowe przestrzenie nazw przy użyciu 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 (.NET Storage Client API) |
Tak (.NET Service Bus API) |
| 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ść do 63 znaków (Litery w nazwie kolejki muszą mieć małe litery). |
Długość maksymalnie 260 znaków (Ścieżki i nazwy kolejki są bez uwzględniania wielkości liter). |
| Pobieranie funkcji długości kolejki | Tak (Przybliżona wartość, jeśli komunikaty wygasają poza czas wygaśnięcia bez usuwania). |
Tak (Dokładna, wartość punktu 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 nazw/wartości.
- Obie technologie kolejki oferują możliwość podglądu komunikatu bez konieczności blokowania go, co może być przydatne podczas implementowania narzędzia eksploratora kolejki/przeglądarki.
- Interfejsy API obsługi komunikatów obsługiwanych przez brokera usługi Service Bus używają połączeń TCP w trybie pełnodupleksowym 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 magazynu i kolejki usługi Service Bus.
| Kryteria porównania | Kolejki magazynu | Kolejki usługi Service Bus |
|---|---|---|
| Authentication | 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. Publiczne kolejki z dostępem anonimowym nie są obsługiwane.
- Za pomocą uwierzytelniania sygnatury dostępu współdzielonego 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łny dostęp. Aby uzyskać więcej informacji, zobacz Azure Storage — uwierzytelnianie sas i Azure Service Bus — uwierzytelnianie SAS.
- Obie kolejki obsługują autoryzację dostępu przy użyciu usługi Azure Active Directory (Azure AD). Autoryzowanie użytkowników lub aplikacji przy użyciu tokenu OAuth 2.0 zwróconego przez Azure AD zapewnia lepsze zabezpieczenia i łatwość użycia za pośrednictwem sygnatur dostępu współdzielonego (SAS). W przypadku Azure AD nie ma potrzeby przechowywania tokenów w kodzie i ryzyka potencjalnych luk w zabezpieczeniach. Aby uzyskać więcej informacji, zobacz Azure Storage — uwierzytelnianie Azure AD i Azure Service Bus — uwierzytelnianie Azure AD.
Podsumowanie
Aby lepiej zrozumieć te dwie technologie, możesz podjąć bardziej świadomą decyzję o tym, która technologia kolejki ma być używana i kiedy. Decyzja o tym, kiedy używać kolejek magazynu lub kolejek usługi Service Bus, wyraźnie zależy od wielu czynników. Te czynniki mogą zależeć 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 zapewniają wiele zaawansowanych funkcji, takich jak poniższe. Dlatego mogą być preferowanym wyborem, jeśli tworzysz aplikację hybrydową lub jeśli w przeciwnym razie aplikacja wymaga tych funkcji.
- Sesje
- Transakcje
- Wykrywanie duplikatów
- Automatyczne nieaktywne pismo
- Trwałe możliwości publikowania i subskrybowania
Następne kroki
Poniższe artykuły zawierają więcej wskazówek i informacji na temat korzystania z kolejek magazynu lub kolejek usługi Service Bus.