Cloud & IT Cert Prep · Lektion

Azure Service Bus til afkoblet messaging

Opret et Service Bus-navneområde med queues og topics, send og modtag meddelelser fra en applikation, og konfigurér dead-letter-queues til håndtering af mislykkede meddelelser.

Lektion 2 af 413 trin

Azure Service Bus til afkoblet messaging er en gratis Cloud & IT Cert Prep-lektion på CoddyKit. Dette er lektion 2 af 4. Du kan læse hele lektionen gratis nedenfor — og derefter øve dig praktisk i browseren med en indbygget kodeeditor og en AI-vejleder, der er tilgængelig døgnet rundt. Den er en del af læringsforløbet i Cloud & IT Cert Prep, og dine fremskridt synkroniseres på tværs af nettet og CoddyKit-appen. Cloud & IT Cert Prep-kurset indeholder 4 lektioner i alt.

Hvorfor afkoble med meddelelser?

I tæt koblede arkitekturer kalder services hinanden synkront — hvis den efterfølgende service er langsom eller nede, blokerer kaldet, eller det mislykkes også. Meddelelseskøer indfører en asynkron buffer mellem producenter og forbrugere, så en langsom efterfølgende service ikke spreder fejl op gennem systemet. Azure Service Bus er Microsofts enterprise-meddelelsesservice, som tilbyder køer (punkt til punkt) og emner (publicering-abonnement) med garanteret levering, rækkefølge og funktioner til placering af meddelelser i en dead-letter-kø.

Service Bus-navneområder og niveauer

Et Service Bus-navneområde er den øverste container for alle meddelelsesenheder (køer og emner) og leverer FQDN-slutpunktet (f.eks. myns.servicebus.windows.net). Navneområder findes i tre niveauer: Basic (kun køer, ingen emner, maksimal meddelelsesstørrelse på 256 KB), Standard (køer + emner, maksimalt 256 KB) og Premium (køer + emner, meddelelser på op til 100 MB, dedikeret kapacitet, VNet-integration og geografisk disaster recovery). Premium kræves til produktionsbelastninger, der har brug for SLA-garanteret ydeevne.

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

Køer: punkt til punkt-meddelelser

En Service Bus-kø gemmer meddelelser i FIFO-rækkefølge og leverer hver meddelelse til præcis én forbruger. Forbrugere modtager meddelelser ved hjælp af en peek-lock-mekanisme: Meddelelsen skjules midlertidigt for andre forbrugere, mens den behandles. Hvis forbrugeren gennemfører behandlingen korrekt, kalder den CompleteMessage() for at fjerne meddelelsen fra køen. Hvis behandlingen mislykkes, kalder forbrugeren AbandonMessage(), hvorefter meddelelsen bliver synlig igen til et nyt forsøg. Efter et konfigurerbart antal leveringsforsøg flyttes meddelelser, der ikke kan behandles, til dead-letter-køen (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

Emner og abonnementer

Emner implementerer mønstret publicering-abonnement: En producent sender en meddelelse til et emne, og et vilkårligt antal abonnementer på emnet modtager hver en kopi af meddelelsen. Abonnementer kan have filtre (SQL- eller korrelationsudtryk), så de kun modtager et udsnit af meddelelserne — f.eks. et HighPriority-abonnement, der kun modtager meddelelser, hvor egenskaben Priority er lig med High. Det gør det muligt for ét emne at fordele meddelelser til mange efterfølgende services, som hver især er interesserede i et forskelligt udsnit af hændelserne.

# 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'"'"''

Afsendelse og modtagelse af meddelelser

Azure Service Bus SDK leverer en ServiceBusClient til afsendelse og modtagelse. Hvis du vil sende, skal du oprette en ServiceBusSender og kalde SendMessageAsync(). Hvis du vil modtage, skal du oprette en ServiceBusReceiver og kalde ReceiveMessageAsync() (pull-baseret) eller bruge en ServiceBusProcessor med en hændelsesbehandler til push-baseret kontinuerlig behandling. Brug af DefaultAzureCredential sammen med Service Bus SDK eliminerer behovet for forbindelsesstrenge og opretholder det adgangskodefri mønster.

# 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')

Dead-letter-kø

Dead-letter-køen (DLQ) er en underkø, der automatisk modtager meddelelser, som ikke kan leveres. Meddelelser placeres i dead-letter-køen, når de overskrider det maksimale antal leveringer, udløber (TTL er gået), eller ikke består evalueringen af et emneabonnements filter. Overvågning af DLQ'en er afgørende — en DLQ, der vokser, viser en systematisk behandlingsfejl. DLQ-meddelelser bevarer deres oprindelige indhold samt egenskaberne årsag til dead-letter og beskrivelse, som Service Bus tilføjer for at hjælpe med at diagnosticere den grundlæggende årsag.

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

Meddelelsessessioner til rækkefølge

Sessioner muliggør streng rækkefølge for meddelelser, der tilhører den samme logiske gruppe. Hver meddelelse mærkes med et SessionId (f.eks. et kunde-id eller ordre-id), og en sessionsbevidst forbruger modtager alle meddelelser for en given session i FIFO-rækkefølge og eksklusivt. Sessioner er afgørende for arbejdsgange, hvor trin skal udføres i rækkefølge — f.eks. behandling af alle hændelser for en bestemt ordre: Oprettet → Betaling modtaget → Afsendt → Leveret. Sessioner aktiveres, når køen eller abonnementet oprettes.

Service Bus sammenlignet med Event Grid og Event Hubs

Disse tre Azure-meddelelsesservices forveksles ofte: Service Bus er til pålidelig, transaktionel enterprise-meddelelsesudveksling med rækkefølge, sessioner og DLQ — velegnet til ordrebehandling, finansielle transaktioner og orkestrering af arbejdsgange. Event Grid er til reaktiv hændelsesrouting (en blob blev uploadet, en VM blev slettet) med fordeling til flere behandlere, men uden rækkefølge eller afspilning. Event Hubs er til hændelsesstreaming med høj gennemstrømning (millioner af hændelser i sekundet) og mulighed for afspilning — velegnet til IoT-telemetri og indlæsning af logfiler. Vælg ud fra kravene til rækkefølge, gennemstrømning og holdbarhed.

Geografisk disaster recovery

Service Bus Geo-Disaster Recovery (Geo-DR) replikerer navneområdets metadata (køer, emner, abonnementer og adgangspolitikker) til en sekundær region. De parrede regioner deler ét aliasværtsnavn. Hvis den primære region svigter, starter du en failover, hvorefter aliaset peger på den sekundære region. Bemærk, at meddelelsesdata (meddelelser under behandling) ikke replikeres i Standard-niveauet — det er kun Premium-niveauets Geo-DR, der replikerer meddelelser. Til missionskritisk meddelelsesudveksling skal du bruge Premium + Geo-DR for at opfylde kravene til RTO og RPO.

Skalering og partitionerede enheder

Til scenarier med høj gennemstrømning skal du aktivere partitionering af køer og emner, når de oprettes. Partitionerede enheder bruger internt flere meddelelsesmæglere og lagerfragmenter, hvilket mangedobler gennemstrømningskapaciteten. I Standard-niveauet har partitionerede enheder en samlet størrelse på op til 80 GB. Hver meddelelse dirigeres til en partition baseret på egenskaben PartitionKey (som standard sessions-id'et, hvis sessioner er aktiveret). Partitionering er en engangsbeslutning ved oprettelsen — du kan ikke partitionere en eksisterende kø. Brug Premium-niveauet for den højeste garanterede gennemstrømning uden kompleksiteten ved partitionering.

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

Overvågning af Service Bus' tilstand

Vigtige Service Bus-målepunkter, du bør overvåge i Azure Monitor: Active Messages (kødybde — stigende dybde viser forsinkelse hos forbrugeren), Dead-lettered Messages (behandlingsfejl), Server Errors og User Errors (problemer med godkendelse og begrænsning af hastigheden) samt Incoming Requests (samlet gennemstrømning). Konfigurer målepunktalarmer, så driftsteams får besked, når dead-letter-køen vokser over en tærskel, eller når aktive meddelelser ikke bliver forbrugt i en længere periode.

Hurtigt tjek

Test din forståelse af begreberne fra Microsoft Azure Fundamentals (AZ-900) i denne lektion.

Besvar den i den interaktive lektion

Opsummering af lektionen

I denne lektion lærte du, at Service Bus-køer leverer punkt til punkt-meddelelser med peek-lock-levering og en dead-letter-kø til fejlramte meddelelser, at emner og abonnementer fordeler meddelelser til flere forbrugere ved hjælp af filterregler, og at sessioner muliggør ordnet behandling af meddelelser, der tilhører den samme logiske gruppe. Næste gang undersøger vi Azure Container Apps til udrulning af moderne mikrotjenester.

Gratis at komme i gang

Lær Cloud & IT Cert Prep med en AI-underviser — gratis

Skriv og kør rigtig kode i din browser, få øjeblikkelig hjælp fra en AI-underviser døgnet rundt, og fortsæt, hvor du slap, på web eller i appen.

Kurser: 150
Lektioner: 600

Start gratis Se hele kurset

Ofte stillede spørgsmål

Er lektionen “Azure Service Bus til afkoblet messaging” gratis?

Ja — hele teksten til “Azure Service Bus til afkoblet messaging” kan læses gratis her på nettet. Hvis du vil øve dig interaktivt med en indbygget kodeeditor og en AI-vejleder døgnet rundt og få adgang til resten af Cloud & IT Cert Prep-kurset, skal du opgradere til CoddyKit PRO. Cloud & IT Cert Prep-kurset indeholder 4 lektioner i alt.

Hvad lærer jeg i “Azure Service Bus til afkoblet messaging”?

Opret et Service Bus-navneområde med queues og topics, send og modtag meddelelser fra en applikation, og konfigurér dead-letter-queues til håndtering af mislykkede meddelelser. Du øver dig i Cloud & IT Cert Prep med praktisk kode, som du kører direkte i browseren, og en AI-vejleder døgnet rundt besvarer dine spørgsmål, mens du arbejder dig gennem lektionen.

Skal jeg have erfaring for at begynde på Cloud & IT Cert Prep?

Der kræves ingen tidligere erfaring. Cloud & IT Cert Prep på CoddyKit er tilrettelagt for både begyndere og øvede, så du kan starte her eller fra begyndelsen og lære i dit eget tempo. Dette er lektion 2 af 4.

Hvor lang tid tager lektionen “Azure Service Bus til afkoblet messaging”?

De fleste CoddyKit-lektioner tager cirka 5–10 minutter. Hver lektion er kort og interaktiv, så du gør løbende fremskridt og kan fortsætte, hvor du slap – på både web og app.

Kan jeg skrive og køre kode i denne Cloud & IT Cert Prep-lektion?

Ja. Alle Cloud & IT Cert Prep-lektioner har en indbygget kodeeditor, så du kan skrive og køre rigtig kode direkte i din browser og få øjeblikkelig feedback fra AI – uden lokal opsætning.

Alle lektioner i dette kursus

Managed Identity til passwordløs godkendelse
Azure Service Bus til afkoblet messaging
Azure Container Apps
Udviklerworkflow fra ende til anden

← Tilbage til Cloud & IT Cert Prep