Warstwa obsługi komunikatów w warstwie Premium usługi Service Bus

Komunikaty usługi Service Bus, w tym jednostki, takie jak kolejki i tematy, stanowią połączenie możliwości obsługi komunikatów dla przedsiębiorstw oraz zaawansowanej semantyki publikowania/subskrybowania w skali chmury. Obsługa komunikatów usługi Service Bus pełni rolę szkieletu komunikacyjnego dla wielu zaawansowanych rozwiązań w chmurze.

Warstwa Premium komunikatów usługi Service Bus stanowi odpowiedź na częste żądania klientów dotyczące skali, wydajności i dostępności dla aplikacji o krytycznym znaczeniu. Zalecamy użycie warstwy Premium w scenariuszach produkcyjnych. Mimo że zestawy funkcji są prawie identyczne, warstwy Standardowa i Premium komunikatów usługi Service Bus są przeznaczone do obsługi różnych przypadków użycia.

W poniższej tabeli wyróżniono pewne ogólne różnice.

Warstwa Premium komunikatów usługi Service Bus zapewnia izolację zasobów na poziomie procesora CPU i pamięci, dlatego obciążenia poszczególnych klientów są od siebie odizolowane. Ten kontener zasobów jest nazywany jednostką obsługi komunikatów. Każda przestrzeń nazw w warstwie Premium ma przydzieloną co najmniej jedną jednostkę obsługi komunikatów. Możesz kupić 1, 2, 4, 8 lub 16 jednostek obsługi komunikatów dla każdej przestrzeni nazw usługi Service Bus Premium. Pojedyncze obciążenie lub jednostka może obejmować wiele jednostek obsługi komunikatów, a liczba jednostek obsługi komunikatów może zostać zmieniona w tej chwili. Pozwala to uzyskać przewidywalną i powtarzalną wydajność dla rozwiązania opartego na usłudze Service Bus.

Nie tylko ta wydajność jest bardziej przewidywalna i dostępna, ale także szybsza. Dzięki obsłudze komunikatów w warstwie Premium szczytowa wydajność jest znacznie szybsza niż w warstwie Standardowa.

Różnice techniczne dotyczące obsługi komunikatów w warstwie Premium

W poniższych sekcjach omówiono kilka różnic między warstwami obsługi komunikatów w warstwie Premium i Standardowa.

Jednostki ekspresowe

Ponieważ obsługa komunikatów w warstwie Premium działa w izolowanym środowisku czasu wykonywania, jednostki ekspresowe nie są obsługiwane w przestrzeniach nazw w warstwie Premium. Jednostka ekspresowa tymczasowo przechowuje komunikat w pamięci przed zapisaniem go w magazynie trwałym. Jeśli masz kod działający w ramach standardowej obsługi komunikatów i chcesz przełączyć go do warstwy Premium, upewnij się, że funkcja jednostki ekspresowej jest wyłączona.

Użycie zasobów obsługi komunikatów w warstwie Premium

Ogólnie rzecz biorąc, każda operacja w jednostce może spowodować użycie procesora CPU i pamięci. Oto niektóre z tych operacji:

• Operacje zarządzania, takie jak operacje tworzenia, pobierania, aktualizowania i usuwania (CRUD) w kolejkach, tematach i subskrypcjach.
• Operacje środowiska uruchomieniowego (wysyłanie i odbieranie komunikatów)
• Monitorowanie operacji i alertów

Dodatkowe użycie procesora CPU i pamięci nie jest jednak dodatkowo wyceniane. W przypadku warstwy obsługi komunikatów w warstwie Premium jest dostępna pojedyncza cena dla jednostki komunikatów.

Użycie procesora CPU i pamięci jest śledzone i wyświetlane z następujących powodów:

• Zapewnienie przezroczystości wewnętrznych systemów
• Omówienie pojemności zakupionych zasobów.
• Planowanie pojemności, które ułatwia podjęcie decyzji o skalowaniu w górę/w dół.

Ile jednostek obsługi komunikatów jest potrzebnych?

Podczas aprowizacji przestrzeni nazw usługi Azure Service Bus w warstwie Premium należy określić liczbę jednostek obsługi komunikatów. Te jednostki obsługi komunikatów to dedykowane zasoby przydzielone do przestrzeni nazw. Gdy partycjonowanie jest włączone w przestrzeni nazw, jednostki obsługi komunikatów są równomiernie dystrybuowane między partycjami.

Liczba jednostek obsługi komunikatów przydzielonych do przestrzeni nazw usługi Service Bus w warstwie Premium może być dynamicznie dostosowywana do współczynnika zmian (zwiększenia lub zmniejszenia) obciążeń.

Podczas podejmowania decyzji o liczbie jednostek obsługi komunikatów dla architektury należy wziąć pod uwagę kilka czynników:

• Zacznij od 1 lub 2 jednostek obsługi komunikatów przydzielonych do przestrzeni nazw lub 1 jednostki komunikatów na partycję.
• Zapoznaj się z metrykami użycia procesora CPU w ramach metryk użycia zasobów dla przestrzeni nazw.
  • Jeśli użycie procesora CPU jest poniżej 20%, możesz skalować w dół liczbę jednostek obsługi komunikatów przydzielonych do przestrzeni nazw.
  • Jeśli użycie procesora CPU przekracza 70%, aplikacja korzysta ze skalowania w górę liczby jednostek obsługi komunikatów przydzielonych do przestrzeni nazw.

Aby dowiedzieć się, jak skonfigurować przestrzeń nazw usługi Service Bus do automatycznego skalowania (zwiększanie lub zmniejszanie liczby jednostek obsługi komunikatów), zobacz Automatyczne aktualizowanie jednostek obsługi komunikatów.

Wprowadzenie do obsługi komunikatów w warstwie Premium

Wprowadzenie do obsługi komunikatów w warstwie Premium jest proste, a proces jest podobny do standardowego obsługi komunikatów. Rozpocznij od utworzenia przestrzeni nazw w witrynie Azure Portal. W obszarze Warstwa cenowa wybierz pozycję Premium. Wybierz pozycję Wyświetl pełne szczegóły cennika, aby wyświetlić więcej informacji o każdej warstwie.

Możesz również tworzyć przestrzenie nazw Premium za pomocą szablonów usługi Azure Resource Manager.

Obsługa dużych komunikatów

Przestrzenie nazw w warstwie Premium usługi Azure Service Bus obsługują możliwość wysyłania dużych ładunków komunikatów o rozmiarze do 100 MB. Ta funkcja jest przeznaczona głównie do starszych obciążeń, które używały większych ładunków komunikatów w innych brokerach obsługi komunikatów w przedsiębiorstwie i chcą bezproblemowo migrować do usługi Azure Service Bus.

Poniżej przedstawiono niektóre zagadnienia dotyczące wysyłania dużych komunikatów w usłudze Azure Service Bus —

• Obsługiwane tylko w przestrzeniach nazw warstwy Premium usługi Azure Service Bus.
• Obsługiwane tylko w przypadku korzystania z protokołu Advanced Message Queuing Protocol (AMQP). Nieobsługiwane w przypadku korzystania z protokołów SBMP lub HTTP w warstwie Premium maksymalny rozmiar komunikatu dla protokołów SBMP i HTTP wynosi 1 MB.
• Obsługiwane w przypadku korzystania z zestawu SDK klienta usługi Java Message Service (JMS) 2.0 i innych zestawów SDK klienta języka.
• Wysyłanie dużych komunikatów powoduje zmniejszenie przepływności i zwiększone opóźnienie.
• Chociaż obsługiwane są ładunki komunikatów o rozmiarze 100 MB, zalecamy zachowanie możliwie najmniejszych ładunków komunikatów w celu zapewnienia niezawodnej wydajności z przestrzeni nazw usługi Service Bus.
• Maksymalny rozmiar komunikatu jest wymuszany tylko dla komunikatów wysyłanych do kolejki lub tematu. Limit rozmiaru nie jest wymuszany dla operacji odbierania. Umożliwia aktualizowanie maksymalnego rozmiaru komunikatu dla danej kolejki (lub tematu).
• Przetwarzanie wsadowe nie jest obsługiwane.
• Eksplorator usługi Service Bus nie obsługuje wysyłania ani odbierania dużych komunikatów.

30 września 2026 r. wycofamy obsługę protokołu SBMP dla usługi Azure Service Bus, więc nie będzie można już używać tego protokołu po 30 września 2026 r. Przeprowadź migrację do najnowszych bibliotek zestawu SDK usługi Azure Service Bus przy użyciu protokołu AMQP, który oferuje krytyczne aktualizacje zabezpieczeń i ulepszone możliwości przed tą datą.

Aby uzyskać więcej informacji, zobacz ogłoszenie o wycofaniu pomocy technicznej.

Włączanie obsługi dużych komunikatów dla nowej kolejki (lub tematu)

Aby włączyć obsługę dużych komunikatów, ustaw maksymalny rozmiar komunikatu podczas tworzenia nowej kolejki (lub tematu), jak pokazano na poniższej ilustracji:

Włączanie obsługi dużych komunikatów dla istniejącej kolejki (lub tematu)

Możesz również włączyć obsługę dużych komunikatów dla istniejących kolejek (lub tematów), aktualizując maksymalny rozmiar komunikatu w przeglądzie dla tej konkretnej kolejki (lub tematu), jak pokazano na poniższej ilustracji.

Bezpieczeństwo sieci

Następujące funkcje zabezpieczeń sieci są dostępne tylko w warstwie Premium. Aby uzyskać szczegółowe informacje, zobacz Zabezpieczenia sieci.

• Tagi usługi
• Punkty końcowe usługi sieciowej
• Prywatne punkty końcowe

Konfigurowanie zapory adresów IP przy użyciu witryny Azure Portal jest dostępne tylko dla przestrzeni nazw warstwy Premium. Można jednak skonfigurować reguły zapory adresów IP dla innych warstw przy użyciu szablonów usługi Azure Resource Manager, interfejsu wiersza polecenia, programu PowerShell lub interfejsu API REST. Aby uzyskać więcej informacji, zobacz Konfigurowanie zapory ip.

Szyfrowanie danych w stanie spoczynku

Usługa Azure Service Bus Premium zapewnia szyfrowanie danych magazynowanych przy użyciu usługi Azure Storage Service Encryption (Azure SSE). Usługa Service Bus Premium używa usługi Azure Storage do przechowywania danych. Wszystkie dane przechowywane w usłudze Azure Storage są szyfrowane przy użyciu kluczy zarządzanych przez firmę Microsoft. Jeśli używasz własnego klucza (nazywanego również kluczem zarządzanym przez klienta), dane są nadal szyfrowane przy użyciu klucza zarządzanego przez firmę Microsoft, ale dodatkowo klucz zarządzany przez firmę Microsoft jest szyfrowany przy użyciu klucza zarządzanego przez klienta. Ta funkcja umożliwia tworzenie, obracanie, wyłączanie i odwoływanie dostępu do kluczy zarządzanych przez klienta, które są używane do szyfrowania kluczy zarządzanych przez firmę Microsoft. Włączenie funkcji klucza zarządzanego przez klienta jest jednorazowym procesem konfiguracji w przestrzeni nazw. Aby uzyskać więcej informacji, zobacz Szyfrowanie danych usługi Azure Service Bus magazynowanych.

Partycjonowanie

Istnieją pewne różnice między warstwami Standardowa i Premium, jeśli chodzi o partycjonowanie.

• Partycjonowanie jest dostępne podczas tworzenia jednostek dla wszystkich kolejek i tematów w jednostkach SKU podstawowych lub standardowych. Przestrzeń nazw może mieć jednostki partycjonowane i niepartycyjne. Partycjonowanie jest dostępne podczas tworzenia przestrzeni nazw dla warstwy Premium, a wszystkie kolejki i tematy w tej przestrzeni nazw są partycjonowane. Wszystkie wcześniej zmigrowane jednostki podzielone na partycje w przestrzeniach nazw w warstwie Premium nadal działają zgodnie z oczekiwaniami.
• Po włączeniu partycjonowania w jednostkach SKU w warstwie Podstawowa lub Standardowa usługa Service Bus tworzy 16 partycji. Gdy partycjonowanie jest włączone w warstwie Premium, podczas tworzenia przestrzeni nazw jest określana liczba partycji.

Aby uzyskać więcej informacji, zobacz Partycjonowanie w usłudze Service Bus.

Awaria geograficzna i odzyskiwanie

Usługa Azure Service Bus rozprzestrzenia ryzyko katastroficznych awarii poszczególnych maszyn, a nawet kompletnych stojaków w klastrach obejmujących wiele domen awarii w centrum danych i implementuje przezroczyste mechanizmy wykrywania błędów i trybu failover, tak aby usługa nadal działała w ramach zapewnianych poziomów usług i zwykle bez zauważalnych przerw w działaniu w przypadku wystąpienia takich awarii. Przestrzeń nazw w warstwie Premium może mieć co najmniej dwie jednostki obsługi komunikatów, a te jednostki obsługi komunikatów są rozmieszczone w wielu domenach awarii w centrum danych, obsługując model klastra usługi Service Bus wszystkich aktywnych.

W przypadku przestrzeni nazw warstwy Premium ryzyko awarii jest dodatkowo rozłożone na trzy fizycznie oddzielone strefy dostępności obiektów, a usługa ma wystarczającą ilość rezerw pojemności, aby natychmiast poradzić sobie z pełną, katastrofalną utratą centrum danych. Cały aktywny model klastra usługi Azure Service Bus w domenie awarii wraz z obsługą strefy dostępności jest lepszy od dowolnego lokalnego produktu brokera komunikatów pod względem odporności na poważne awarie sprzętowe, a nawet katastrofalną utratę całych obiektów centrum danych. Mimo to, mogą istnieć poważne sytuacje z powszechnym zniszczeniem fizycznym, że nawet te środki nie mogą wystarczająco bronić przed.

Funkcja odzyskiwania po awarii geograficznej (Geo-DR) usługi Service Bus została zaprojektowana w celu ułatwienia odzyskiwania po awarii tej wielkości i porzucenia nieudanych regionów świadczenia usługi Azure bez konieczności zmieniania konfiguracji aplikacji. Porzucenie regionu platformy Azure zwykle obejmuje kilka usług, a ta funkcja ma na celu przede wszystkim ułatwienie zachowania integralności konfiguracji aplikacji złożonej. Funkcja jest dostępna globalnie dla warstwy Premium usługi Service Bus.

Funkcja odzyskiwania po awarii geograficznej zapewnia, że cała konfiguracja przestrzeni nazw (jednostki, konfiguracja, właściwości) jest stale replikowana z podstawowej przestrzeni nazw do pomocniczej przestrzeni nazw, z którą jest sparowana, i umożliwia zainicjowanie jednorazowego przejścia w tryb failover z podstawowej do pomocniczej w dowolnym momencie. Przeniesienie trybu failover ponownie wskazuje wybraną nazwę aliasu przestrzeni nazw do pomocniczej przestrzeni nazw, a następnie przerywa parowanie. Przejście w tryb failover jest niemal natychmiastowe po zainicjowaniu.

Aby uzyskać więcej informacji, zobacz Geo-disaster recovery usługi Azure Service Bus.

Replikacja geograficzna

Funkcja replikacji geograficznej jest jedną z opcji izolowania aplikacji usługi Azure Service Bus przed awariami i awariami, zapewniając replikację obu metadanych (jednostek, konfiguracji, właściwości) i danych (danych komunikatów i właściwości komunikatów/zmian stanu), natomiast funkcja Geo-DR opisana w poprzedniej sekcji replikuje tylko metadane.

Funkcja replikacji geograficznej zapewnia, że metadane i dane przestrzeni nazw są stale replikowane z regionu podstawowego do co najmniej jednego regionu pomocniczego.

• Kolejki, tematy, subskrypcje, filtry.
• Dane, które znajdują się w jednostkach.
• Wszystkie zmiany stanu i zmiany właściwości wykonywane względem komunikatów w przestrzeni nazw.
• Konfiguracja przestrzeni nazw.

Ta funkcja umożliwia promowanie dowolnego regionu pomocniczego do podstawowego w dowolnym momencie. Podwyższenie poziomu pomocniczego wskazuje nazwę przestrzeni nazw do wybranego regionu pomocniczego i przełącza role między regionem podstawowym i pomocniczym. Promocja jest prawie natychmiastowa po zainicjowaniu.

Obsługa usługi Java Message Service (JMS)

Warstwa Premium obsługuje JMS 1.1 i JMS 2.0. Aby uzyskać więcej informacji, zobacz How to use JMS 2.0 with Azure Service Bus Premium (Jak używać programu JMS 2.0 w usłudze Azure Service Bus Premium).

Warstwa Standardowa obsługuje tylko podzestaw JMS 1.1 skoncentrowany na kolejkach. Aby uzyskać więcej informacji, zobacz Używanie usługi Java Message Service 1.1 ze standardem usługi Azure Service Bus.

Następne kroki

Zobacz następujący artykuł: Automatyczne aktualizowanie jednostek obsługi komunikatów.