Settembre 2018

Volume 33 numero 9

Il presente articolo è stato tradotto automaticamente.

Azure - gestione di recapito di eventi con griglia di eventi di Azure

Dal David Barkol

Griglia di eventi è un servizio di messaggistica completamente gestito in Microsoft Azure che fornisce un approccio innovativo per il routing di eventi nel cloud e oltre. Ha sbloccato nuove e i modelli univoci per le soluzioni come basata su eventi sono progettati con una potente e flessibile modello pubblicazione-sottoscrizione.

È stata fornita un'introduzione a griglia di eventi di Azure nel numero di febbraio 2018 (aka.ms/eventgridarticle) che illustra le nozioni di base del servizio e come può essere usato per pubblicare e utilizzare gli eventi in vari modi. In questo articolo, viene approfondito come gli eventi vengono recapitati e quali sono le opzioni per i criteri di ripetizione dei tentativi, gli eventi non è validi ed eventi che non sono stati recapitati correttamente. Prima di esplorare, sarà utile esaminare il funzionamento di griglia di eventi a livello generale.

Una breve panoramica di griglia di eventi

Con griglia di eventi di Azure, le origini eventi possono provenire da un elenco in continua crescita di servizi di Azure, ad esempio hub eventi e servizi multimediali, o anche da un'applicazione personalizzata che è in esecuzione in locale o all'interno di un altro provider di servizi cloud o Data Center. Questi eventi vengono utilizzati e gestiti da griglia di eventi, che è responsabile per l'inserimento in blocco dei messaggi e della relativa distribuzione per ogni sottoscrizione di eventi. I gestori eventi vengono utilizzati per agire sugli eventi in ingresso e possono essere servizi in Azure. Uno scenario molto comune è quello che si basa su altre tecnologie senza server, ad esempio le funzioni e App per la logica. Insieme, queste soluzioni altamente scalabile e flessibile possono essere composte in modo molto rapido e conveniente senza il peso della gestione di qualsiasi infrastruttura.

Un gestore eventi può anche essere un semplice WebHook, il che significa che è esattamente come un'origine evento, può risiedere in un punto qualsiasi, purché supporta il protocollo HTTPS e può accettare una richiesta POST. Questo approccio indipendente dalla piattaforma e linguaggio è una delle numerose opzioni che rendono griglia di eventi di un servizio molto speciale che ha solo l'inizio di aprire nuove soluzioni nel cloud. Figura 1 illustra come griglia di eventi consente di connettere più origini e gestori. L'elenco dei servizi di Azure che si integrano con griglia di eventi è in continua crescita e solo un subset è raffigurato nel diagramma.

Figura 1 Panoramica di griglia di eventi di Azure

Recapito di eventi e codici di risposta

Griglia di eventi considera ogni evento in modo indipendente. Ciò significa che c'è un ordine garantito per gli eventi e, in alcuni casi, un evento può essere recapitato più di una volta. Pertanto, è responsabilità del gestore eventi da codificare in modo sicuro e siano idempotenti. L'invio ripetutamente lo stesso evento deve produrre lo stesso risultato. Se l'ordinamento degli eventi è un requisito, si devono essere gestito ai lati calcolo (all'interno della logica del gestore dell'evento) o tramite un altro servizio, ad esempio il Bus di servizio o agli hub eventi per mantenere l'ordine.

Si è determineranno la risposta HTTP restituito dal gestore eventi a griglia di eventi come procederà con la gestione dell'evento. I codici di stato 200 OK e 202 Accepted sono considerati un acknowledgement di un evento di recapito senza.

Uno dei seguenti codici di errore è indicativo di un tentativo di recapito non riuscito: 400-richiesta 401-non autorizzato, 404 non trovato, 408-Timeout richiesta, 414-URI richiesta troppo a lungo e 500 Errore interno del Server, 503-Servizio non disponibile e 504 Gateway Timeout. A seconda del codice di errore, griglia di eventi può essere ritentata l'invio dell'evento all'endpoint. Verrà approfondita in appena un po'.

Criteri di ripetizione

Se viene restituito un codice di errore o non viene ricevuto un acknowledgement, un altro tentativo verrà eseguito per inviare l'evento all'endpoint. Un criterio di ripetizione dei tentativi che impiega un backup esponenziale viene inserito quindi nello grado di tentare un recapito finale dell'evento prima della scadenza. Per impostazione predefinita, un evento scadono dopo 24 ore di recapito con esito negativo. Dopo il primo tentativo, la pianificazione di recapito sarà il backoff, usando la sequenza temporale seguente: 10 secondi, 30 secondi e 1 minuto, 5 minuti, 10 minuti, 30 minuti e 1 ora. Dopo il primo tentativo di un'ora, ogni richiesta successiva viene eseguita una volta ogni ora fino a quando non viene raggiunto il time-to-live (TTL).

Una nuova funzionalità di griglia di eventi consente di configurare i criteri di ripetizione dei tentativi per una sottoscrizione di eventi da due valori possibili di impostazione:

Numero massimo tentativi di recapito è un valore configurabile che consente di impostare i tentativi di ripetizione dei tentativi massimo per una sottoscrizione di eventi. Il valore predefinito e massimo consentito, è 30.

Eventi durata (TTL) sono un valore che corrisponde all'impostazione della durata-TTL per un evento. Il valore predefinito, nonché l'impostazione massima, viene 1.440 minuti (24 ore).

Una di queste proprietà possono essere utilizzate per gestire i criteri di ripetizione dei tentativi a livello di sottoscrizione di eventi e possono essere utile quando un evento è interessante è solo per un breve periodo di tempo o gettato intenzionalmente un errore, ad esempio 503 per proteggere il computer durante l'elevato livello di verifica 3!d.

Non è valido e la lettera canali

Una delle responsabilità primaria di un servizio di messaggistica è garantire che un messaggio venga recapitato correttamente. Tuttavia, non può garantire che il ricevitore del messaggio in questione verrà di gestirlo correttamente.

In alcuni casi, il destinatario di un evento potrebbe rifiutare il messaggio se non è conforme determinati obiettivi. Ciò può arrivare in forma di un tipo di dati non validi o payload o un messaggio non autorizzato. In questo caso, il messaggio viene spostato in genere in una posizione designata, noto anche come un canale di messaggio non valido.

Un altro scenario comune è un messaggio che viene inviato correttamente, ma non può essere elaborato a causa di un errore sul lato ricevente. Si tratta in genere i codici di stato di livello 500 che indicano un errore del servizio o l'indisponibilità del servizio. In genere, il servizio di messaggistica ritenterà l'invio di questi messaggi fino a quando non viene soddisfatta una determinata soglia e il messaggio viene considerato non recapitabile. Una lettera non consegnata channelis utilizzato, in modo analogo al canale di messaggio non valido, per archiviare tali messaggi insieme a tutti i metadati pertinenti.

L'esigenza in entrambi gli scenari è che non vi siano alcune utilità o un servizio che consente di monitorare i canali e saprà cosa fare con i messaggi. Ciò può presentarsi in un report pianificato o forse un altro servizio basato su eventi, ad esempio un'App per la logica, che può prelevare il messaggio e inviare notifiche agli utenti finali o altri sistemi e servizi.

Mancato recapito dei messaggi con griglia di eventi

Una funzionalità molto richiesta per griglia di eventi di Azure a breve dopo che è stato rilasciato consisteva nel fornire un meccanismo per l'acquisizione degli eventi che non è stato possibile recapitare. Questa funzionalità ha recentemente forniti alla luce dello sdoganamento con la possibilità di configurare i criteri di ripetizione dei tentativi e il percorso di lettera non consegnata per ogni sottoscrizione di eventi. Con questa funzionalità, ora è possibile configurare il canale di lettera non consegnata in un Account di archiviazione di Azure che consente di acquisire il messaggio e le informazioni pertinenti sul recapito. Questo stesso endpoint verrà usato come lettera non consegnata sia un canale di messaggio non valido. Figura 2 viene illustrato come gli eventi di lettera non consegnata sono ora supportati in griglia di eventi di Azure.

Figura 2 eventi di lettera non consegnata

Voglio sottolineare un paio di informazioni importanti prima di scriverci un esempio che usa i criteri di ripetizione dei tentativi sia la lettera non consegnata recapito.

Si noti che le frecce provenienti dall'argomento di griglia di eventi verranno nella direzione dei gestori. Vorrei sottolineare questa per ribadire il concetto che griglia di eventi è un modello push push. I gestori eventi offrono un webhook che viene chiamato da griglia di eventi al momento per inviare un evento. Questa decisione progettuale importante evidenzia la natura basata su eventi del servizio. A differenza di altri servizi di messaggistica, non è più necessario ricorrere a tecniche di polling prolungato o hammer-polling per verificare se un messaggio è disponibile. Al contrario, un gestore può basarsi su questo modello per ricevere una notifica di nuovi eventi, ovvero un altro motivo perché sono interessanti tecnologie senza server, ad esempio App per la logica e funzioni per i gestori eventi. È possibile mettere in pratica.

Installazione

A questo punto verrà illustrato i passaggi di impostazione e configurazione di entrambi i criteri di ripetizione dei tentativi e un endpoint di lettera non consegnata. Inoltre, può essere utile anche controllare gli eventi di lettera non consegnata e intraprendere le azioni appena diventano disponibili.

Tutto quello che voglio impostare in Azure verrà eseguita da Azure Cloud Shell. In questo modo è possibile farlo da qualsiasi computer e non essere preoccuparsi di eventuali strumenti particolari o altre dipendenze. Informazioni dettagliate su Azure Cloud Shell sono reperibile in bit.ly/2CsFtQB.

Al momento della stesura di questo articolo, questa funzionalità è disponibile in anteprima, anche se molto probabilmente verrà rilasciato prima o poco dopo aver pubblicato l'articolo. Mentre è in anteprima, è possibile installare l'estensione di griglia di eventi per usarla nell'interfaccia della riga di comando (CLI):

az extension add -–name eventgrid

Con cui la legenda, voglio inizializzare alcune variabili locali che verranno utilizzate più volte in tutto l'esercizio:

rgname=msdndemo
topicname=<your-unique-grid-topic-name>
storagename=<your-unique-storage-account-name>
containername=deadletterevents

Voglio creare un gruppo di risorse, account di archiviazione e un contenitore che verrà usato per ricevere gli eventi di lettera non consegnata, come illustrato nella figura 3.

Figura 3 Creazione di un gruppo di risorse, un Account di archiviazione e un contenitore

# create resource group
az group create --name $rgname -l westus2
# create storage account
az storage account create \
  -–name $storagename \
  --location westus2 \
  --resource-group $rgname \
  --sku Standard_LRS \
  --kind StorageV2 \
  --access-tier Hot
# create storage container
export AZURE_STORAGE_ACCOUNT=$storagename
export AZURE_STORAGE_ACCESS_KEY=”$(az storage account keys list -–account-name $storagename
  --resource-group $rgname –-query “[0].value” –-output tsv)”
az storage container create –-name $containername

Successivamente, devo ID della risorsa. dell'account di archiviazione Questo sarà essere usato con il nome del contenitore, per definire l'endpoint di lettera non consegnata:

# storage ID
storageid=$(az storage account show –-name $storagename
  –-resource-group $rgname –-query id --output tsv)  
# container ID for dead letter channel
containerid="$storageid/blobservices/default/containers/$containername"

I verranno inviati gli eventi a un argomento di griglia di eventi personalizzato. È possibile creare l'argomento e salvare la chiave di accesso e l'indirizzo endpoint. Questi valori verranno utilizzati in un secondo momento quando si pubblicano eventi:

# create custom topic
az eventgrid topic create -g $rgname –-name $topicname -l westus2
# save topic endpoint
topicendpoint=$(az eventgrid topic show –-name $topicname -g $rgname
  –-query “endpoint” –-output tsv) 
# save topic key
topickey=$(az eventgrid topic key list --name $topicname -g $rgname
  --query "key1" --output tsv)

Gestore di eventi di funzioni di Azure

In questo scenario, sarà fingendo che gli utenti inviano le richieste di brano per una stazione radio fittizi che specializza la musica Blues. Arriva, essi è inserire in una playlist per la stazione. Tuttavia, se il genere del brano non corrisponde la musica di destinazione per la stazione radio, verrà rifiutato e posizionato sul canale di lettera non consegnata.

Il gestore eventi è una funzione di Azure basato sulla versione 2 del runtime. Verrà esaminare il campo oggetto dell'evento e approvare o rifiutare la richiesta di brano di conseguenza. Il codice per la funzione di Azure è illustrato nella figura 4.

Figura 4 il gestore di eventi di funzioni di Azure

using System.IO;
using System.Linq;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.AspNetCore.Http;
using Microsoft.Azure.EventGrid.Models;
using Microsoft.Azure.WebJobs.Host;
using Newtonsoft.Json;
using Microsoft.Extensions.Logging; 

namespace WeWantTheFunc
{
  public static class SongRequestHandler
  {
    [FunctionName("SongRequestHandler")]
    public static IActionResult Run(
      [HttpTrigger(AuthorizationLevel.Function, "post", Route = null)]
      HttpRequest req, ILogger log)
    {
      // Get the body of the request
      var requestBody = new StreamReader(req.Body).ReadToEnd();
      // Check the header for the event type           
      if (!req.Headers.TryGetValue("Aeg-Event-Type", out var headerValues))
        return new BadRequestObjectResult("Not a valid request");
      var eventTypeHeaderValue = headerValues.FirstOrDefault();
      if (eventTypeHeaderValue == "SubscriptionValidation")
      {
        // Validate the subscription
        var events = JsonConvert.DeserializeObject<EventGridEvent[]>(requestBody);
        dynamic data = events[0].Data;
        var validationCode = data["validationCode"];
        return new JsonResult(new
        {
          validationResponse = validationCode
        });
      }
      else if (eventTypeHeaderValue == "Notification")
      {
        // Handle the song request
        log.LogInformation(requestBody);
        var events = JsonConvert.DeserializeObject<EventGridEvent[]>(requestBody);
        // Reject the request if it does not
        // match the genre for the station.
        if (events[0].Subject != "genre/blues")
          return new BadRequestObjectResult("Sorry, this is a Blues station");
        return new OkObjectResult("");
      }
      return new BadRequestObjectResult("Not a valid request");
    }
  }
}

Questa funzione è costituito da due parti. Il primo controlla se l'evento in arrivo destinato per la convalida dell'endpoint. Se è una richiesta di convalida, la funzione restituisce il codice di convalida per dimostrare la proprietà e l'accettazione dei messaggi in arrivo.

La seconda parte della funzione è per le notifiche degli eventi da griglia di eventi. Restituendo una risposta richiesta non valida (401), viene eseguita un'istruzione esplicita per non inviare più l'evento al gestore. Ciò riconduce alla parte più importante del processo, ovvero la creazione di una sottoscrizione di eventi.

Sottoscrizione di eventi

Con tutte le parti del posto, è infine possibile per creare una sottoscrizione di eventi che illustra i criteri di ripetizione dei tentativi sia il mancato recapito dei messaggi di funzionalità. Un presupposto è che la funzione di Azure in figura 4 è stato distribuito ed è attualmente in esecuzione in Azure. Il comando per creare la sottoscrizione è come segue:

az eventgrid event-subscription create \
  --endpoint <your-azure-function-url> \
  --topic-name $topicname \
  -g $rgname \
  --name song-request-sub \
  --deadletter-endpoint $containerid \
  --max-delivery-attempts 2
  --event-ttl 1

Si noti che i tentativi di recapito massima sia evento-ttl sono incluse le impostazioni. Non è un requisito per includere entrambe le impostazioni, ma possono essere usati insieme per configurare i criteri di ripetizione dei tentativi. Il numero massimo di tentativi di recapito imposto a due e la durata (TTL) su un minuto. Un altro argomento nuova denominato endpoint di messaggi non recapitabili viene inizializzato al contenitore di account di archiviazione usando la variabile che è stata creata in precedenza. È possibile inviare alcuni eventi e vedere questo lavoro end-to-end.

L'invio di eventi

Della riga di comando, è possibile copiare un corpo di esempio che contiene una richiesta di brano. Questa richiesta effettivamente conterrà un genere musica non valido (Rock) che verrà rifiutato dal gestore dell'evento.

# copy the request body
body=$(eval echo "'$(curl https://raw.githubusercontent.com/dbarkol/azure-event-grid-patterns/master/badsongrequest.json)'")
# post the request to the custom topic endpoint
curl -X POST -H "aeg-sas-key: $topickey" -d "$body" $topicendpoint

L'aspettativa è che alcuni minuti dopo il messaggio viene inviato, finirà nel contenitore di account di archiviazione che è stata configurata come canale di lettera non consegnata. È possibile usare uno strumento come Azure Storage Explorer per visualizzare il nuovo blob creato per ogni messaggio come non recapitabili. Tuttavia, che non è molto appassionante. In alternativa, si desidera ricevere una notifica quando viene aggiunto un nuovo messaggio nel canale di lettera non consegnata.

Esaminare eventi lettera non consegnata

Poiché l'evento di lettera non consegnata è semplicemente un nuovo blob creato in un contenitore, griglia di eventi è utilizzabile per avviare un altro flusso di lavoro che viene attivato quando viene creato il file. Figura 5 illustra il flusso di lavoro per come un evento può provenire da un account di archiviazione e infine essere ricevuto da un'App per la logica e invia un messaggio di posta elettronica.

Figura 5 Blob eventi gestiti da App per la logica

L'unica cosa che sarà necessario inserire il codice seguente tra loro è un'App per la logica che inizia con un trigger di griglia di eventi. I primi tre passaggi nell'applicazione includono trigger e le azioni seguenti:

Trigger griglia di eventi è configurato per l'account di archiviazione. Usa due filtri, ovvero uno per il tipo di evento (Microsoft.Storage.BlobCreated) e la seconda per il contenitore usando l'opzione di filtro prefisso. Entrambi questi filtri assicurarsi che l'app viene richiamato solo quando viene creato un nuovo file all'interno del contenitore di lettera non consegnata dedicato.

Inizializza variabile è l'azione successiva che recupera l'URL dal corpo del messaggio di griglia di eventi. Il valore è l'espressione seguente:

triggerBody()?['data']['url']

Ottenere i blob contenuti tramite il percorso è l'azione che verrà letto il contenuto del blob. Formattare il valore del percorso del blob utilizzando la seguente espressione di manipolazione di stringa per rimuovere la parte che non è necessario:

replace(variables('DeadLetterUrl'),
  'https://<storage-account-name>.blob.core.windows.net', '')

Questi passaggi iniziali vengono visualizzati nella figura 6.

Figura 6, un'App per la logica attivata dalla griglia di eventi

Ecco le azioni finali dell'App per la logica:

Parse JSON esaminerà il contenuto del blob e fornire un set di variabili che è possibile far riferimento in un secondo momento. L'espressione per la proprietà di contenuto è:

json(body('Get_blob_content_using_path'))

Anche necessario fornire un payload di esempio che è simile a:

[{
  "id":"100",
  "eventTime":"2017-08-21T06:42:20.0000000+00:00",
  "eventType":"type",
  "dataVersion":"",
  "metadataVersion":"1",
  "topic":"enpoint",
  "subject":"testsubject",
  "deadLetterReason":"reason",
  "deliveryAttempts":1,
  "lastDeliveryOutcome":"BadRequest",
  "lastHttpStatusCode":400,
  "data":{"something":"data"}
}]

Inviare che un messaggio di posta elettronica è l'ultima azione, che formatta il corpo e l'oggetto del messaggio di posta elettronica con gli elementi degli eventi (motivo di lettera non consegnata e oggetto). Perché il payload contiene effettivamente una matrice, App per la logica che riconosce ed esegue il wrapping l'azione in una per ogni azione.

Come nota a margine, ogni passaggio all'interno di una per ogni ciclo viene eseguito in parallelo anziché in sequenza in App per la logica. si tratta del comportamento predefinito che può essere modificato per l'esecuzione in sequenza, se lo si desidera. Il risultato finale è visualizzato nella figura 7.

Figura 7 l'analisi JSON e l'invio di notifiche

Test di questo end-to-end verrà generato un messaggio di posta elettronica inviato per ogni evento di lettera non consegnata.

Conclusioni

Con la progettazione originale e l'integrazione completa con un numero crescente di servizi di Azure, solo inizio rivelare modi innovativi per creare soluzioni basate su eventi della griglia di eventi. In questo articolo è stato illustrato come sfruttare i nuovi criteri di ripetizione dei tentativi e funzionalità in griglia di eventi di Azure di mancato recapito dei messaggi. Questi molto attesi funzionalità sono opzioni avanzate per effettuare le soluzioni basate su griglia di eventi più resilienti e scalabili. Il codice in questo articolo è reperibile in bit.ly/2LGKjhN.

David Barkolè uno specialista di Azure presso Microsoft nel Team di Black Belt globale. È possibile contattarlo su Twitter: @dbarkol o tramite posta elettronica all'indirizzo dabarkol@microsoft.com. Possiede un blog regolarmente su griglia di eventi in madeofstrings.com.

Grazie al seguente esperto tecnico Microsoft per la revisione dell'articolo: Bahram Banisadr

Bahram Banisadr è PM responsabile della griglia di eventi di Azure per compilare il tessuto connessi per servizi di Azure.

Discutere di questo articolo nel forum di MSDN Magazine