Event Grid og hendelsesdrevet arkitektur

I en hendelsesdrevet arkitektur kommuniserer komponenter ved å publisere og abonnere på hendelser, i stedet for å kalle hverandre direkte. En komponent (produsent) genererer en hendelse når noe bemerkelsesverdig skjer – en fil lastes opp, en ordre legges inn eller en enhet sender en måling. Andre komponenter (abonnenter) reagerer på hendelser de er interessert i, uavhengig av hverandre og asynkront. Dette kobler produsenter og forbrukere fra hverandre, noe som forbedrer skalerbarhet, robusthet og vedlikeholdbarhet.

Azure Event Grid er en fullstendig administrert tjeneste for hendelsesruting som leverer hendelser fra kilder (utgivere) til behandlere (abonnenter) ved hjelp av en push-modell. Event Grid er utviklet for reaktive, diskrete hendelser – noe har blitt endret, og du må reagere umiddelbart. Tjenesten garanterer levering minst én gang med automatisk nytt forsøk, støtter filtrering slik at abonnenter bare mottar relevante hendelser, og kan rute hendelser til Azure Functions, Logic Apps, webhooks, Event Hubs og Service Bus-køer.

Utgivere sender hendelser til et Event Grid-emne. Abonnenter oppretter hendelsesabonnementer på et emne og angir et endepunkt og eventuelle filterregler. Ett emne kan ha flere abonnementer – hvert abonnement mottar en uavhengig kopi av hendelser som samsvarer. Azure-tjenester som Blob Storage, Resource Manager, Service Bus og Azure Container Registry er innebygde hendelseskilder med systememner som ikke krever ytterligere konfigurasjon.

Hendelser som publiseres til Event Grid, følger et standardisert JSON-skjema med obligatoriske felt: id (unik identifikator), eventType (for eksempel Microsoft.Storage.BlobCreated), subject (bane til hendelsesressursen), eventTime (ISO 8601-tidsstempel), dataVersion og data (hendelsesspesifikk nyttelast). Event Grid støtter også CloudEvents-skjemaet (CNCF-standard) for samhandling med andre hendelsesplattformer.

Hendelsesabonnementer støtter filtrering for å redusere mengden støy hos abonnenten. Du kan filtrere etter hendelsestype (motta bare BlobCreated, ikke BlobDeleted), prefiks eller suffiks for emnet (bare blobber i en bestemt container), eller avanserte filtre på alle felt i hendelsesdataene ved hjelp av operatorer som StringContains, NumberGreaterThan og BoolEquals. Filtreringen skjer på serversiden, slik at abonnenter bare mottar hendelser som oppfyller kriteriene deres.

Tre Azure-tjenester håndterer hendelser og meldinger – velg ut fra scenariet ditt. Event Grid brukes til reaktiv hendelsesruting (lavt volum, diskrete og reaktive hendelser – for eksempel varsler om ressursendringer). Event Hubs brukes til hendelsesstrømming med høy gjennomstrømming (millioner av hendelser per sekund, telemetri og datapipelines for stordata). Service Bus brukes til bedriftsmeldinger med rekkefølge, deduplisering, meldinger som legges i kø for senere behandling, og transaksjoner (ordrebehandling og finansielle transaksjoner).

Publiser egendefinerte hendelser til et Event Grid-emne ved hjelp av en enkel HTTP POST-forespørsel med tilgangsnøkkelen til emnet. Alle tjenester eller applikasjoner som kan sende HTTP-forespørsler, kan publisere hendelser. Dermed blir det enkelt å generere hendelser fra lokale applikasjoner, tredjepartstjenester eller Azure-tjenester som ikke har innebygd støtte for Event Grid. Du kan samle opptil 1 MB med hendelser i hver POST for bedre effektivitet.

Hvis et leveringsforsøk for en hendelse mislykkes (abonnenten returnerer en HTTP-status utenfor 2xx), prøver Event Grid på nytt med eksponentiell tilbakekobling og tilfeldig variasjon i opptil 24 timer (kan konfigureres til opptil 72 timer), med maksimalt 30 forsøk. Når alle forsøkene er brukt opp, kan Event Grid legge hendelser som ikke ble levert, i en dead-letter-kø i en Azure Blob Storage-container for manuell undersøkelse. Konfigurer dead-lettering når pålitelig hendelseslevering er kritisk, og du trenger å revidere eller behandle mislykkede hendelser på nytt.

Azure Event Hubs er en distribuert plattform for datastrømming som kan motta og behandle millioner av hendelser per sekund. Den bruker en partisjonert forbrukermodell – hendelser fordeles på partisjoner, og hver forbrukergruppe leser hendelser uavhengig av de andre, i sitt eget tempo. Dette gjør det mulig for flere forbrukere å behandle den samme strømmen uten koordinering. Vanlige bruksområder er innsamling av IoT-telemetri, samling av applikasjonslogger, analyse av klikkstrømmer og datapipelines for sanntidsinstrumentbord.

Azure Service Bus er en meldingsmegler for bedrifter som tilbyr køer (punkt-til-punkt) og emner med abonnementer (publisering-abonnement). I motsetning til Event Grid (send-og-glem) og Event Hubs (strømming) garanterer Service Bus ordnet levering (FIFO-køer), deteksjon av duplikater, dead-letter-køer for behandlingsfeil, meldingsøkter for gruppert behandling og transaksjoner – alt dette er viktig for arbeidsflyter for økonomi- og ordrebehandling.

Et vanlig hendelsesdrevet mønster i Azure er at en bruker laster opp en fil til Blob Storage, som utløser en BlobCreated-hendelse til Event Grid. Event Grid ruter hendelsen til en Azure Function som behandler filen (endrer størrelsen på et bilde, trekker ut tekst eller validerer data) og skriver resultatet til Azure SQL Database. Hvis behandlingen mislykkes, legges hendelsen i en dead-letter-kø i en lagringscontainer. Hele denne pipelinen krever ingen polling og ingen vedvarende databehandling når den er inaktiv.

I denne leksjonen har du lært at Azure Event Grid ruter diskrete hendelser fra utgivere til abonnenter ved hjelp av push-levering, filtrering og dead-lettering, hva som er den viktigste forskjellen mellom Event Grid (reaktive hendelser), Event Hubs (strømming) og Service Bus (pålitelig meldingsbehandling for bedrifter), og hvordan du bygger hendelsesdrevne pipelines ved å koble Blob Storage-hendelser via Event Grid til Azure Functions. Neste gang skal vi utforske Azure DevOps-tjenester.