Begrepp för Azure Event Grid-namnområden

  • Artikel

Den här artikeln beskriver de viktigaste begreppen och funktionerna som är associerade med namnområdesämnen.

Händelser

En händelse är den minsta mängd information som helt beskriver något som hände i ett system. Vi refererar ofta till en händelse som en diskret händelse eftersom den representerar ett distinkt, fristående faktum om ett system som ger en insikt som kan användas. Varje händelse har gemensam information som source händelsen, time händelsen ägde rum och en unik identifierare. Varje händelse har också en type, som vanligtvis är en unik identifierare som beskriver vilken typ av meddelande händelsen används för.

Till exempel, en händelse som handlar om en fil som har skapats i Azure Storage innehåller information om filen, såsom värdet lastTimeModified. En Event Hubs-händelse har URL:en för den insamlade filen. En händelse om en ny ordning i din Orders-mikrotjänst kan ha ett orderId attribut och ett URL-attribut till orderns tillståndsrepresentation. Några fler exempel på händelsetyper är: com.yourcompany.Orders.OrderCreated, org.yourorg.GeneralLedger.AccountChanged, io.solutionname.Auth.MaximumNumberOfUserLoginAttemptsReached.

Här är en exempelhändelse:

{
    "specversion" : "1.0",
    "type" : "com.yourcompany.order.created",
    "source" : "/orders/account/123",
    "subject" : "O-28964",
    "id" : "A234-1234-1234",
    "time" : "2018-04-05T17:31:00Z",
    "comexampleextension1" : "value",
    "comexampleothervalue" : 5,
    "datacontenttype" : "application/json",
    "data" : {
       "orderId" : "O-28964",
       "URL" : "https://com.yourcompany/orders/O-28964"
    }
}

En annan typ av händelse

Användarcommunityn refererar också till "händelser" till meddelanden som bär en datapunkt, till exempel en enskild enhetsläsning eller ett klick på en webbappssida. Den typen av händelse analyseras vanligtvis under ett tidsfönster för att härleda insikter och vidta en åtgärd. I Event Grids dokumentation refererar vi till den typen av händelse som en datapunkt, strömmande data eller helt enkelt som telemetri. Bland andra typer av meddelanden används den här typen av händelser med Event Grids MQTT-koordinatorfunktion (Message Queuing Telemetry Transport).

CloudEvents

Event Grid-namnområdesämnen accepterar händelser som följer CNCF:s öppna CloudEvents 1.0-standardspecifikation med http-protokollbindningen med JSON-format. En CloudEvent är ett slags meddelande som innehåller det som kommuniceras, kallas händelsedata och metadata om det. Händelsedata i händelsedrivna arkitekturer innehåller vanligtvis information om en ändring av systemtillståndet. CloudEvents-metadata består av en uppsättning attribut som ger sammanhangsberoende information om meddelandet, till exempel var det härstammar (källsystemet), dess typ osv. Alla giltiga meddelanden som följer CloudEvents-specifikationerna måste innehålla följande obligatoriska kontextattribut:

CloudEvents-specifikationen definierar även valfria och tilläggskontextattribut som du kan inkludera när du använder Event Grid.

När du använder Event Grid är CloudEvents det föredragna händelseformatet på grund av dess väldokumenterade användningsfall (lägen för överföring av händelser, händelseformat osv.), utökningsbarhet och förbättrad samverkan. CloudEvents förbättrar samverkan genom att tillhandahålla ett gemensamt händelseformat för publicering och användning av händelser. Det möjliggör enhetliga verktyg och standardsätt för routning och hantering av händelser.

CloudEvents con tältläge s

CloudEvents-specifikationen definierar tre con tältläge s: binär, strukturerad och batchbaserad.

Viktigt!

Med valfri con tältläge kan du utbyta text (JSON, text/*osv.) eller binärkodade händelsedata. Binärt con tältläge används inte uteslutande för att skicka binära data.

Con tältläge handlar inte om den kodning som du använder, binär eller text, utan om hur händelsedata och dess metadata beskrivs och utbyts. Den strukturerade con tältläge använder en enda struktur, till exempel ett JSON-objekt, där både kontextattributen och händelsedata är tillsammans i HTTP-nyttolasten. Binärkon tältläge separerar kontextattribut, som mappas till HTTP-huvuden och händelsedata, som är HTTP-nyttolasten kodad enligt medietypen som anges i Content-Type.

Stöd för CloudEvents

Den här tabellen visar det aktuella stödet för CloudEvents-specifikationen:

CloudEvents con tältläge Stöds?
Strukturerad JSON Ja
Strukturerad JSON batch Ja, för publiceringshändelser
Binära Ja, för publiceringshändelser

Den maximala tillåtna storleken för en händelse är 1 MB. Händelser över 64 KB debiteras i steg om 64 KB.

Strukturerade tältläge

Ett meddelande i CloudEvents structured con tältläge har både kontextattributen och händelsedata tillsammans i en HTTP-nyttolast.

Viktigt!

För närvarande stöder Event Grid CloudEvents JSON-format med HTTP.

Här är ett exempel på en CloudEvents i strukturerat läge med JSON-format. Både metadata (alla attribut som inte är "data") och meddelande-/händelsedata ("data"-objektet) beskrivs med JSON. Vårt exempel innehåller alla obligatoriska kontextattribut tillsammans med några valfria attribut (subject, time, och datacontenttype) och tilläggsattribut (comexampleextension1, comexampleothervalue).

{
    "specversion" : "1.0",
    "type" : "com.yourcompany.order.created",
    "source" : "/orders/account/123",
    "subject" : "O-28964",
    "id" : "A234-1234-1234",
    "time" : "2018-04-05T17:31:00Z",
    "comexampleextension1" : "value",
    "comexampleothervalue" : 5,
    "datacontenttype" : "application/json",
    "data" : {
       "orderId" : "O-28964",
       "URL" : "https://com.yourcompany/orders/O-28964"
    }
}

Du kan använda JSON-formatet med strukturerat innehåll för att skicka händelsedata som inte är ett JSON-värde. I detta syfte gör du följande:

  1. Inkludera ett datacontenttype attribut med medietypen där data kodas.
  2. Om medietypen är kodad i ett textformat som text/plain, text/csveller application/xml, bör du använda ett data attribut med en JSON-sträng som innehåller det du kommunicerar som värde.
  3. Om medietypen representerar en binär kodning bör du använda ett data_base64 attribut vars värde är en JSON-sträng som innehåller det BASE64-kodade binära värdet.

Den här CloudEvent har till exempel händelsedata kodade i application/protobuf för att utbyta Protobuf-meddelanden.

{
    "specversion" : "1.0",
    "type" : "com.yourcompany.order.created",
    "source" : "/orders/account/123",
    "id" : "A234-1234-1234",
    "time" : "2018-04-05T17:31:00Z",
    "datacontenttype" : "application/protobuf",
    "data_base64" : "VGhpcyBpcyBub3QgZW5jb2RlZCBpbiBwcm90b2J1ZmYgYnV0IGZvciBpbGx1c3RyYXRpb24gcHVycG9zZXMsIGltYWdpbmUgdGhhdCBpdCBpcyA6KQ=="
}

Mer information om användningen av attributen data eller data_base64 finns i Hantera data .

Mer information om den här con tältläge finns i CloudEvents HTTP structured con tältläge specifications .

Batchkon tältläge

Event Grid stöder för närvarande JSON-batchkon tältläge vid publicering av CloudEvents till Event Grid. Den här con tältläge använder en JSON-matris fylld med CloudEvents i strukturerade con tältläge. Ditt program kan till exempel publicera två händelser med hjälp av en matris som följande. På samma sätt, om du använder Event Grids SDK för dataplanet, är den här nyttolasten också det som skickas:

[
    {
        "specversion": "1.0",
        "id": "E921-1234-1235",
        "source": "/mycontext",
        "type": "com.example.someeventtype",
        "time": "2018-04-05T17:31:00Z",
        "data": "some data"
    },
    {
        "specversion": "1.0",
        "id": "F555-1234-1235",
        "source": "/mycontext",
        "type": "com.example.someeventtype",
        "time": "2018-04-05T17:31:00Z",
        "data": {
            "somekey" : "value",
            "someOtherKey" : 9
        }
    }
]

Mer information finns i CloudEvents Specifikationer för batchbaserat innehållsläge .

Batchbearbetning

Programmet bör gruppera flera händelser i en matris för att uppnå större effektivitet och högre dataflöde med en enda publiceringsbegäran. Batchar kan vara upp till 1 MB och den maximala storleken för en händelse är 1 MB.

Binärt con tältläge

En CloudEvent i binärt tältläge har sina kontextattribut som beskrivs som HTTP-huvuden. Namnen på HTTP-huvudena är namnet på kontextattributet som prefixet med ce-. Rubriken Content-Type visar medietypen där händelsedata kodas.

Viktigt!

När du använder binärkon tältläge ce-datacontenttype måste HTTP-huvudet INTE också finnas.

Viktigt!

Om du planerar att inkludera dina egna attribut (dvs. tilläggsattribut) när du använder binärt con tältläge kontrollerar du att deras namn består av gemener ("a" till "z") eller siffror ("0" till "9") från ASCII-tecknet och att de inte överskrider 20 tecken. Namngivningskonventionen för namngivning av CloudEvents-kontextattribut är alltså mer restriktiv än för giltiga HTTP-huvudnamn. Alla giltiga HTTP-huvudnamn är inte ett giltigt tilläggsattributnamn.

HTTP-nyttolasten är händelsedata som kodas enligt medietypen i Content-Type.

En HTTP-begäran som används för att publicera en CloudEvent i binärt innehållsläge kan se ut så här:

POST / HTTP/1.1
HOST mynamespace.eastus-1.eventgrid.azure.net/topics/mytopic
ce-specversion: 1.0
ce-type: com.example.someevent
ce-source: /mycontext
ce-id: A234-1234-1234
ce-time: 2018-04-05T17:31:00Z
ce-comexampleextension1: value
ce-comexampleothervalue: 5
content-type: application/protobuf

Binary data according to protobuf encoding format. No context attributes are included.

När du ska använda CloudEvents binära eller strukturerade con tältläge

Du kan använda strukturerade con tältläge om du vill ha en enkel metod för vidarebefordran av CloudEvents mellan hopp och protokoll. Eftersom en CloudEvent i strukturerad con tältläge innehåller meddelandet tillsammans med dess metadata, är det enkelt för klienter att använda det som helhet och vidarebefordra det till andra system.

Du kan använda binär con tältläge om du vet att underordnade program bara kräver meddelandet utan extra information (det vill: kontextattributen). Med strukturerad con tältläge kan du fortfarande hämta händelsedata (meddelande) från CloudEvent, men det är enklare om ett konsumentprogram bara har dem i HTTP-nyttolasten. Andra program kan till exempel använda andra protokoll och kanske bara vara intresserade av ditt kärnmeddelande, inte dess metadata. Faktum är att metadata kan vara relevanta bara för det omedelbara första hoppet. I det här fallet är det enklare att hantera och vidarebefordra data som du vill utbyta förutom dess metadata.

Utgivare

En utgivare är det program som skickar händelser till Event Grid. Det kan vara samma program där händelserna har sitt ursprung, händelsekällan. Du kan publicera händelser från ditt eget program när du använder namnområdesämnen.

Händelsekällor

En händelsekälla är platsen där händelsen inträffar. Varje händelsekälla stöder en eller flera händelsetyper. Ditt program är till exempel händelsekällan för anpassade händelser som systemet definierar. När du använder namnområdesämnen är de händelsekällor som stöds dina egna program.

Namnrymder

Ett Event Grid-namnområde är en hanteringscontainer för följande resurser:

Resurs Protokoll som stöds
Namnområdesämnen HTTP
Ämnesutrymmen MQTT
Klienter MQTT
Klientgrupper MQTT
CA-certifikat MQTT
Behörighetsbindningar MQTT

Med ett Azure Event Grid-namnområde kan du gruppera relaterade resurser och hantera dem som en enda enhet i din Azure-prenumeration. Det ger dig ett unikt fullständigt kvalificerat domännamn (FQDN).

Ett namnområde exponerar två slutpunkter:

  • En HTTP-slutpunkt för att stödja allmänna meddelandekrav med hjälp av namnområdesämnen.
  • En MQTT-slutpunkt för IoT-meddelanden eller lösningar som använder MQTT.

Ett namnområde innehåller även DNS-integrerade nätverksslutpunkter. Den innehåller också en rad funktioner för åtkomstkontroll och hantering av nätverksintegrering, till exempel offentlig IP-ingressfiltrering och privata länkar. Det är också containern med hanterade identiteter som används för inneslutna resurser i namnområdet.

Här är några fler punkter om namnområden:

  • Namnområdet är en spårad resurs med tags och location egenskaper, och när den har skapats kan den hittas på resources.azure.com.
  • Namnet på namnområdet kan vara 3–50 tecken långt. Den kan innehålla alfanumeriska och bindestreck(-) och inga blanksteg.
  • Namnet måste vara unikt per region.
  • Aktuella regioner som stöds: USA, centrala, Asien, östra, USA, östra, USA, östra 2, Europa, norra, USA, södra centrala, Sydostasien, Förenade Arabemiraten, norra, Europa, västra, USA, västra 2, USA, västra 3.

Genomflödesenheter

Dataflödesenheter (TUs) definierar ingress- och utgående händelsefrekvenskapacitet i namnområden. Mer information finns i kvoter och gränser för Azure Event Grid.

Ämnen

Ett ämne innehåller händelser som har publicerats till Event Grid. Du använder vanligtvis en ämnesresurs för en samling relaterade händelser. Vi hänvisade ofta till ämnen i ett namnområde som namnområdesämnen.

Namnområdesämnen

Namnområdesämnen är ämnen som skapas i ett Event Grid-namnområde. Ditt program publicerar händelser till en HTTP-namnområdesslutpunkt som anger ett namnområdesavsnitt där publicerade händelser är logiskt inneslutna. När du utformar ditt program måste du bestämma hur många ämnen som ska skapas. För relativt stora lösningar skapar du ett namnområdesavsnitt för varje kategori av relaterade händelser. Tänk dig till exempel ett program som hanterar användarkonton och ett annat program om kundbeställningar. Det är osannolikt att alla händelseprenumeranter vill ha händelser från båda programmen. Om du vill skilja på problem skapar du två namnområdesämnen: ett för varje program. Låt händelsekonsumenter prenumerera på ämnet enligt deras krav. För små lösningar kanske du föredrar att skicka alla händelser till ett enda ämne.

Namnområdesämnen stöder pull-leverans och push-leverans. Se när du ska använda pull- eller push-leverans för att avgöra om pull-leverans är rätt metod med tanke på dina krav.

Prenumerationer på händelser

En händelseprenumeration är en konfigurationsresurs som är associerad med ett enskilt ämne. Du kan bland annat använda en händelseprenumeration för att ange kriterier för händelseval för att definiera den händelsesamling som är tillgänglig för en prenumerant av den totala uppsättningen händelser som är tillgängliga i ett ämne. Du kan filtrera händelser enligt prenumerantens krav. Du kan till exempel filtrera händelser efter deras händelsetyp. Du kan också definiera filtervillkor för händelsedataegenskaper om du använder ett JSON-objekt som värde för dataegenskapen. Om du vill ha mer information om resursegenskaper letar du efter kontrollplansåtgärder i Event Grid REST API.

Diagram som visar ett ämne och associerade händelseprenumerationer.

Ett exempel på hur du skapar prenumerationer för namnområdesämnen finns i Publicera och använda meddelanden med hjälp av namnområdesämnen med HJÄLP av CLI.

Kommentar

Händelseprenumerationer under ett namnområdesämne har en förenklad resursmodell jämfört med den som används för anpassade ämnen, domäner, partner och systemämnen (Event Grid Basic). Mer information finns i Skapa, visa och hantera händelseprenumerationer.

Pull-leverans

Med pull-leverans ansluter ditt program till Event Grid för att läsa meddelanden med hjälp av köliknande semantik. När program ansluter till Event Grid för att använda händelser har de kontroll över händelseförbrukningen och tidpunkten. Konsumentprogram kan också använda privata slutpunkter när de ansluter till Event Grid för att läsa händelser med privat IP-utrymme.

Pull-leverans stöder följande åtgärder för att läsa meddelanden och kontrollera meddelandetillståndet: ta emot, bekräfta, släppa, avvisa och förnya lås. Mer information finns i översikt över pull-leverans.

Dataform när du tar emot händelser med pull-leverans

När du levererar händelser med pull-leverans innehåller Event Grid en matris med objekt som i sin tur innehåller objekten event och brokerProperties . Värdet för händelseegenskapen är CloudEvent som levereras i strukturerade con tältläge. BrokerProperties-objektet innehåller låstoken som är associerad med den levererade CloudEvent. Följande json-objekt är ett exempelsvar från en mottagningsåtgärd som returnerar två händelser:

{
    "value": [
        {
            "brokerProperties": {
                "lockToken": "CiYKJDUwNjE4QTFFLUNDODQtNDZBQy1BN0Y4LUE5QkE3NjEwNzQxMxISChDXYS23Z+5Hq754VqQjxywE",
                "deliveryCount": 2
            },
            "event": {
                "specversion": "1.0",
                "id": "A234-1234-1235",
                "source": "/mycontext",
                "time": "2018-04-05T17:31:00Z",
                "type": "com.example.someeventtype",
                "data": "some data"
            }
        },
        {
            "brokerProperties": {
                "lockToken": "CiYKJDUwNjE4QTFFLUNDODQtNDZBQy1BN0Y4LUE5QkE3NjEwNzQxMxISChDLeaL+nRJLNq3/5NXd/T0b",
                "deliveryCount": 1
            },
            "event": {
                "specversion": "1.0",
                "id": "B688-1234-1235",
                "source": "/mycontext",
                "type": "com.example.someeventtype",
                "time": "2018-04-05T17:31:00Z",
                "data": {
                    "somekey" : "value",
                    "someOtherKey" : 9
                }
            }
        }
    ]
}

Push-leverans

Med push-leverans skickar Event Grid händelser till ett mål som konfigurerats i en push-händelseprenumeration (leveransläge i). Det ger en robust logik för återförsök om målet inte kan ta emot händelser.

Viktigt!

Event Grid-namnrymdernas push-leverans stöder för närvarande Azure Event Hubs som mål. I framtiden kommer Event Grid-namnområden att ha stöd för fler destinationer, inklusive alla destinationer som stöds av Event Grid Basic.

Händelseleverans för Event Hubs

Event Grid använder Event Hubs SDK för att skicka händelser till Event Hubs med AMQP. Händelser skickas som en bytematris med varje element i matrisen som innehåller en CloudEvent.

Push- och pull-leverans

Event Grid stöder leverans av push- och pull-händelser med HTTP. Med push-leverans definierar du ett mål i en händelseprenumeration, en webhook eller en Azure-tjänst som Event Grid skickar händelser till. Med pull-leverans ansluter prenumerantprogram till Event Grid för att använda händelser. Pull-leverans stöds för ämnen i ett Event Grid-namnområde.

Viktigt!

Event Hubs stöds som mål för prenumerationer till namnområdesämnen. I kommande versioner kommer Event Grid-namnområden att stödja alla mål som för närvarande är tillgängliga i Event Grid Basic tillsammans med ytterligare destinationer.

Diagram på hög nivå som visar push-leverans och pull-leverans med den typ av resurser som ingår.

När du ska använda push-leverans jämfört med pull-leverans

Följande är allmänna riktlinjer som hjälper dig att bestämma när du ska använda pull- eller push-leverans.

Pull-leverans

  • Du behöver fullständig kontroll över när händelser ska ta emot. Ditt program kanske till exempel inte är igång hela tiden, inte tillräckligt stabilt, eller så bearbetar du data vid vissa tidpunkter.
  • Du behöver fullständig kontroll över händelseförbrukningen. Till exempel har en underordnad tjänst eller ett lager i ditt konsumentprogram ett problem som hindrar dig från att bearbeta händelser. I så fall tillåter PULL-leverans-API:et att konsumentappen släpper en redan läst händelse till asynkron meddelandekö så att den kan levereras senare.
  • Du vill använda privata länkar när du tar emot händelser, vilket endast är möjligt med pull-leveransen, inte push-leveransen.
  • Du har inte möjlighet att exponera en slutpunkt och använda push-leverans, men du kan ansluta till Event Grid för att använda händelser.

Push-leverans

  • Du vill undvika konstant avsökning för att fastställa att en systemtillståndsändring har inträffat. Du använder hellre Event Grid för att skicka händelser till dig när tillståndsändringar sker.
  • Du har ett program som inte kan göra utgående anrop. Din organisation kan till exempel vara bekymrad över dataexfiltrering. Ditt program kan dock ta emot händelser via en offentlig slutpunkt.

Nästa steg