Sistema di supporti cloud Gridwich

Le pipeline gridwich inseriscono, elaborano, archivia e distribuiscono asset multimediali con l'aiuto di due nuovi metodi, Griglia di eventi di Azure Sandwich e Terraform Sandwich.

Architettura

L'architettura di Gridwich include due sandwich che rispondono ai requisiti dell'elaborazione asincrona degli eventi e dell'infrastruttura come codice:

• Il panino griglia di eventi astrae i processi remoti e a esecuzione prolungata, ad esempio la codifica multimediale dal sistema del flusso di lavoro saga esterno, inserendoli tra due gestori di Griglia di eventi. Questo sandwich consente al sistema esterno di inviare un evento di richiesta, monitorare gli eventi pianificati e attendere un esito positivo o negativo finale che potrebbe arrivare minuti o ore dopo.

  

  Scaricare un file di Visio di questa architettura.

• Terraform Sandwich è un modello Terraform a più fasi aggiornato per supportare l'infrastruttura come codice. La separazione delle versioni dell'infrastruttura e del software significa che l'app Funzioni di Azure deve essere rilasciata ed eseguita prima che Terraform possa distribuire la sottoscrizione di Griglia di eventi. Per soddisfare questo requisito, nella pipeline CI/CD sono presenti due processi Terraform:

  

  • Terraform 1 crea tutte le risorse ad eccezione delle sottoscrizioni Griglia di eventi di Azure.
  • Terraform 2 crea le sottoscrizioni di Griglia di eventi dopo che il software è operativo.

  In questo modo, Terraform può gestire e distribuire completamente l'infrastruttura della soluzione, anche quando non tutte le risorse di Azure possono essere create prima della distribuzione degli artefatti software.

Workflow

Il processo di richiesta e risposta di Gridwich copre le richieste seguenti:

• Creazione
• Trasporto
• Reception
• Invio ai componenti di Gridwich
• Riconoscimento e azioni
• Risposte

I passaggi seguenti descrivono il processo di richiesta e risposta tra un sistema esterno e Gridwich. In Gridwich il sistema esterno è un sistema di orchestrazione del flusso di lavoro MAM e saga. Per i formati esatti degli eventi di messaggio delle operazioni gridwich, vedere Formati dei messaggi gridwich.

1. Il sistema esterno crea una richiesta e la invia al gestore di richieste.

2. Il gestore di richieste è responsabile dell'invio di richieste ai listener di richiesta gridwich in un modello di sottoscrizione di pubblicazione tradizionale. In questa soluzione, il gestore di richieste è Griglia di eventi di Azure. Tutte le richieste vengono incapsulate usando lo schema di eventi di Griglia di eventi.

3. L'app Gridwich Funzioni di Azure utilizza eventi da Griglia di eventi. Per una migliore velocità effettiva, Gridwich definisce un endpoint HTTP come modello push avviato da Griglia di eventi, anziché il modello di polling di binding di Griglia di eventi fornito Funzioni di Azure.

4. L'app Funzioni di Azure legge le proprietà dell'evento e invia gli eventi a parti del codice Gridwich che gestiscono il tipo di evento e la versione.

5. Qualsiasi gestore che funzionerà con la richiesta corrente usa la classe EventGridHandlerBase comune per inviare immediatamente un messaggio di riconoscimento quando riceve la richiesta. Il gestore invia quindi il lavoro alla classe derivata.

   I flussi di lavoro delle richieste gridwich possono essere sincroni o asincroni. Per le richieste che sono facili da eseguire e veloci da completare, un gestore sincrono esegue il lavoro e restituisce l'evento Success o Failure quasi immediatamente dopo l'invio del riconoscimento.

   Per le richieste con esecuzione prolungata, un gestore asincrono valuta la richiesta, convalida gli argomenti e avvia l'operazione a esecuzione prolungata. Il gestore restituisce quindi una risposta pianificata per confermare che ha richiesto l'attività di lavoro. Al termine dell'attività di lavoro, il gestore della richiesta è responsabile della fornitura di un evento completato esito positivo o negativo per il lavoro.

   Il servizio di pubblicazione eventi comunica i messaggi Acknowledgement, Failure, Scheduled o Success al gestore di richieste di Griglia di eventi.

6. L'autore di eventi nella funzione di Azure invia l'evento di risposta a un argomento di Griglia di eventi, che funge da broker di messaggi affidabile. Il sistema esterno sottoscrive l'argomento e utilizza i messaggi. La piattaforma Griglia di eventi fornisce la normale logica di ripetizione dei tentativi per la pubblicazione nel sistema esterno.

Ordine dei messaggi

Mentre un riconoscimento precede sia le risposte riuscite che pianificate, Gridwich non garantisce che una risposta pianificata precetterà sempre la risposta success corrispondente. Una sequenza di risposta valida può essere riconosciuta > riuscita pianificata > o confermata > riuscita > pianificata.

Errori delle richieste

Gli errori delle richieste possono essere causati da richieste non valide, pre-condizioni mancanti, errori di elaborazione, eccezioni di sicurezza o eccezioni non gestite. Quasi tutti gli errori hanno lo stesso modulo di messaggio e includono il valore del contesto dell'operazione originale. La classe EventGridHandlerBase comune invia in genere risposte di errore a Griglia di eventi tramite l'interfaccia dell'editore di eventi di Funzioni di Azure. Application Insights registra anche gli errori tramite la registrazione strutturata.

Contesto dell'operazione

Il sistema esterno potrebbe generare migliaia di richieste al giorno, all'ora o al secondo. Ogni evento di richiesta a Gridwich deve includere una proprietà dell'oggetto JSON denominata operationContext.

Se una richiesta contiene un contesto di operazione, ad esempio {"id"="Op1001"}, ogni risposta gridwich deve includere un contesto operativo opaco corrispondente, indipendentemente dal fatto che la richiesta sia a esecuzione breve o a esecuzione prolungata. Questo contesto dell'operazione persiste per tutta la durata delle richieste anche a esecuzione prolungata.

Il requisito di risposta è per un oggetto JSON "corrispondente" anziché per lo stesso oggetto JSON. Le funzionalità di Gridwich, ad esempio la disattivazione del contesto, sfruttano il fatto che il sistema esterno elabora l'oggetto JSON restituito in modo dall'alto verso il basso.

In particolare, il sistema esterno ha:

• Nessuna dipendenza dall'ordinamento delle proprietà, quindi Gridwich può restituire un oggetto con le stesse proprietà, possibilmente in un ordine diverso. Ad esempio, {"a":1,"b":2} rispetto a {"b":2,"a":1}.

• Non è presente alcun problema con proprietà aggiuntive, quindi Gridwich, dopo aver ricevuto {"b":2,"a":1}, potrebbe restituire {"a":1,"b":2,"~somethingExtra":"yes"}validamente . Per ridurre al minimo la possibilità di collisioni, Gridwich antepone i nomi delle proprietà aggiunte con una tilde (~), ad esempio ~muted.

• Nessuna dipendenza di formattazione JSON. Ad esempio, non esistono presupposti sulla posizione in cui la spaziatura interna spazi vuoti può rientrare nella rappresentazione di stringa del codice JSON. Gridwich usa le maiuscole per questa mancanza di dipendenza di formattazione comprimendo gli spazi vuoti non necessarie nelle rappresentazioni di stringa degli oggetti JSON. Vedere JSONHelpers.SerializeOperationContext.

Partecipanti saga e contesto operativo

Nel sistema di orchestrazione della saga di Gridwich ogni partecipante della saga contribuisce a una o più attività lavorative al sistema. Ogni partecipante della saga funziona indipendentemente dagli altri partecipanti, e più di un partecipante della saga potrebbe agire su una singola richiesta.

Ognuno dei partecipanti alla saga deve mantenere il contesto dell'operazione, ma può implementarlo in modo diverso. Ad esempio:

• Le operazioni sincrone a esecuzione breve mantengono il contesto dell'operazione.
• Archiviazione di Azure fornisce una proprietà stringa opaca chiamata ClientRequestId per la maggior parte delle operazioni.
• Alcuni servizi hanno una Job.CorrelationData proprietà .
• Altre API cloud offrono concetti simili a un contesto operativo opaco che possono restituire quando segnalano lo stato di avanzamento, il completamento o l'errore.

Per altre informazioni sulle saghe e sui partecipanti alla saga, vedere Orchestrazione saga.

Gestori sincroni e asincroni

Ogni gestore eventi nel sistema usa una classe EventGridHandlerBase comune per fornire servizi generici, ad esempio riconoscimento delle richieste, gestione degli errori e pubblicazione di eventi di risposta. Il servizio di pubblicazione eventi comunica i messaggi Acknowledgement, Failure, Scheduled o Success al gestore di richieste di Griglia di eventi.

Qualsiasi gestore che prevede di lavorare con la richiesta corrente deve fornire un riconoscimento quando riceve la richiesta. La classe base invia immediatamente un messaggio di riconoscimento e quindi invia il lavoro alla classe derivata.

Elaborazione di eventi sincroni

Per le richieste che sono facili da eseguire e veloci da completare, il gestore esegue il lavoro in modo sincrono e restituisce l'evento Success, con il relativo contesto operativo, quasi immediatamente dopo l'invio del riconoscimento.

.

Ad esempio, ChangeBlobTierHandler è un semplice flusso sincrono. Il gestore ottiene un oggetto DTO (Request Data Transfer Object), chiama e attende un singolo servizio per eseguire il lavoro e restituisce una risposta Success o Failure.

Elaborazione asincrona di eventi

Alcune richieste sono a esecuzione prolungata. Ad esempio, la codifica dei file multimediali può richiedere ore. In questi casi, un gestore di richieste asincrone valuta la richiesta, convalida gli argomenti e avvia l'operazione a esecuzione prolungata. Il gestore restituisce quindi una risposta pianificata per confermare che ha richiesto l'attività di lavoro.

Al termine dell'attività di lavoro, il gestore della richiesta è responsabile della fornitura di un evento completato esito positivo o negativo per il lavoro. Mentre rimane senza stato, il gestore deve recuperare il contesto dell'operazione originale e inserirlo nel payload del messaggio di evento Completed.

Ad esempio, BlobCopyHandler mostra un flusso asincrono semplice. Il gestore ottiene un DTO di richiesta, chiama e attende un singolo servizio per avviare il lavoro e pubblica una risposta pianificata o non riuscita.

Per completare il flusso di richiesta a esecuzione prolungata, BlobCreatedHandler utilizza l'evento Microsoft.Storage.BlobCreateddella piattaforma , estrae il contesto dell'operazione originale e pubblica una risposta di completamento riuscito o negativo.

Funzioni a esecuzione prolungata

Quando Gridwich distribuisce una nuova app per le funzioni, può eliminare i processi a esecuzione prolungata correnti. Se questi processi terminano improvvisamente, non esiste alcuno stato e nessun report al chiamante. Gridwich deve distribuire nuove app per le funzioni, gestendo normalmente la transizione per le funzioni a esecuzione prolungata e senza messaggi mancanti.

La soluzione deve:

• Non mantenere lo stato delle istanze in esecuzione dell'app Gridwich.
• Non terminare i processi solo perché qualcosa di nuovo sta distribuendo o un nuovo messaggio richiede la stessa attività.
• Non richiamare altri carichi di lavoro di Azure, ad esempio Funzioni permanenti, App per le funzioni, App per la logica o Istanze di Azure Container.

Gridwich usa Funzioni di Azure token di distribuzione e annullamento degli slot per soddisfare questi requisiti per funzioni affidabili e a esecuzione prolungata.

Il diagramma seguente mostra il funzionamento della maggior parte dei processi di Gridwich. La casella verde rappresenta un processo che Gridwich passa a un servizio esterno. Gridwich reagisce quindi in modo guidato dagli eventi allo stato. La casella rossa mostra una funzione con esecuzione prolungata su Gridwich stessa.

Il runtime di Funzioni aggiunge il token di annullamento quando l'applicazione viene arrestata. Gridwich rileva il token e restituisce i codici di errore per tutte le richieste e i processi attualmente in esecuzione.

La distribuzione degli slot distribuisce nuove versioni software. Lo slot di produzione ha l'applicazione in esecuzione e lo slot di staging ha la nuova versione. Azure esegue una serie di passaggi di distribuzione e quindi scambia le istanze dello slot. L'istanza precedente viene riavviata come ultimo passaggio del processo.

Gridwich attende 30 secondi dopo il mapping dei nomi host, quindi per le funzioni attivate da HTTP, Gridwich garantisce almeno 30 secondi prima del riavvio per lo slot di produzione precedente. Altri trigger potrebbero essere controllati dalle impostazioni dell'app che non dispongono di un meccanismo per attendere gli aggiornamenti delle impostazioni dell'app. Queste funzioni rischiano l'interruzione se l'esecuzione inizia subito prima del riavvio dello slot di produzione precedente.

Per altre informazioni, vedere Cosa accade durante uno scambio di slot per Funzioni di Azure e Funzioni di Azure slot di distribuzione.

Componenti

La soluzione di elaborazione dei supporti gridwich usa Griglia di eventi di Azure, Funzioni di Azure, Archiviazione BLOB di Azure, App per la logica di Azure e Azure Key Vault. I processi di orchestrazione CI/CD e saga usano Azure Repos, Azure Pipelines e Terraform.

• Griglia di eventi di Azure gestisce il routing degli eventi gridwich, con due processi di Griglia di eventi in sandwich che consentono l'elaborazione asincrona di eventi multimediali. Griglia di eventi è un endpoint di recapito di richieste altamente affidabile. La piattaforma Azure fornisce il tempo di attività e la stabilità necessari per l'endpoint di recapito delle richieste.

  Gridwich incapsula gli eventi all'interno dell'oggetto proprietà dello schema Event.Data di Griglia di eventi, opaco per il broker di Griglia di eventi e il livello di trasporto. Gridwich usa anche i campi oggetto e dataVersion per instradare eventType gli eventi. In modo che il gestore di richieste di Griglia di eventi possa essere sostituito con altri broker di eventi di sottoscrizione di pubblicazione, Gridwich dipende dal minor numero possibile di campi eventi e non usa i topic campi o subject .

• Funzioni di Azure consente di eseguire codice attivato dall'evento senza dover effettuare in modo esplicito il provisioning o la gestione dell'infrastruttura. Gridwich è un'app Funzioni di Azure che ospita l'esecuzione di varie funzioni.

• Archiviazione BLOB di Azure offre un'archiviazione cloud scalabile e conveniente e l'accesso per dati non strutturati come gli asset multimediali. Gridwich usa sia i BLOB in blocchi che i contenitori Archiviazione di Azure.

• Azure Key Vault protegge le chiavi crittografiche, le password e altri segreti usati da Azure e da app e servizi di terze parti.

• Azure DevOps è un set di servizi per sviluppatori e operazioni, inclusi repository di codice basati su Git e pipeline di compilazione e versione automatizzate, che si integrano con Azure. Gridwich usa Azure Repos per archiviare e aggiornare i progetti di codice e Azure Pipelines per CI/CD e altri flussi di lavoro.

• Terraform è uno strumento open source che usa Infrastructure as Code per effettuare il provisioning e gestire infrastrutture e servizi.

Alternative

• Durable Functions, che dispone di un archivio stato predefinito per le operazioni a esecuzione prolungata, potrebbe anche fornire un contesto operativo opaco. Durable Functions può creare una serie di attività all'interno di un'operazione e salvare il contesto dell'operazione come input o output per l'operazione. Gridwich potrebbe infatti usare Durable Functions per tutte le attività lavorative, ma questo approccio aumenterebbe la complessità del codice.

• È possibile ottenere una migliore separazione dall'infrastruttura di Griglia di eventi effettuando il refactoring di EventGridHandlerBase in un RequestHandlerBaseoggetto e rimuovendo qualsiasi collegamento a oggetti o tipi di Griglia di eventi. Questa classe sottoposto a refactoring viene eseguita solo in DTO di base e non nei tipi di oggetto specifici del trasporto. Analogamente, IEventGridDispatcher potrebbe diventare un oggetto IResponseDispatcher con un'implementazione specificaEventGridDispatcher.

• La libreria Gridwich.SagaParticipants.Storage.AzureStorage contiene anche servizi di archiviazione usati da altri partecipanti della saga. La presenza delle interfacce in un progetto principale evita problemi di inversione del controllo (IoC), ma è possibile estrarre le interfacce in una libreria gateway dell'infrastruttura di archiviazione principale separata.

• L'app per le funzioni di Gridwich usa l'inserimento delle dipendenze per registrare uno o più gestori di richieste per tipi di eventi e versioni di dati specifici. L'app inserisce EventGridDispatcher con la raccolta di gestori eventi di Griglia di eventi e il dispatcher esegue una query sui gestori per determinare quali elaborano l'evento.

  In alternativa, è possibile usare la sottoscrizione di eventi e il meccanismo di filtro forniti dalla piattaforma Griglia di eventi. Questo meccanismo impone un modello di distribuzione 1:1, in cui una funzione di Azure ospita un solo gestore eventi. Anche se Gridwich usa un modello 1:molti, la sua architettura pulita significa che il refactoring della soluzione per 1:1 non sarebbe difficile.

• Per un microservizio alternativo anziché un'architettura monolitica di Gridwich, vedere Alternativa ai microservizi.

Dettagli dello scenario

Un noto conglomerato di media e intrattenimento ha sostituito il proprio servizio di streaming video locale con una soluzione basata sul cloud per l'inserimento, l'elaborazione e la pubblicazione di asset video. Gli obiettivi principali dell'azienda erano sfruttare la capacità, i costi e la flessibilità del cloud di Azure per:

• Inserire file video non elaborati, elaborarli e pubblicarli e soddisfare le richieste multimediali.
• Migliorare sia la codifica che le nuove funzionalità di assunzione e distribuzione su larga scala e con un approccio progettato in modo pulito.
• Implementare l'integrazione e il recapito continui (CI/CD) per la pipeline di gestione degli asset multimediali (MAM).

Per soddisfare questi obiettivi, il team di progettazione Microsoft ha sviluppato Gridwich, un framework di elaborazione degli eventi senza stato basato su un sistema di orchestrazione del flusso di lavoro saga esterno.

Potenziali casi d'uso

Il team di progettazione ha sviluppato Gridwich per allinearsi ai principi e agli standard del settore per:

• Architettura monolitica pulita
• Struttura e denominazione del progetto
• CI/CD
• Archiviazione di Azure utilizzo e scalabilità
• Registrazione

Il sistema Gridwich incorpora le procedure consigliate per l'elaborazione e la distribuzione di asset multimediali in Azure. Anche se il sistema Gridwich è specifico dei supporti, il framework di elaborazione dei messaggi e di eventi può essere applicato a qualsiasi flusso di lavoro di elaborazione di eventi senza stato.

Distribuire lo scenario

• Passare al repository Gridwich in GitHub.
• Seguire tutte le procedure, a partire dalla configurazione di Azure DevOps.

Risorse correlate

• Progetto iniziale Terraform per Azure Pipelines
• Esempio di Funzione di Azure con Griglia di eventi e Terraform Sandwich. Sottoscrivere una funzione di Azure agli eventi di Griglia di eventi tramite Terraform usando un panino Terraform.
• MediaInfoLib con Archiviazione di Azure. Funzioni di Azure e esempi di console che usano .NET Core multipiattaforma per recuperare un report in un file multimediale archiviato in Archiviazione di Azure.
• Visualizzatore Griglia di eventi Blazor. Un'applicazione Visualizzatore Griglia di eventi, che usa Blazor e SignalR, con il supporto delle autorizzazioni di Microsoft Entra.
• Funzione di Azure con identità del servizio gestita per Archiviazione di Azure. Usare l'identità del servizio gestita tra Funzioni di Azure e Archiviazione di Azure.