Event Grid och händelsestyrd arkitektur

I en händelsestyrd arkitektur kommunicerar komponenter genom att publicera och prenumerera på händelser i stället för att anropa varandra direkt. En komponent (producent) genererar en händelse när något anmärkningsvärt inträffar — en fil laddas upp, en order läggs eller en enhet skickar ett mätvärde. Andra komponenter (prenumeranter) reagerar på de händelser de är intresserade av, oberoende av varandra och asynkront. Det innebär att producenter och konsumenter frikopplas, vilket förbättrar skalbarhet, motståndskraft och underhållbarhet.

Azure Event Grid är en fullständigt hanterad tjänst för händelseroutning som levererar händelser från källor (publicerare) till hanterare (prenumeranter) med hjälp av en push-modell. Event Grid är utformat för reaktiva, diskreta händelser — något har ändrats och du behöver reagera omedelbart. Tjänsten garanterar leverans minst en gång med automatiska nya försök, stöder filtrering så att prenumeranter endast tar emot relevanta händelser och kan dirigera händelser till Azure Functions, Logic Apps, webhooks, Event Hubs och Service Bus-köer.

Publicerare skickar händelser till ett Event Grid-ämne. Prenumeranter skapar händelseprenumerationer på ett ämne och anger en slutpunkt samt valfria filterregler. Ett och samma ämne kan ha flera prenumerationer — varje prenumeration tar emot en separat kopia av matchande händelser. Azure-tjänster som Blob Storage, Resource Manager, Service Bus och Azure Container Registry är inbyggda händelsekällor med systemämnen som inte kräver någon ytterligare konfiguration.

Händelser som publiceras till Event Grid följer ett standardiserat JSON-schema med obligatoriska fält: id (unik identifierare), eventType (t.ex. Microsoft.Storage.BlobCreated), subject (sökväg till händelseresursen), eventTime (tidsstämpel enligt ISO 8601), dataVersion och data (nyttolast som är specifik för händelsen). Event Grid stöder även CloudEvents-schema (CNCF-standard) för interoperabilitet med andra händelseplattformar.

Händelseprenumerationer stöder filtrering för att minska mängden brus hos prenumeranten. Du kan filtrera efter händelsetyp (ta endast emot BlobCreated, inte BlobDeleted), prefix eller suffix för ämnet (endast blobbar i en viss container) eller avancerade filter på valfritt fält i händelsedata med operatorer som StringContains, NumberGreaterThan och BoolEquals. Filtreringen sker på serversidan, så prenumeranter tar endast emot händelser som matchar deras kriterier.

Tre Azure-tjänster hanterar händelser och meddelanden — välj utifrån ditt scenario. Event Grid är avsett för reaktiv händelseroutning (låg volym, diskreta och reaktiva händelser — till exempel en avisering om en resursändring). Event Hubs är avsett för händelseströmning med hög genomströmning (miljontals händelser per sekund, telemetri och stordatapipelines). Service Bus är avsett för meddelandehantering i företag med ordning, deduplicering, dead-lettering och transaktioner (orderhantering och finansiella transaktioner).

Publicera anpassade händelser till ett Event Grid-ämne med en enkel HTTP POST-begäran och ämnets åtkomstnyckel. Alla tjänster eller program som kan skicka HTTP-begäranden kan publicera händelser. Det gör det enkelt att generera händelser från lokala program, tjänster från tredje part eller Azure-tjänster som saknar inbyggt stöd för Event Grid. Bunta ihop händelser på upp till 1 MB per POST för bättre effektivitet.

Om ett försök att leverera en händelse misslyckas (prenumeranten returnerar HTTP-statuskoden non-2xx) gör Event Grid nya försök med exponentiell backoff och jitter i upp till 24 timmar (konfigurerbart till högst 72 timmar), med maximalt 30 försök. När alla försök har förbrukats kan Event Grid använda dead-lettering för att lagra oöverförda händelser i en Azure Blob Storage-container för manuell undersökning. Konfigurera dead-lettering när tillförlitlig händelseleverans är kritisk och du behöver granska eller bearbeta misslyckade händelser igen.

Azure Event Hubs är en distribuerad plattform för dataströmning som kan ta emot och bearbeta miljontals händelser per sekund. Den använder en partitionerad konsumentmodell — händelser distribueras över partitioner och varje konsumentgrupp läser händelser oberoende av de andra i sin egen takt. Det gör att flera konsumenter kan bearbeta samma ström utan samordning. Vanliga användningsområden är insamling av IoT-telemetri, aggregering av programloggar, analys av klickströmmar och datapipelines för instrumentpaneler i realtid.

Azure Service Bus är en meddelandeförmedlare för företag som tillhandahåller köer (punkt-till-punkt) och ämnen med prenumerationer (publicera-prenumerera). Till skillnad från Event Grid (fire-and-forget) och Event Hubs (strömning) garanterar Service Bus leverans i ordning (FIFO-köer), identifiering av dubbletter, dead-letter-köer för bearbetningsfel, meddelandesessioner för grupperad bearbetning och transaktioner — allt sådant som är viktigt för arbetsflöden för finansiella transaktioner och orderhantering.

Ett vanligt händelsestyrt mönster i Azure är att en användare laddar upp en fil till Blob Storage, som utlöser en BlobCreated-händelse till Event Grid. Event Grid dirigerar händelsen till en Azure Function som bearbetar filen (ändrar storlek på en bild, extraherar text eller validerar data) och skriver resultatet till Azure SQL Database. Om bearbetningen misslyckas lagras händelsen i en dead-letter-kö i en lagringscontainer. Hela denna pipeline kräver ingen avfrågning och ingen beständig beräkningskapacitet när den är inaktiv.

I den här lektionen lärde du dig att Azure Event Grid dirigerar diskreta händelser från publicerare till prenumeranter med push-leverans, filtrering och dead-lettering, den viktigaste skillnaden mellan Event Grid (reaktiva händelser), Event Hubs (strömning) och Service Bus (tillförlitlig meddelandehantering för företag) samt hur du bygger händelsestyrda pipelines genom att koppla Blob Storage-händelser via Event Grid till Azure Functions. Härnäst utforskar vi Azure DevOps-tjänster.