Gridwich-cloudmediasysteem

De Gridwich-pijplijnen nemen mediaassets op, verwerken, opslaan en leveren met behulp van twee nieuwe methoden, de Azure Event Grid Sandwich en de Terraform Sandwich.

Architectuur

De Gridwich-architectuur bevat twee sandwiches die voldoen aan de vereisten van asynchrone gebeurtenisverwerking en infrastructuur als code:

• De Event Grid-sandwich abstraheert externe en langlopende processen zoals mediacodering van het externe saga-werkstroomsysteem door ze tussen twee Event Grid-handlers te sandwicheren. Met deze sandwich kan het externe systeem een aanvraag-gebeurtenis verzenden, geplande gebeurtenissen bewaken en wachten op een uiteindelijke geslaagde of mislukte reactie die mogelijk minuten of uren later aankomt.

  

  Een Visio-bestand van deze architectuur downloaden.

• De Terraform Sandwich is een Terraform-patroon met meerdere fasen dat is bijgewerkt om infrastructuur als code te ondersteunen. Het scheiden van infrastructuur- en softwarereleases betekent dat de Azure Functions-app moet worden vrijgegeven en uitgevoerd voordat Terraform het Event Grid-abonnement kan implementeren. Er zijn twee Terraform-taken in de CI/CD-pijplijn om aan deze vereiste te voldoen:

  

  • Terraform 1 maakt alle resources, met uitzondering van de Azure Event Grid-abonnementen.
  • Terraform 2 maakt de Event Grid-abonnementen nadat de software actief is.

  Op deze manier kan Terraform de oplossingsinfrastructuur volledig beheren en implementeren, zelfs wanneer niet alle Azure-resources kunnen worden gemaakt voordat de softwareartefacten worden geïmplementeerd.

Werkstroom

Het gridwich-aanvraag- en antwoordproces behandelt de volgende aanvragen:

• Maken
• Transport
• Receptie
• Verzenden naar Gridwich-onderdelen
• Bevestiging en acties
• Antwoorden

In de volgende stappen wordt het aanvraag- en antwoordproces tussen een extern systeem en Gridwich beschreven. In Gridwich is het externe systeem een MAM- en saga-werkstroomindelingssysteem. Zie Gridwich-berichtindelingen voor de exacte indelingen van gridwich-bewerkingen.

1. Het externe systeem maakt een aanvraag en verzendt deze naar de aanvraagbroker.

2. De aanvraagbroker is verantwoordelijk voor het verzenden van aanvragen naar gridwich-aanvraaglisteners in een traditioneel publicatieabonnementsmodel. In deze oplossing is de aanvraagbroker Azure Event Grid. Alle aanvragen worden ingekapseld met behulp van het Event Grid-gebeurtenisschema.

3. De Azure Functions-app Grid gebruikt gebeurtenissen van Event Grid. Voor een betere doorvoer definieert Gridwich een HTTP-eindpunt als een pushmodel dat Event Grid initieert, in plaats van het Event Grid-binding pollingmodel dat Azure Functions biedt.

4. De Azure Functions-app leest de gebeurtenis-eigenschappen en verzendt gebeurtenissen naar onderdelen van de Gridwich-code die dat gebeurtenistype en die versie verwerken.

5. Elke handler die met de huidige aanvraag werkt, maakt gebruik van de algemene EventGridHandlerBase-klasse om onmiddellijk een bevestigingsbericht te verzenden wanneer deze de aanvraag ontvangt. De handler verzendt het werk vervolgens naar de afgeleide klasse.

   Gridwich-aanvraagwerkstromen kunnen synchroon of asynchroon zijn. Voor aanvragen die gemakkelijk kunnen worden uitgevoerd en snel te voltooien, voert een synchrone handler het werk uit en retourneert de gebeurtenis Geslaagd of Mislukt bijna onmiddellijk nadat de bevestiging is verzonden.

   Voor aanvragen die langlopend zijn, evalueert een asynchrone handler de aanvraag, valideert argumenten en start de langdurige bewerking. De handler retourneert vervolgens een gepland antwoord om te bevestigen dat de werkactiviteit is aangevraagd. Bij het voltooien van de werkactiviteit is de aanvraaghandler verantwoordelijk voor het leveren van een voltooide of mislukte gebeurtenis voor het werk.

   De gebeurtenispublicatieservice communiceert de berichten Bevestiging, Fout, Gepland of Geslaagd naar de Event Grid-aanvraagbroker.

6. De gebeurtenisuitgever in de Azure-functie verzendt de reactie-gebeurtenis naar een Event Grid-onderwerp, dat fungeert als een betrouwbare berichtenbroker. Het externe systeem abonneert zich op het onderwerp en verbruikt de berichten. Het Event Grid-platform biedt de normale logica voor opnieuw proberen voor publicatie naar het externe systeem.

Berichtvolgorde

Hoewel een bevestiging voorafgaat aan zowel de geslaagde als de geplande antwoorden, garandeert Gridwich niet dat een gepland antwoord altijd voorafgaat aan het bijbehorende geslaagde antwoord. Een geldige reactievolgorde kan een bevestigd > gepland > succes of een bevestigd > succes >gepland zijn.

Mislukte aanvragen

Aanvraagfouten kunnen worden veroorzaakt door ongeldige aanvragen, ontbrekende voorwaarden, verwerkingsfouten, beveiligingsuitzonderingen of niet-verwerkte uitzonderingen. Bijna alle fouten hebben hetzelfde berichtformulier en bevatten de oorspronkelijke waarde van de bewerkingscontext . De algemene EventGridHandlerBase-klasse verzendt doorgaans foutreacties naar Event Grid via de interface van de azure-functiegebeurtenisuitgever. Application Insights registreert ook fouten via gestructureerde logboekregistratie.

Bewerkingscontext

Het externe systeem kan duizenden aanvragen per dag, per uur of per seconde genereren. Elke aanvraag gebeurtenis naar Gridwich moet een JSON-objecteigenschap met de naam operationContextbevatten.

Als een aanvraag een bewerkingscontext bevat, zoals {"id"="Op1001"}elk Gridwich-antwoordmoet een bijbehorende ondoorzichtige bewerkingscontext bevatten, of de aanvraag kortlopend of langlopend is. Deze bewerkingscontext blijft behouden gedurende de levensduur van zelfs zeer langlopende aanvragen.

De antwoordvereiste is voor een 'corresponderend' in plaats van het 'hetzelfde' JSON-object. Gridwich-functies zoals contextdemping profiteren van het feit dat het externe systeem het geretourneerde JSON-object op een top-down manier verwerkt.

Het externe systeem heeft met name:

• Geen afhankelijkheid van het ordenen van eigenschappen, zodat Gridwich een object met dezelfde eigenschappen kan terugsturen, mogelijk in een andere volgorde. Bijvoorbeeld, {"a":1,"b":2} vs. {"b":2,"a":1}.

• Er is geen probleem met extra eigenschappen die aanwezig zijn, zodat Gridwich, die is ontvangen {"b":2,"a":1}, geldig kan retourneren {"a":1,"b":2,"~somethingExtra":"yes"}. Om de kans op botsingen te minimaliseren, voegt Gridwich bijvoorbeeld de namen van toegevoegde eigenschappen toe met een tilde (~).~muted

• Geen JSON-opmaakafhankelijkheden. Er zijn bijvoorbeeld geen veronderstellingen over waar witruimteopvulling kan vallen binnen de tekenreeksweergave van de JSON. Gridwich hoofdlettert op dit gebrek aan opmaakafhankelijkheid door overbodige witruimte te comprimeren in tekenreeksweergaven van de JSON-objecten. Zie JSONHelpers.SerializeOperationContext.

Saga-deelnemers en bewerkingscontext

In het Gridwich saga orchestration systeem draagt elke saga deelnemer een of meer werkactiviteiten bij aan het systeem. Elke saga deelnemer werkt onafhankelijk van de andere deelnemers, en meer dan één saga deelnemer kan handelen op één aanvraag.

Elk van de saga-deelnemers moet de context van de bewerking behouden, maar kan het anders implementeren. Voorbeeld:

• Kortlopende synchrone bewerkingen behouden de bewerkingscontext.
• Azure Storage biedt een ondoorzichtige tekenreekseigenschap die wordt aangeroepen ClientRequestId voor de meeste bewerkingen.
• Sommige services hebben een Job.CorrelationData accommodatie.
• Andere cloud-API's bieden vergelijkbare concepten als een ondoorzichtige bewerkingscontext die ze kunnen retourneren bij het signaleren van de voortgang, voltooiing of fout.

Zie Saga orchestration voor meer informatie over saga's en saga-deelnemers.

Synchrone en asynchrone handlers

Elke gebeurtenis-handler in het systeem maakt gebruik van een algemene EventGridHandlerBase-klasse om algemene services te bieden, zoals aanvraagbevestiging, foutafhandeling en publicatie van antwoordgebeurtenissen. De gebeurtenispublicatieservice communiceert de berichten Bevestiging, Fout, Gepland of Geslaagd naar de Event Grid-aanvraagbroker.

Elke handler die van plan is om met de huidige aanvraag te werken, moet een bevestiging geven wanneer deze de aanvraag ontvangt. De basisklasse verzendt onmiddellijk een bevestigingsbericht en verzendt vervolgens het werk naar de afgeleide klasse.

Synchrone gebeurtenisverwerking

Voor aanvragen die gemakkelijk kunnen worden uitgevoerd en snel te voltooien, werkt de handler synchroon en retourneert de gebeurtenis Geslaagd, met de bewerkingscontext, bijna onmiddellijk nadat de bevestiging is verzonden.

.

De ChangeBlobTierHandler is bijvoorbeeld een eenvoudige synchrone stroom. De handler krijgt een DTO (Request Data Transfer Object), roept aan en wacht op één service om het werk uit te voeren en retourneert een reactie op geslaagde of mislukte pogingen.

Asynchrone gebeurtenisverwerking

Sommige aanvragen worden lang uitgevoerd. Het coderen van mediabestanden kan bijvoorbeeld uren duren. In deze gevallen evalueert een asynchrone aanvraaghandler de aanvraag, valideert argumenten en initieert de langdurige bewerking. De handler retourneert vervolgens een gepland antwoord om te bevestigen dat de werkactiviteit is aangevraagd.

Bij het voltooien van de werkactiviteit is de aanvraaghandler verantwoordelijk voor het leveren van een voltooide of mislukte gebeurtenis voor het werk. Terwijl de statusloos blijft, moet de handler de oorspronkelijke bewerkingscontext ophalen en deze in de nettolading voltooid gebeurtenisbericht plaatsen.

De BlobCopyHandler toont bijvoorbeeld een eenvoudige asynchrone stroom. De handler ontvangt een aanvraag-DTO, roept aan en wacht op één service om het werk te initiëren en publiceert een reactie op gepland of mislukt.

Om de langlopende aanvraagstroom te voltooien, verbruikt de BlobCreatedHandler de platformgebeurtenis Microsoft.Storage.BlobCreated, extraheert de oorspronkelijke bewerkingscontext en publiceert een reactie op geslaagde of mislukte voltooiing.

Langlopende functies

Wanneer Gridwich een nieuwe Functions-app implementeert, kan deze de huidige langlopende processen verwijderen. Als deze processen plotseling eindigen, is er geen status en geen rapport terug naar de beller. Gridwich moet nieuwe Functions-apps implementeren terwijl de overgang correct wordt verwerkt voor langlopende functies en geen berichten ontbreken.

De oplossing moet:

• Behoud niet de status van actieve exemplaren van de Gridwich-app.
• Dood processen niet alleen omdat er iets nieuws wordt geïmplementeerd of een nieuw bericht dezelfde activiteit aanvraagt.
• Roep geen extra Azure-workloads aan, zoals Durable Functions, Functions Apps, Logic Apps of Azure Container Instances.

Gridwich maakt gebruik van azure Functions-site-implementatie en annuleringstokens om te voldoen aan deze vereisten voor betrouwbare, langlopende functies.

In het volgende diagram ziet u hoe de meeste Gridwich-taken werken. Het groene vak vertegenwoordigt een taak die Gridwich doorgeeft aan een externe service. Gridwich reageert vervolgens op een gebeurtenisgestuurde manier op de status. Het rode vak toont een functie die lang wordt uitgevoerd op Gridwich zelf.

De Functions-runtime voegt het annuleringstoken toe wanneer de toepassing wordt afgesloten. Gridwich detecteert het token en retourneert foutcodes voor alle aanvragen en actieve processen.

Site-implementatie implementeert nieuwe softwareversies. De productiesite heeft de actieve toepassing en de staging-site heeft de nieuwe versie. Azure voert een reeks implementatiestappen uit en wisselt vervolgens de site-exemplaren. Het oude exemplaar wordt opnieuw opgestart als de laatste stap van het proces.

Gridwich wacht 30 seconden nadat de hostnamen opnieuw zijn toegewezen, dus voor door HTTP geactiveerde functies garandeert Gridwich ten minste 30 seconden voordat de oude productiesite opnieuw wordt opgestart. Andere triggers kunnen worden beheerd door app-instellingen die geen mechanisme hebben om te wachten op updates van app-instellingen. Deze functies lopen een onderbreking als de uitvoering direct voordat de oude productiesite opnieuw wordt gestart.

Zie Wat er gebeurt tijdens een wisseling van sites voor Azure Functions en Azure Functions-implementatiesites voor meer informatie.

Onderdelen

De mediaverwerkingsoplossing Gridwich maakt gebruik van Azure Event Grid, Azure Functions, Azure Blob Storage, Azure Logic Apps en Azure Key Vault. De CI/CD- en saga-indelingsprocessen maken gebruik van Azure Repos, Azure Pipelines en Terraform.

• Azure Event Grid beheert de routering van Gridwich-gebeurtenissen, met twee ingeklemde Event Grid-taken waarmee asynchrone mediagebeurtenissen kunnen worden verwerkt. Event Grid is een uiterst betrouwbaar leveringseindpunt voor aanvragen. Het Azure-platform biedt de benodigde uptime en stabiliteit van het leveringseindpunt voor aanvragen.

  Gridwich bevat gebeurtenissen in het event grid-eigenschapsobjectEvent.Data , dat ondoorzichtig is voor de Event Grid-broker en -transportlaag. Gridwich gebruikt ook de eventType velden en dataVersion objectvelden om gebeurtenissen te routeren. Zodat de Event Grid-aanvraagbroker kan worden vervangen door andere gebeurtenisbrokers voor publicatieabonnementen, hangt Gridwich af van de minste gebeurtenisvelden die mogelijk zijn en gebruikt de topic of subject velden niet.

• Met Azure Functions kunt u door gebeurtenissen geactiveerde code uitvoeren zonder dat u expliciet infrastructuur hoeft in te richten of te beheren. Gridwich is een Azure Functions-app die als host fungeert voor de uitvoering van verschillende functies.

• Azure Blob Storage biedt schaalbare, kostenefficiënte cloudopslag en toegang voor ongestructureerde gegevens, zoals mediaassets. Gridwich maakt gebruik van zowel Azure Storage-blok-blobs als containers.

• Azure Key Vault beschermt cryptografische sleutels, wachtwoorden en andere geheimen die door Azure en apps en services van derden worden gebruikt.

• Azure DevOps is een set services voor ontwikkelaars en bewerkingen, waaronder op Git gebaseerde codeopslagplaatsen en geautomatiseerde build- en release-pijplijnen, die kunnen worden geïntegreerd met Azure. Gridwich gebruikt Azure-opslagplaatsen om de codeprojecten op te slaan en bij te werken, en Azure Pipelines voor CI/CD en andere werkstromen.

• Terraform is een opensource-hulpprogramma dat infrastructuur als code gebruikt voor het inrichten en beheren van infrastructuren en services.

Alternatieven

• Durable Functions, die een ingebouwd statusarchief hebben voor langdurige bewerkingen, kan ook een ondoorzichtige bewerkingscontext bieden. Durable Functions kan een reeks taken binnen een bewerking maken en de bewerkingscontext opslaan als invoer of uitvoer voor de bewerking. Gridwich kan Durable Functions zelfs gebruiken voor alle werkactiviteiten, maar deze benadering zou de complexiteit van code verhogen.

• U kunt beter loskoppelen van de Event Grid-infrastructuur door de EventGridHandlerBase te herstructureren in een RequestHandlerBase, en eventuele koppelingen naar Event Grid-objecten of -typen te verwijderen. Deze geherstructureerde klasse zou alleen betrekking hebben op basis-DTU's en niet in transportspecifieke objecttypen. Op dezelfde manier kan de IEventGridDispatcher een IResponseDispatcher met een specifieke EventGridDispatcher implementatie worden.

• De bibliotheek Gridwich.SagaParticipants.Storage.AzureStorage bevat ook opslagservices die andere saga-deelnemers gebruiken. Als u de interfaces in een kernproject hebt, voorkomt u problemen met Inversion of Control (IoC), maar u kunt de interfaces extraheren in een afzonderlijke gatewaybibliotheek voor de kernopslaginfrastructuur.

• De Gridwich Functions-app maakt gebruik van afhankelijkheidsinjectie om een of meer aanvraaghandlers te registreren voor specifieke gebeurtenistypen en gegevensversies. De app injecteert de EventGridDispatcher met de verzameling Event Grid-gebeurtenis-handlers en de dispatcher vraagt de handlers om te bepalen welke de gebeurtenis verwerken.

  U kunt ook het gebeurtenisabonnement en het filtermechanisme gebruiken dat het Event Grid-platform biedt. Dit mechanisme legt een implementatiemodel van 1:1 op, waarbij één Azure-functie slechts één gebeurtenis-handler host. Hoewel Gridwich een 1:veel-model gebruikt, betekent de schone architectuur dat het herstructureren van de oplossing voor 1:1 niet moeilijk zou zijn.

• Zie Microservices-alternatief voor een alternatieve microservice in plaats van monolithische Gridwich-architectuur.

Scenariodetails

Een bekend massamedia- en entertainmentconglomeraat vervangt hun on-premises videostreamingservice door een cloudoplossing voor het opnemen, verwerken en publiceren van videoassets. De belangrijkste doelstellingen van het bedrijf waren om te profiteren van Azure-cloudcapaciteit, -kosten en -flexibiliteit om:

• Opname van onbewerkte videobestanden, verwerken en publiceren en voldoen aan mediaaanvragen.
• Verbeter zowel de codering als de nieuwe mogelijkheden voor opname en distributie op schaal en met een overzichtelijke benadering.
• Implementeer continue integratie en levering (CI/CD) voor de MAM-pijplijn (Media Asset Management).

Om aan deze doelstellingen te voldoen, heeft het technische team van Microsoft Gridwich ontwikkeld, een staatloos gebeurtenisverwerkingsframework dat wordt gedreven door een extern saga-werkstroomindelingssysteem.

Potentiële gebruikscases

Het technische team heeft Gridwich ontwikkeld om te voldoen aan principes en industriestandaarden voor:

• Schone monolithische architectuur
• Projectstructuur en naamgeving
• CI/CD
• Azure Storage-gebruik en -schaalaanpassing
• Logboekregistratie

Het Gridwich-systeem belichaamt best practices voor het verwerken en leveren van mediaassets in Azure. Hoewel het Gridwich-systeem mediaspecifiek is, kan het framework voor berichtverwerking en eventing van toepassing zijn op elke werkstroom voor stateless gebeurtenisverwerking.

Dit scenario implementeren

• Ga naar de Gridwich-opslagplaats op GitHub.
• Volg alle procedures, te beginnen met het instellen van Azure DevOps.

Verwante resources

• Terraform-startersproject voor Azure Pipelines
• Azure Function met Event Grid en Terraform Sandwich-voorbeeld. Abonneer een Azure-functie op Event Grid-gebeurtenissen via Terraform met behulp van een Terraform Sandwich.
• MediaInfoLib met Azure Storage. Voorbeelden van Azure Functions en consoles die gebruikmaken van platformoverschrijdende .NET Core om een rapport op te halen over een mediabestand dat is opgeslagen in Azure Storage.
• Event Grid Viewer Blazor. Een Event Grid Viewer-toepassing, met behulp van Blazor en SignalR, met ondersteuning voor Microsoft Entra-autorisatie.
• Azure Function met Managed Service Identity voor Azure Storage. Gebruik Managed Service Identity tussen Azure Functions en Azure Storage.