Redigera

Dela via

Gridwich molnmediesystem

Azure Blob Storage
Azure Event Grid
Azure Functions
Azure Logic Apps

Gridwich-pipelines matar in, bearbetar, lagrar och levererar medietillgångar med hjälp av två nya metoder, Azure Event Grid Sandwich och Terraform Sandwich.

Arkitektur

Gridwich-arkitekturen har två smörgåsar som uppfyller kraven för asynkron händelsebearbetning och infrastruktur som kod:

  • Event Grid-smörgåsen abstraherar bort fjärranslutna och långvariga processer som mediekodning från det externa saga-arbetsflödessystemet genom att samla in dem mellan två Event Grid-hanterare. Med den här smörgåsen kan det externa systemet skicka en begärandehändelse, övervaka schemalagda händelser och vänta på ett slutligt lyckat eller misslyckat svar som kan komma några minuter eller timmar senare.

    Diagram som visar Event Grid-hanterarsmörgåsen.

    Ladda ned en Visio-fil med den här arkitekturen.

  • Terraform Sandwich är ett Terraform-mönster i flera steg som har uppdaterats för att stödja infrastruktur som kod. Att separera infrastruktur- och programvaruversioner innebär att Azure Functions-appen måste släppas och köras innan Terraform kan distribuera Event Grid-prenumerationen. För att uppfylla det här kravet finns det två Terraform-jobb i CI/CD-pipelinen:

    Diagram som visar Terraform-smörgåsjobben.

    • Terraform 1 skapar alla resurser förutom Azure Event Grid-prenumerationerna.
    • Terraform 2 skapar Event Grid-prenumerationerna när programvaran är igång.

    På så sätt kan Terraform helt hantera och distribuera lösningsinfrastrukturen, även om inte alla Azure-resurser kan skapas innan programvaruartefakterna distribueras.

Arbetsflöde

Gridwich-begärande- och svarsprocessen omfattar följande begäranden:

  • Skapa
  • Transport
  • Mottagande
  • Skicka till Gridwich-komponenter
  • Bekräftelse och åtgärder
  • Svar

Följande steg beskriver processen för begäran och svar mellan ett externt system och Gridwich. I Gridwich är det externa systemet ett MAM- och saga-arbetsflödesorkestreringssystem. De exakta formaten för Gridwich-åtgärders meddelandehändelser finns i Gridwich-meddelandeformat.

Diagram som visar gridwich-processen för begäran-svar.

  1. Det externa systemet skapar en begäran och skickar den till begärandekoordinatorn.

  2. Begärandekoordinatorn ansvarar för att skicka begäranden till Gridwich-begärandelyssnare i en traditionell publikationsprenumerationsmodell. I den här lösningen är begärandekoordinatorn Azure Event Grid. Alla begäranden kapslas in med Event Grid-händelseschemat.

  3. Gridwich Azure Functions-appen använder händelser från Event Grid. För bättre dataflöde definierar Gridwich en HTTP-slutpunkt som en push-modell som Event Grid initierar, i stället för den Event Grid-bindningsmätningsmodell som Azure Functions tillhandahåller.

  4. Azure Functions-appen läser händelseegenskaperna och skickar händelser till delar av Gridwich-koden som hanterar den händelsetypen och versionen.

  5. Alla hanterare som fungerar med den aktuella begäran använder den vanliga EventGridHandlerBase-klassen för att omedelbart skicka ett bekräftelsemeddelande när den tar emot begäran. Hanteraren skickar sedan arbetet till den härledda klassen.

    Gridwich-begärandearbetsflöden kan vara synkrona eller asynkrona. För begäranden som är enkla att utföra och snabba att slutföra utför en synkron hanterare arbetet och returnerar händelsen Lyckad eller misslyckad nästan omedelbart efter att bekräftelsen har skickats.

    För begäranden som körs länge utvärderar en asynkron hanterare begäran, validerar argument och initierar den långvariga åtgärden. Hanteraren returnerar sedan ett schemalagt svar för att bekräfta att den begärde arbetsaktiviteten. När du slutför arbetsaktiviteten ansvarar begärandehanteraren för att tillhandahålla en lyckad eller misslyckad händelse för arbetet.

    Händelsepubliceringstjänsten kommunicerar meddelandena Bekräftelse, Fel, Schemalagd eller Lyckad till Event Grid-begärandekoordinatorn.

  6. Händelseutgivaren i Azure-funktionen skickar svarshändelsen till ett Event Grid-ämne som fungerar som en tillförlitlig meddelandekö. Det externa systemet prenumererar på ämnet och använder meddelandena. Event Grid-plattformen tillhandahåller sin normala logik för återförsök för publicering till det externa systemet.

Meddelandeordning

Även om en bekräftelse föregår både lyckade och schemalagda svar, garanterar Gridwich inte att ett schemalagt svar alltid föregår motsvarande lyckade svar. En giltig svarssekvens kan vara antingen Bekräftad schemalagd > lyckad > eller Bekräftad lyckad > schemalagd>.

Misslyckade förfrågningar

Begärandefel kan orsakas av felaktiga begäranden, saknade förhandsvillkor, bearbetningsfel, säkerhetsfel eller ohanterade undantag. Nästan alla fel har samma meddelandeformulär och innehåller det ursprungliga åtgärdskontextvärdet . Den vanliga EventGridHandlerBase-klassen skickar vanligtvis felsvar till Event Grid via azure-funktionsgränssnittet för händelseutgivare. Application Insights loggar även fel via strukturerad loggning.

Åtgärdskontext

Det externa systemet kan generera tusentals begäranden per dag, per timme eller per sekund. Varje begärandehändelse till Gridwich måste innehålla en JSON-objektegenskap med namnet operationContext.

Om en begäran innehåller en åtgärdskontext, till exempel {"id"="Op1001"}, måste varje Gridwich-svar innehålla en motsvarande ogenomskinlig åtgärdskontext, oavsett om begäran är tidskrävande eller tidskrävande. Den här åtgärdskontexten bevaras under livslängden för även mycket långvariga begäranden.

Svarskravet gäller för ett "motsvarande" I stället för "samma" JSON-objekt. Gridwich-funktioner som kontextavstängning drar nytta av det faktum att det externa systemet bearbetar det returnerade JSON-objektet uppifrån och ned.

Mer specifikt har det externa systemet:

  • Inget beroende av egenskapsordning, så Gridwich kan skicka tillbaka ett objekt med samma egenskaper, eventuellt i en annan ordning. Till exempel jämfört {"a":1,"b":2} med {"b":2,"a":1}.

  • Inga problem med att extra egenskaper finns, så Gridwich, efter att ha tagit emot {"b":2,"a":1}, kan returnera {"a":1,"b":2,"~somethingExtra":"yes"}giltigt . För att minimera risken för kollisioner prefixerar Gridwich namnen på tillagda egenskaper med en tilde (~), till exempel ~muted.

  • Inga JSON-formateringsberoenden. Det finns till exempel inga antaganden om var utfyllnad av blanksteg kan falla inom strängrepresentationen av JSON. Gridwich versalerar på denna brist på formateringsberoende genom att komprimera ut onödiga blanksteg i strängrepresentationer av JSON-objekten. Se JSONHelpers.SerializeOperationContext.

Saga-deltagare och driftkontext

I Gridwichs sagaorkestreringssystem bidrar varje sagadeltagare med en eller flera arbetsaktiviteter till systemet. Varje sagadeltagare arbetar oberoende av de andra deltagarna, och mer än en sagadeltagare kan agera på en enda begäran.

Var och en av deltagarna i sagan måste behålla åtgärdskontexten, men kan implementera den på olika sätt. Till exempel:

  • Kortvariga synkrona åtgärder behåller åtgärdskontexten.
  • Azure Storage tillhandahåller en täckande strängegenskap som anropas ClientRequestId för de flesta åtgärder.
  • Vissa tjänster har en Job.CorrelationData egenskap.
  • Andra moln-API:er erbjuder liknande begrepp som en ogenomskinlig åtgärdskontext som de kan returnera när de signalerar förlopp, slutförande eller fel.

Mer information om sagor och sagadeltagare finns i Saga-orkestrering.

Synkrona och asynkrona hanterare

Varje händelsehanterare i systemet använder en vanlig EventGridHandlerBase-klass för att tillhandahålla allmänna tjänster som bekräftelse av begäran, felhantering och publicering av svarshändelser. Händelsepubliceringstjänsten kommunicerar meddelandena Bekräftelse, Fel, Schemalagd eller Lyckad till Event Grid-begärandekoordinatorn.

Alla hanterare som planerar att arbeta med den aktuella begäran måste ange en bekräftelse när den tar emot begäran. Basklassen skickar omedelbart ett bekräftelsemeddelande och skickar sedan arbetet till den härledda klassen.

Diagram som visar flödet bekräftelsemeddelande.

Synkron händelsebearbetning

För begäranden som är enkla att utföra och snabba att slutföra utför hanteraren arbetet synkront och returnerar händelsen Lyckad, med dess åtgärdskontext, nästan omedelbart efter att bekräftelsen har skickats.

Diagram som visar ett synkront meddelandeflöde för begäran och svar..

ChangeBlobTierHandler är till exempel ett enkelt synkront flöde. Hanteraren hämtar ett begärandedataöverföringsobjekt (DTO), anropar och väntar på en enda tjänst för att utföra arbetet och returnerar ett svar om lyckad eller misslyckad.

Diagram som visar det synkrona flödet ChangeBlobTierHandler.

Asynkron händelsebearbetning

Vissa begäranden är tidskrävande. Det kan till exempel ta timmar att koda mediefiler. I dessa fall utvärderar en asynkron begärandehanterare begäran, validerar argument och initierar den långvariga åtgärden. Hanteraren returnerar sedan ett schemalagt svar för att bekräfta att den begärde arbetsaktiviteten.

Diagram som visar ett asynkront meddelandeflöde för begäran och svar.

När du slutför arbetsaktiviteten ansvarar begärandehanteraren för att tillhandahålla en lyckad eller misslyckad händelse för arbetet. När hanteraren förblir tillståndslös måste den hämta den ursprungliga åtgärdskontexten och placera den i nyttolasten Slutfört händelsemeddelande.

BlobCopyHandler visar till exempel ett enkelt asynkront flöde. Hanteraren hämtar en begärande-DTO, anropar och väntar på en enda tjänst för att initiera arbetet och publicerar ett schemalagt svar eller ett felsvar.

Diagram som visar exemplet för BlobCopyHandler-asynkront flöde med schemalagd händelse.

För att slutföra det långvariga begärandeflödet använder BlobCreatedHandler plattformshändelsen Microsoft.Storage.BlobCreated, extraherar den ursprungliga åtgärdskontexten och publicerar ett svar om lyckad eller misslyckad slutförande.

Diagram som visar exemplet på ett asynkront BlobCopyHandler-flöde med en lyckad händelse.

Långvariga funktioner

När Gridwich distribuerar en ny Functions-app kan den släppa aktuella tidskrävande processer. Om dessa processer slutar plötsligt finns det ingen status och ingen rapport tillbaka till anroparen. Gridwich måste distribuera nya Functions Apps samtidigt som övergången hanteras korrekt för långvariga funktioner och inga meddelanden saknas.

Lösningen måste:

  • Behåll inte tillståndet för att köra instanser av Gridwich-appen.
  • Inte avsluta processer bara för att något nytt distribueras eller ett nytt meddelande begär samma aktivitet.
  • Anropa inte ytterligare Azure-arbetsbelastningar, till exempel Durable Functions, Functions Apps, Logic Apps eller Azure Container Instances.

Gridwich använder distributions- och annulleringstoken för Azure Functions-platser för att uppfylla dessa krav för tillförlitliga, långvariga funktioner.

Följande diagram visar hur de flesta Gridwich-jobb fungerar. Den gröna rutan representerar ett jobb som Gridwich skickar till en extern tjänst. Gridwich reagerar sedan på ett händelsedrivet sätt på statusen. Den röda rutan visar en funktion som körs länge på Gridwich själv.

Diagram som visar funktioner som körs på kort och lång sikt.

Functions-körningen lägger till annulleringstoken när programmet stängs av. Gridwich identifierar token och returnerar felkoder för alla begäranden och processer som körs.

Distribution av fack distribuerar nya programvaruversioner. Produktionsplatsen har det program som körs och mellanlagringsplatsen har den nya versionen. Azure utför en serie distributionssteg och byter sedan fackinstanserna. Den gamla instansen startas om som det sista steget i processen.

Gridwich väntar 30 sekunder efter ommappning av värdnamnen, så för HTTP-utlösta funktioner garanterar Gridwich minst 30 sekunder före omstarten för den gamla produktionsplatsen. Andra utlösare kan styras av appinställningar som inte har någon mekanism för att vänta på appinställningsuppdateringar. Dessa funktioner riskerar att avbrytas om körningen startar precis innan den gamla produktionsplatsen startas om.

Mer information finns i Vad händer under ett fackbyte för Distributionsfack för Azure Functions och Azure Functions.

Komponenter

Gridwichs lösning för mediebearbetning använder Azure Event Grid, Azure Functions, Azure Blob Storage, Azure Logic Apps och Azure Key Vault. CI/CD- och saga-orkestreringsprocesserna använder Azure Repos, Azure Pipelines och Terraform.

  • Azure Event Grid hanterar routningen av Gridwich-händelser med två inklubbade Event Grid-jobb som möjliggör asynkron mediahändelsebearbetning. Event Grid är en mycket tillförlitlig slutpunkt för leverans av begäranden. Azure-plattformen tillhandahåller nödvändig slutpunktsupptid för begärandeleverans och stabilitet.

    Gridwich kapslar in händelser i event grid-schemaegenskapsobjektetEvent.Data, som är ogenomskinlig för Event Grid-koordinatorn och transportskiktet. Gridwich använder också objektfälten eventType och dataVersion för att dirigera händelser. Så att Event Grid-begärandekoordinatorn kan ersättas med andra händelseköer för publiceringsprenumeration beror Gridwich på det minsta möjliga händelsefältet och använder inte fälten topic eller subject .

  • Med Azure Functions kan du köra händelseutlöst kod utan att uttryckligen behöva etablera eller hantera infrastruktur. Gridwich är en Azure Functions-app som är värd för körning av olika funktioner.

  • Azure Blob Storage ger skalbar, kostnadseffektiv molnlagring och åtkomst för ostrukturerade data som medietillgångar. Gridwich använder både Azure Storage-blockblobar och containrar.

  • Azure Key Vault skyddar kryptografiska nycklar, lösenord och andra hemligheter som Azure och appar och tjänster från tredje part använder.

  • Azure DevOps är en uppsättning utvecklar- och drifttjänster, inklusive Git-baserade kodlagringsplatser och automatiserade bygg- och versionspipelines som integreras med Azure. Gridwich använder Azure Repos för att lagra och uppdatera kodprojekten och Azure Pipelines för CI/CD och andra arbetsflöden.

  • Terraform är ett verktyg med öppen källkod som använder Infrastruktur som kod för att etablera och hantera infrastrukturer och tjänster.

Alternativ

  • Durable Functions, som har ett inbyggt tillståndslager för långvariga åtgärder, kan också ge en ogenomskinlig åtgärdskontext. Durable Functions kan skapa en serie aktiviteter inom en åtgärd och spara åtgärdskontexten som indata eller utdata för åtgärden. Gridwich kan faktiskt använda Durable Functions för alla arbetsaktiviteter, men den här metoden skulle öka kodkomplexiteten.

  • Du kan få bättre frikoppling från Event Grid-infrastrukturen genom att omstrukturera EventGridHandlerBase till en RequestHandlerBaseoch ta bort eventuella kopplingar till Event Grid-objekt eller -typer. Den här omstrukturerade klassen hanterar endast bas-DTU:er och inte i transportspecifika objekttyper. På samma sätt kan IEventGridDispatcher bli en IResponseDispatcher med en specifik EventGridDispatcher implementering.

  • Biblioteket Gridwich.SagaParticipants.Storage.AzureStorage innehåller även lagringstjänster som andra saga-deltagare använder. Om du har gränssnitten i ett kärnprojekt undviker du problem med inversion av kontroll (IoC), men du kan extrahera gränssnitten till ett separat gatewaybibliotek för kärninfrastruktur.

  • Gridwich Functions-appen använder beroendeinmatning för att registrera en eller flera begärandehanterare för specifika händelsetyper och dataversioner. Appen matar in EventGridDispatcher med samlingen av Event Grid-händelsehanterare, och avsändaren frågar hanterarna för att avgöra vilka som ska bearbeta händelsen.

    Du kan också använda händelseprenumerationen och filtreringsmekanismen som Event Grid-plattformen tillhandahåller. Den här mekanismen tillämpar en 1:1-distributionsmodell, där en Azure-funktion endast är värd för en händelsehanterare. Även om Gridwich använder en 1:många-modell innebär dess rena arkitektur att det inte skulle vara svårt att omstrukturera lösningen för 1:1.

  • En alternativ mikrotjänst i stället för monolitisk Gridwich-arkitektur finns i Alternativet Mikrotjänster.

Information om scenario

Ett välkänt massmedie- och underhållningskonglomerat ersatte sin lokala videoströmningstjänst med en molnbaserad lösning för inmatning, bearbetning och publicering av videotillgångar. Företagets huvudmål var att dra nytta av Azures molnkapacitet, kostnad och flexibilitet för att:

  • Mata in råa videofiler, bearbeta och publicera dem och uppfylla mediebegäranden.
  • Förbättra både kodning och nya intags- och distributionsfunktioner i stor skala och med en rent konstruerad metod.
  • Implementera kontinuerlig integrering och leverans (CI/CD) för MAM-pipelinen (Media Asset Management).

För att uppfylla dessa mål utvecklade Microsofts teknikteam Gridwich, ett tillståndslöst ramverk för händelsebearbetning som drivs av ett externt saga-arbetsflödesorkestreringssystem.

Potentiella användningsfall

Teknikteamet utvecklade Gridwich för att anpassa sig till principer och branschstandarder för:

Gridwich-systemet innehåller metodtips för bearbetning och leverans av medietillgångar i Azure. Även om Gridwich-systemet är mediespecifikt kan ramverket för meddelandebearbetning och händelsehantering gälla för alla tillståndslösa arbetsflöden för händelsebearbetning.

Distribuera det här scenariot