Azure Fundamentals · Lekcja

Azure Service Bus do komunikacji rozdzielonej

Proszę utworzyć przestrzeń nazw Service Bus z kolejkami i tematami, wysyłać i odbierać komunikaty z aplikacji oraz skonfigurować kolejki kwarantanny do obsługi nieudanych komunikatów.

Azure Service Bus do komunikacji rozdzielonej to bezpłatna lekcja Azure Fundamentals na CoddyKit. To lekcja 2 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Azure Fundamentals, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Azure Fundamentals zawiera 4 lekcji w sumie.

Dlaczego warto rozdzielać komunikację za pomocą komunikatów?

W architekturach silnie powiązanych usługi wywołują się synchronicznie — jeśli usługa podrzędna działa wolno lub jest niedostępna, wywołujący również zostaje zablokowany albo kończy działanie błędem. Kolejki komunikatów wprowadzają asynchroniczny bufor między producentami a konsumentami, dzięki czemu wolne działanie usługi podrzędnej nie powoduje kaskadowego rozprzestrzeniania się awarii na usługi nadrzędne. Azure Service Bus to należąca do klasy enterprise usługa komunikatów firmy Microsoft, udostępniająca kolejki (komunikacja punkt-punkt) i tematy (publikowanie-subskrypcja) z gwarantowanym dostarczaniem, zachowaniem kolejności oraz obsługą przenoszenia komunikatów do kolejki komunikatów odrzuconych.

Przestrzenie nazw i warstwy Service Bus

Przestrzeń nazw Service Bus to kontener najwyższego poziomu dla wszystkich jednostek komunikatów (kolejek i tematów), który udostępnia punkt końcowy FQDN (np. myns.servicebus.windows.net). Przestrzenie nazw występują w trzech warstwach: Basic (tylko kolejki, bez tematów, maksymalny rozmiar komunikatu 256 KB), Standard (kolejki i tematy, maksymalnie 256 KB) oraz Premium (kolejki i tematy, komunikaty o rozmiarze do 100 MB, dedykowana pojemność, integracja z VNet i odzyskiwanie po awarii geograficznej). Warstwa Premium jest wymagana w przypadku produkcyjnych obciążeń, które potrzebują wydajności objętej umową SLA.

# Create a Service Bus namespace (Standard tier)
az servicebus namespace create \
  --resource-group myRG \
  --name myservicebusns \
  --location eastus \
  --sku Standard

Kolejki: komunikacja punkt-punkt

Kolejka Service Bus przechowuje komunikaty w kolejności FIFO i dostarcza każdy komunikat dokładnie do jednego konsumenta. Konsumenci odbierają komunikaty za pomocą mechanizmu peek-lock: komunikat jest tymczasowo ukrywany przed innymi konsumentami na czas przetwarzania. Jeśli konsument zakończy przetwarzanie pomyślnie, wywołuje CompleteMessage(), aby usunąć komunikat z kolejki. Jeśli przetwarzanie się nie powiedzie, konsument wywołuje AbandonMessage(), a komunikat ponownie staje się widoczny i może zostać przetworzony ponownie. Po skonfigurowanej liczbie prób dostarczenia komunikaty, których nie można przetworzyć, są przenoszone do kolejki komunikatów odrzuconych (DLQ).

# Create a Service Bus queue with DLQ enabled
az servicebus queue create \
  --resource-group myRG \
  --namespace-name myservicebusns \
  --name orders \
  --max-delivery-count 5 \
  --default-message-time-to-live P7D \
  --dead-lettering-on-message-expiration true

Tematy i subskrypcje

Tematy implementują wzorzec publikowania-subskrypcji: producent wysyła komunikat do tematu, a dowolna liczba subskrypcji tego tematu otrzymuje własną kopię komunikatu. Subskrypcje mogą mieć filtry (wyrażenia SQL lub korelacji), aby otrzymywać tylko podzbiór komunikatów — na przykład subskrypcję HighPriority, która otrzymuje wyłącznie komunikaty, w których właściwość Priority ma wartość High. Umożliwia to rozsyłanie komunikatów z jednego tematu do wielu usług podrzędnych, z których każda jest zainteresowana innym podzbiorem zdarzeń.

# Create a topic and two subscriptions with filters
az servicebus topic create \
  --resource-group myRG \
  --namespace-name myservicebusns \
  --name order-events

az servicebus topic subscription create \
  --resource-group myRG \
  --namespace-name myservicebusns \
  --topic-name order-events \
  --name high-priority-sub

az servicebus topic subscription rule create \
  --resource-group myRG \
  --namespace-name myservicebusns \
  --topic-name order-events \
  --subscription-name high-priority-sub \
  --name PriorityFilter \
  --filter-sql-expression 'Priority = '"'"'High'"'"''

Wysyłanie i odbieranie komunikatów

Azure Service Bus SDK udostępnia obiekt ServiceBusClient do wysyłania i odbierania komunikatów. Aby wysłać komunikat, należy utworzyć obiekt ServiceBusSender i wywołać metodę SendMessageAsync(). Aby odebrać komunikat, należy utworzyć obiekt ServiceBusReceiver i wywołać metodę ReceiveMessageAsync() (odbieranie przez odpytywanie) albo użyć obiektu ServiceBusProcessor z programem obsługi zdarzeń do ciągłego przetwarzania opartego na wypychaniu. Użycie DefaultAzureCredential z Service Bus SDK eliminuje potrzebę stosowania parametrów połączenia i pozwala zachować model bez haseł.

# Python: Send a message to a Service Bus queue
from azure.servicebus import ServiceBusClient, ServiceBusMessage
from azure.identity import DefaultAzureCredential

credential = DefaultAzureCredential()
client = ServiceBusClient(
  fully_qualified_namespace='myservicebusns.servicebus.windows.net',
  credential=credential
)
with client.get_queue_sender(queue_name='orders') as sender:
    msg = ServiceBusMessage('{ 'orderId': '12345', 'amount': 99.99 }')
    sender.send_messages(msg)
    print('Message sent')

Kolejka komunikatów odrzuconych

Kolejka komunikatów odrzuconych (DLQ) to podkolejka, do której automatycznie trafiają komunikaty, których nie można dostarczyć. Komunikaty są odrzucane, gdy: przekroczą maksymalną liczbę dostarczeń, wygasną (upłynie wartość TTL) lub nie przejdą oceny filtra subskrypcji tematu. Monitorowanie DLQ jest niezbędne — rosnąca liczba komunikatów w DLQ wskazuje na systematyczną awarię przetwarzania. Komunikaty w DLQ zachowują oryginalną zawartość, a także właściwości przyczyna odrzucenia i opis dodane przez Service Bus, które pomagają zdiagnozować przyczynę problemu.

# Read messages from the dead-letter queue
az servicebus queue show \
  --resource-group myRG \
  --namespace-name myservicebusns \
  --name 'orders/$DeadLetterQueue' \
  --query 'countDetails.deadLetterMessageCount'

Sesje zapewniające kolejność

Sesje umożliwiają ścisłe zachowanie kolejności komunikatów należących do tej samej grupy logicznej. Każdy komunikat jest oznaczany wartością SessionId (np. identyfikatorem klienta lub zamówienia), a konsument obsługujący sesje odbiera wyłącznie wszystkie komunikaty z danej sesji, w kolejności FIFO. Sesje są niezbędne w przepływach pracy, w których etapy muszą być wykonywane sekwencyjnie — na przykład podczas przetwarzania wszystkich zdarzeń dotyczących konkretnego zamówienia: Created → PaymentReceived → Shipped → Delivered. Sesje włącza się podczas tworzenia kolejki lub subskrypcji.

Service Bus a Event Grid i Event Hubs

Te trzy usługi komunikatów platformy Azure są często mylone: Service Bus służy do niezawodnej, transakcyjnej komunikacji klasy enterprise z zachowaniem kolejności, obsługą sesji i DLQ — sprawdza się w przetwarzaniu zamówień, transakcjach finansowych i orkiestracji przepływów pracy. Event Grid służy do reaktywnego routingu zdarzeń (przesłano obiekt blob, usunięto maszynę wirtualną) z rozsyłaniem do wielu programów obsługi, ale bez zachowania kolejności i możliwości odtwarzania. Event Hubs służy do strumieniowego przetwarzania zdarzeń o dużej przepustowości (miliony zdarzeń na sekundę) z możliwością odtwarzania — sprawdza się w telemetrii IoT i pozyskiwaniu dzienników. Wyboru należy dokonać na podstawie wymagań dotyczących kolejności, przepustowości i trwałości.

Odzyskiwanie po awarii geograficznej

Funkcja Geo-Disaster Recovery (Geo-DR) usługi Service Bus replikuje metadane przestrzeni nazw (kolejki, tematy, subskrypcje i zasady dostępu) do regionu pomocniczego. Sparowane regiony współdzielą jeden alias nazwy hosta; jeśli region podstawowy ulegnie awarii, należy zainicjować przełączenie awaryjne, a alias zacznie wskazywać region pomocniczy. Należy pamiętać, że dane komunikatów (komunikaty będące w trakcie przetwarzania) nie są replikowane w warstwie Standard — komunikaty replikuje wyłącznie funkcja Geo-DR w warstwie Premium. W przypadku komunikacji o znaczeniu krytycznym należy użyć warstwy Premium wraz z Geo-DR, aby spełnić wymagania RTO i RPO.

Skalowanie i jednostki partycjonowane

W scenariuszach wymagających dużej przepustowości należy włączyć partycjonowanie kolejek i tematów podczas ich tworzenia. Jednostki partycjonowane wewnętrznie korzystają z wielu brokerów komunikatów i fragmentów magazynu, zwielokrotniając dostępną przepustowość. W warstwie Standard łączny rozmiar jednostek partycjonowanych może wynosić do 80 GB. Każdy komunikat jest kierowany do partycji na podstawie właściwości PartitionKey (jeśli sesje są włączone, domyślnie jest to identyfikator sesji). Partycjonowanie to decyzja podejmowana podczas tworzenia — istniejącej kolejki nie można poddać partycjonowaniu. Aby uzyskać najwyższą gwarantowaną przepustowość bez złożoności związanej z partycjonowaniem, należy użyć warstwy Premium.

# Create a partitioned queue (Standard tier)
az servicebus queue create \
  --resource-group myRG \
  --namespace-name myservicebusns \
  --name orders-partitioned \
  --enable-partitioning true

Monitorowanie kondycji Service Bus

Najważniejsze metryki usługi Service Bus, które należy monitorować w usłudze Azure Monitor, to: Active Messages (głębokość kolejki — rosnąca głębokość wskazuje na opóźnienie po stronie konsumentów), Dead-lettered Messages (błędy przetwarzania), Server Errors i User Errors (problemy z uwierzytelnianiem i ograniczaniem przepustowości) oraz Incoming Requests (łączna przepustowość). Należy skonfigurować alerty metryk, aby zespoły operacyjne otrzymywały powiadomienia, gdy liczba komunikatów w kolejce odrzuconych przekroczy określony próg lub gdy aktywne komunikaty nie będą odbierane przez dłuższy czas.

Szybkie sprawdzenie

Sprawdź swoją znajomość zagadnień Microsoft Azure Fundamentals (AZ-900) z tej lekcji.

Podsumowanie lekcji

W tej lekcji poznali Państwo: kolejki Service Bus, które zapewniają komunikację punkt-punkt z dostarczaniem w trybie peek-lock oraz kolejką komunikatów odrzuconych dla komunikatów, których nie udało się przetworzyć; tematy i subskrypcje, które rozsyłają komunikaty do wielu konsumentów zgodnie z regułami filtrowania; a także sesje, które umożliwiają uporządkowane przetwarzanie komunikatów należących do tej samej grupy logicznej. W następnej części omówimy Azure Container Apps, służące do wdrażania nowoczesnych mikrousług.

Często zadawane pytania

Czy lekcja „Azure Service Bus do komunikacji rozdzielonej” jest bezpłatna?

Tak — pełny tekst „Azure Service Bus do komunikacji rozdzielonej” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Azure Fundamentals, przejdź na CoddyKit PRO. Kurs Azure Fundamentals zawiera 4 lekcji w sumie.

Co nauczysz się w „Azure Service Bus do komunikacji rozdzielonej”?

Proszę utworzyć przestrzeń nazw Service Bus z kolejkami i tematami, wysyłać i odbierać komunikaty z aplikacji oraz skonfigurować kolejki kwarantanny do obsługi nieudanych komunikatów. Ćwiczysz Azure Fundamentals z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć Azure Fundamentals?

Nie wymagamy żadnego doświadczenia. Azure Fundamentals w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 2 z 4.

Ile czasu zajmuje lekcja „Azure Service Bus do komunikacji rozdzielonej”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji Azure Fundamentals?

Tak. Każda lekcja Azure Fundamentals zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

Tożsamość zarządzana do uwierzytelniania bez haseł
Azure Service Bus do komunikacji rozdzielonej
Azure Container Apps
Kompletny przepływ pracy dewelopera

← Powrót do Azure Fundamentals