Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Azure Queue Storage przechowuje komunikaty na potrzeby przetwarzania asynchronicznego. W tym artykule opisano strategie partycjonowania, modele izolacji i funkcje usługi Queue Storage dla rozwiązań wielodostępnych. Zapewnia wskazówki, które mogą ułatwić dystrybucję obciążenia komunikatów, izolowanie komunikatów dzierżawców oraz zarządzanie dostępem, szyfrowaniem i użyciem.
Strategie partycjonowania
Usługa Queue Storage nie uwidacznia klucza partycji ani podkolejki w kolejce. Kolejka jest najmniejszym poziomem, którego można użyć do dystrybucji obciążenia komunikatów, a konto magazynowe jest następnym poziomem. Kolejka udostępniona nie zapewnia specyficznej dla dzierżawcy przepływności ani izolacji wydajności.
W przypadku komunikatów o rozmiarze 1 KiB pojedyncza kolejka ma docelową przepływność do 2000 komunikatów na sekundę, a konto magazynu ma maksymalną szybkość żądań wynoszącą 20 000 komunikatów na sekundę. Rozmiar komunikatu i wzorce dostępu wpływają na przepustowość osiąganą przez obciążenie robocze. Komunikaty w kolejce mogą być maksymalnie 64 KiB. W przypadku większych komunikatów lub zaawansowanych funkcji brokera rozważ użycie Azure Service Bus.
Jeśli obciążenie może przekroczyć docelowy poziom dla każdej kolejki, rozdziel komunikaty między wiele kolejek. W zależności od wymagań dotyczących routingu i działania można partycjonować kolejki według dzierżawcy, grupy dzierżawców lub warstwy usług, obciążenia funkcjonalnego, stempla wdrożenia lub regionu. Dzierżawca o dużym wolumenie, który współużytkuje kolejkę z innymi dzierżawcami, może zużywać nieproporcjonalnie dużą część przepustowości kolejki i powodować dławienie dla innych dzierżawców.
Wiele kolejek na tym samym koncie magazynu danych nadal współużytkuje pojemność konta i konfigurację na poziomie konta. Jeśli zagregowane obciążenie może przekroczyć limit docelowy konta magazynu lub jeśli dzierżawca potrzebuje niezależnej skali lub konfiguracji regionalnej, rozłóż kolejki na wiele kont magazynu. Monitoruj ograniczanie przepustowości, używaj ponownych prób z wykładniczo rosnącym opóźnieniem i przetestuj obciążenie pod kątem udokumentowanych celów skalowalności usługi Queue Storage. Informacje o dostępie dzierżawców i opcjach izolacji danych zawiera temat Modele izolacji.
Modele izolacji
Po określeniu sposobu dystrybucji obciążenia komunikatów określ poziom izolacji dzierżawcy, który ma być stosowany. Queue Storage obsługuje kolejki udostępnione, kolejki dla każdego dzierżawcy i konta magazynowe dla każdego dzierżawcy. W poniższej tabeli przedstawiono podsumowanie różnic między głównymi modelami izolacji dzierżawy dla usługi Queue Storage.
| Rozważenie | Kolejki udostępnione | Kolejki dla każdego najemcy | Konta magazynowe dla każdego dzierżawcy |
|---|---|---|---|
| Izolacja danych | Niski poziom Aplikacja wymusza izolację. | Nisko-średni | High |
| Izolacja wydajności | Low | Niski poziom Większość przydziałów i limitów ma zastosowanie do całego konta magazynu. | High |
| Złożoność wdrożenia | Low | Medium | High |
| Złożoność operacyjna | Low | Medium | High |
| Przykładowy scenariusz | Duże rozwiązanie wielodostępne ma udostępnioną warstwę aplikacji. | Wystawiane są adresy URL sygnatury dostępu współdzielonego (SAS) w zakresie dzierżawcy. | Każda dzierżawa ma własną sygnaturę wdrożenia. |
Note
Podczas wybierania modelu izolacji należy wziąć pod uwagę przydziały i limity. Te limity obejmują limity usług platformy Azure, cele skalowalności usługi Queue Storage i cele skalowalności dla dostawcy zasobów usługi Storage.
Kolejki udostępnione
Jeśli udostępniasz kolejkę, wszyscy dzierżawcy współdzielą jej docelowy poziom przepustowości. Obciążony dzierżawca może powodować ograniczanie przepustowości dla innych dzierżawców. Aby zapoznać się ze strategiami dystrybucji obciążenia komunikatów, zobacz Strategie partycjonowania.
Kolejki nie zapewniają partycjonowania ani podkolejek, więc dane wszystkich dzierżawców mogą się przeplatać. Aplikacja musi zidentyfikować dzierżawcę dla każdego komunikatu i wymusić izolację podczas przetwarzania. Nie udzielaj dzierżawcom bezpośredniego dostępu do udostępnionej kolejki, jeśli nie mogą uzyskiwać dostępu do komunikatów innych dzierżawców.
Kolejki dla każdego najemcy
Można utworzyć pojedyncze kolejki dla każdego najemcy w ramach jednego konta magazynowania. Nie ma limitu liczby kolejek, które można utworzyć na koncie magazynu.
Kolejki dla każdego dzierżawcy zapewniają granicę routingu i kontroli dostępu, ale nie zapewniają izolacji wydajności. Wszystkie kolejki na koncie współdzielą cele dotyczące pojemności i wydajności konta magazynowego.
W tym scenariuszu możesz użyć kontroli dostępu do usługi Queue Storage, w tym sygnatury dostępu współdzielonego, aby zarządzać dostępem do danych każdego dzierżawcy.
Podczas dynamicznego tworzenia kolejek dla każdego najemcy, należy wziąć pod uwagę sposób, w jaki warstwa aplikacji korzysta z komunikatów z kolejki każdego najemcy. W przypadku zaawansowanych scenariuszy rozważ użycie Azure Service Bus, które obsługuje funkcje, takie jak sesje, automatyczne przekazywanie komunikatów oraz tematy i subskrypcje.
Konta magazynowe dla każdego dzierżawcy
Najsilniejszy poziom izolacji używa dedykowanego konta storage dla każdego najemcy. Ten model zapewnia pełną izolację kluczy konta magazynu danych, które można niezależnie rotować. Umożliwia również skalowanie rozwiązania poza limity i przydziały dla każdego konta magazynowego. Rozważ ten model dla dzierżawców mających trwale duże woluminy komunikatów lub wymagających niezależnej konfiguracji regionalnej lub odrębnych docelowych parametrów wydajności. Należy jednak również wziąć pod uwagę maksymalną liczbę kont przechowywania dozwolonych w ramach jednej subskrypcji Azure.
Funkcje Queue Storage, które obsługują wielodzierżawność
Poniższe funkcje usługi Queue Storage mogą pomóc w zaimplementowaniu i obsłudze wybranego modelu izolacji.
Sygnatury dostępu współdzielonego
W przypadku korzystania z usługi Queue Storage z aplikacji klienckiej należy rozważyć kierowanie żądań za pośrednictwem warstwy aplikacji lub zezwalanie klientom na bezpośrednie łączenie się z kolejką. Bezpośredni dostęp klientów może zmniejszyć obciążenie aplikacji zaplecza i liczbę przeskoków sieciowych.
sygnatura dostępu współdzielonego (SAS) umożliwia zapewnienie aplikacjom klienckim ograniczonego dostępu do kolejki. Można ograniczyć operacje, które klient może wykonać, oraz okres, w którym jest dozwolony dostęp. Można na przykład wydać sygnaturę dostępu współdzielonego (SAS), która umożliwia dzierżawcy dodawanie komunikatów do własnej kolejki bez zezwolenia mu na odczytywanie i usuwanie komunikatów.
Użyj wzorca Valet Key, aby wystawiać ograniczone tokeny SAS ze swojego poziomu aplikacji. Uwierzytelnij klienta przy użyciu systemu uwierzytelniania aplikacji, określ, do której kolejki dzierżawcy może uzyskać dostęp, i wystawiaj token tylko dla wymaganych operacji.
Zapisane zasady dostępu umożliwiają zdefiniowanie pojedynczej zasady do użycia w przypadku wystawiania wielu tokenów SAS usługi. Przechowywane zasady dostępu nie mają zastosowania do tokenów SAS delegowania użytkownika ani tokenów SAS konta.
Delegowanie użytkownika SAS
Sygnatura dostępu współdzielonego usługi lub sygnatura dostępu współdzielonego konta jest podpisana przy użyciu jednego z kluczy konta magazynu. Sygnatura dostępu współdzielonego (SAS) delegowana przez użytkownika jest zamiast tego zabezpieczona przy użyciu poświadczeń Microsoft Entra. Warstwa aplikacji żąda klucza delegowania użytkownika przy użyciu własnej tożsamości zarządzanej, a następnie podpisuje tokeny o określonym zakresie i ograniczone czasowo dla każdego dzierżawcy. Nie dystrybuujesz ani nie przechowujesz kluczy kont. Microsoft zaleca używanie sygnatury dostępu współdzielonego delegowania użytkownika zamiast sygnatury dostępu współdzielonego klucza konta, jeśli projekt rozwiązania to obsługuje.
Użyj krótkich okresów istnienia tokenu i zaplanuj sposób odwołania dostępu w przypadku przejęcia tokenu. Aby skorelować dzienniki aplikacji z dziennikami usługi Queue Storage, ustaw identyfikator żądania klienta (x-ms-client-request-id) w żądaniach magazynu i zarejestruj go wraz z identyfikatorem dzierżawy.
Kontrola dostępu oparta na tożsamości
Usługa Queue Storage zapewnia kontrolę dostępu opartą na tożsamościach za pośrednictwem Microsoft Entra ID. Użyj tożsamości zarządzanych i kontroli dostępu na podstawie ról platformy Azure, aby autoryzować aplikację do uzyskiwania dostępu do kolejek bez przechowywania kluczy kont. Ogranicz dostęp do kolejki każdego dzierżawcy, gdy dzierżawcy wymagają bezpośredniego dostępu. Autoryzacja na poziomie kolejki nie izoluje komunikatów poszczególnych dzierżawców w ramach udostępnionej kolejki.
Encryption
Usługa Queue Storage domyślnie szyfruje dane w spoczynku przy użyciu kluczy zarządzanych przez Microsoft. Aby używać kluczy zarządzanych przez klienta, skonfiguruj konto magazynu do używania klucza szyfrowania o zakresie konta dla kolejek podczas tworzenia konta. Nie można zmienić tego zakresu klucza szyfrowania po utworzeniu konta.
Jeśli dzierżawcy wymagają oddzielnych kluczy zarządzanych przez klienta, użyj oddzielnych kont magazynowych. Blob Storage zakresy szyfrowania i klucze dostarczone przez klienta na poszczególnych żądaniach nie mają zastosowania do usługi Queue Storage. Planuj rotację i odwoływanie kluczy wraz z cyklem życia tenanta.
Monitoring
W rozwiązaniu wielodostępnym zastanów się, czy należy zmierzyć zużycie dla każdego najemcy. Zdefiniuj określone metryki do śledzenia, takie jak liczba komunikatów lub operacji dla każdego dzierżawcy. Możesz również użyć alokacji kosztów, aby śledzić koszty użycia każdego najemcy i włączyć rozliczanie kosztów w wielu subskrypcjach.
Usługa Queue Storage oferuje wbudowane funkcje monitorowania. Gdy dzierżawcy współdzielą kolejkę, uwzględnij identyfikatory dzierżawców w telemetrii aplikacji, aby można było przypisywać przetwarzanie komunikatów i użycie do odpowiedniego dzierżawcy.
Monitorowanie częstotliwości żądań i odpowiedzi HTTP 500 i 503 w celu wykrywania kolejek lub kont, które zbliżają się do celów skalowalności. Skoreluj tę telemetrię z identyfikatorami dzierżawców, aby zidentyfikować dzierżawców, których użycie wpływa na pojemność współdzieloną.
Możesz zbierać dzienniki żądań, a następnie agregować i analizować je obok danych telemetrycznych aplikacji. W rozwiązaniach, które tworzą duże ilości żądań, należy rozważyć, czy korzyści uzasadniają koszt przechwytywania i przetwarzania tych dzienników.
Contributors
Microsoft utrzymuje ten artykuł. Następujący współautorzy napisali ten artykuł.
Główny autor:
- John Downs | Główny inżynier oprogramowania, wzorce i praktyki platformy Azure
Inni współautorzy:
- Dr Christian Geuer-Pollmann | Główny inżynier klienta, fasttrack dla platformy Azure
- Patrick Horn | Starszy menedżer ds. inżynierii klienta, rozwiązanie FastTrack dla platformy Azure
- Ben Hummerstone | Główny inżynier klienta, fasttrack dla platformy Azure
- Vic Perdana | Architekt rozwiązań w chmurze — ISV Azure
- Daniel Scott-Raynsford | Architekt rozwiązań partnerskich, dane i sztuczna inteligencja
- Arsen Vladimirskiy | Główny inżynier ds. klientów, FastTrack dla Azure
Aby wyświetlić niepubliczne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.