Sistema de mídia em nuvem Gridwich

Os pipelines de Gridwich ingerem, processam, armazenam e entregam ativos de mídia com a ajuda de dois novos métodos, o Azure Event Grid Sandwich e o Terraform Sandwich.

Arquitetura

A arquitetura Gridwich apresenta dois sanduíches que abordam os requisitos de processamento assíncrono de eventos e infraestrutura como código:

• O sanduíche de Grade de Eventos abstrai processos remotos e de longa execução, como codificação de mídia, do sistema de fluxo de trabalho de saga externo, colocando-os entre dois manipuladores de Grade de Eventos. Esse sanduíche permite que o sistema externo envie um evento de solicitação, monitore eventos agendados e aguarde uma eventual resposta de sucesso ou falha que pode chegar minutos ou horas depois.

  

  Transfira um ficheiro do Visio desta arquitetura.

• O Terraform Sandwich é um padrão Terraform de vários estágios atualizado para suportar a infraestrutura como código. Separar as versões de infraestrutura e software significa que o aplicativo Azure Functions deve ser lançado e executado antes que o Terraform possa implantar a assinatura da Grade de Eventos. Para atender a esse requisito, há dois trabalhos Terraform no pipeline de CI/CD:

  

  • O Terraform 1 cria todos os recursos, exceto as assinaturas da Grade de Eventos do Azure.
  • O Terraform 2 cria as assinaturas da Grade de Eventos depois que o software está instalado e funcionando.

  Dessa forma, o Terraform pode gerenciar e implantar totalmente a infraestrutura da solução, mesmo quando nem todos os recursos do Azure podem ser criados antes que os artefatos de software sejam implantados.

Fluxo de Trabalho

O processo de solicitação e resposta de Gridwich abrange as seguintes solicitações:

• Criação
• Transporte
• Receção
• Expedição para componentes de Gridwich
• Reconhecimento e ações
• Respostas

As etapas a seguir descrevem o processo de solicitação e resposta entre um sistema externo e Gridwich. Em Gridwich, o sistema externo é um sistema de orquestração de fluxo de trabalho MAM e saga. Para obter os formatos exatos dos eventos de mensagem das operações de Gridwich, consulte Formatos de mensagem de Gridwich.

1. O sistema externo cria uma solicitação e a envia para o agente de solicitação.

2. O corretor de solicitações é responsável por enviar solicitações para ouvintes de solicitação Gridwich em um modelo tradicional de assinatura de publicação. Nesta solução, o agente de solicitação é a Grade de Eventos do Azure. Todas as solicitações são encapsuladas usando o esquema de eventos da Grade de Eventos.

3. O aplicativo Gridwich Azure Functions consome eventos da Grade de Eventos. Para uma melhor taxa de transferência, Gridwich define um ponto de extremidade HTTP como um modelo de push que a Grade de Eventos inicia, em vez do modelo de sondagem de vinculação de Grade de Eventos que o Azure Functions fornece.

4. O Aplicativo Azure Functions lê as propriedades do evento e despacha eventos para partes do código Gridwich que manipulam esse tipo e versão de evento.

5. Qualquer manipulador que trabalhará com a solicitação atual usa a classe comum EventGridHandlerBase para enviar imediatamente uma mensagem de confirmação quando receber a solicitação. Em seguida, o manipulador despacha o trabalho para a classe derivada.

   Os fluxos de trabalho de solicitação Gridwich podem ser síncronos ou assíncronos por natureza. Para solicitações fáceis de executar e rápidas de concluir, um manipulador síncrono faz o trabalho e retorna o evento Êxito ou Falha quase imediatamente após o envio da confirmação.

   Para solicitações de longa execução, um manipulador assíncrono avalia a solicitação, valida argumentos e inicia a operação de longa execução. Em seguida, o manipulador retorna uma resposta agendada para confirmar que solicitou a atividade de trabalho. Ao concluir a atividade de trabalho, o manipulador de solicitação é responsável por fornecer um evento de Sucesso ou Falha concluído para o trabalho.

   O serviço de publicação de eventos comunica as mensagens de Confirmação, Falha, Agendado ou Êxito ao agente de solicitações da Grade de Eventos.

6. O editor de eventos na Função do Azure envia o evento de resposta para um tópico da Grade de Eventos, que atua como um agente de mensagens confiável. O sistema externo subscreve o tópico e consome as mensagens. A plataforma Event Grid fornece sua lógica normal de repetição para publicação no sistema externo.

Ordem da mensagem

Embora um Reconhecimento preceda as respostas de Sucesso e Agendado, Gridwich não garante que uma resposta Agendada sempre precederá a resposta de Sucesso correspondente. Uma sequência de resposta válida pode ser Reconhecido > Sucesso Agendado > ou Sucesso Reconhecido > > Agendado.

Falhas dos pedidos

As falhas de solicitação podem ser causadas por solicitações incorretas, pré-condições ausentes, falhas de processamento, exceções de segurança ou exceções não tratadas. Quase todas as falhas têm a mesma forma de mensagem e incluem o valor de contexto da operação original. A classe comum EventGridHandlerBase normalmente envia respostas de Falha para a Grade de Eventos por meio da interface do editor de eventos da Função do Azure. O Application Insights também registra falhas por meio de log estruturado.

Contexto da operação

O sistema externo pode gerar milhares de solicitações por dia, por hora ou por segundo. Cada evento de solicitação para Gridwich deve incluir uma propriedade de objeto JSON chamada operationContext.

Se uma solicitação contiver um contexto de operação, como {"id"="Op1001"}, cada resposta de Gridwich deve incluir um contexto de operação opaco correspondente, quer a solicitação seja de curta ou longa execução. Esse contexto de operação persiste durante o tempo de vida de solicitações até mesmo de execução muito longa.

O requisito de resposta é para um "correspondente" em vez do "mesmo" objeto JSON. Os recursos do Gridwich, como o silenciamento de contexto, aproveitam o fato de que o sistema externo processa o objeto JSON retornado de cima para baixo.

Especificamente, o sistema externo tem:

• Nenhuma dependência na ordem de propriedade, então Gridwich pode enviar de volta um objeto com as mesmas propriedades, possivelmente em uma ordem diferente. Por exemplo, {"a":1,"b":2} vs. {"b":2,"a":1}.

• Nenhum problema com propriedades extras estando presentes, então Gridwich, tendo recebido {"b":2,"a":1}, poderia retornar {"a":1,"b":2,"~somethingExtra":"yes"}validamente. Para minimizar a possibilidade de colisões, Gridwich prefixa os nomes das propriedades adicionadas com um til (~), por exemplo ~muted.

• Sem dependências de formatação JSON. Por exemplo, não há suposições sobre onde o preenchimento de espaço em branco pode cair dentro da representação de cadeia de caracteres do JSON. Gridwich aproveita essa falta de dependência de formatação compactando espaços em branco desnecessários em representações de cadeia de caracteres dos objetos JSON. Consulte JSONHelpers.SerializeOperationContext.

Participantes da saga e contexto da operação

No sistema de orquestração da saga de Gridwich, cada participante da saga contribui com uma ou mais atividades de trabalho para o sistema. Cada participante da saga trabalha independentemente dos outros participantes, e mais de um participante da saga pode agir em um único pedido.

Cada um dos participantes da saga deve manter o contexto da operação, mas pode implementá-lo de forma diferente. Por exemplo:

• As operações síncronas de curta duração mantêm o contexto da operação.
• O Armazenamento do Azure fornece uma propriedade de cadeia de caracteres opaca chamada ClientRequestId para a maioria das operações.
• Alguns serviços têm uma Job.CorrelationData propriedade.
• Outras APIs de nuvem oferecem conceitos semelhantes a um contexto de operação opaco que podem retornar ao sinalizar progresso, conclusão ou falha.

Para obter mais informações sobre sagas e participantes da saga, consulte Orquestração da saga.

Manipuladores síncronos e assíncronos

Cada manipulador de eventos no sistema usa uma classe EventGridHandlerBase comum para fornecer serviços genéricos, como confirmação de solicitação, tratamento de falhas e publicação de eventos de resposta. O serviço de publicação de eventos comunica as mensagens de Confirmação, Falha, Agendado ou Êxito ao agente de solicitações da Grade de Eventos.

Qualquer manipulador que planeja trabalhar com a solicitação atual deve fornecer uma confirmação quando receber a solicitação. A classe base envia imediatamente uma mensagem de confirmação e, em seguida, despacha o trabalho para a classe derivada.

Processamento de eventos síncrono

Para solicitações fáceis de executar e rápidas de concluir, o manipulador faz o trabalho de forma síncrona e retorna o evento Success, com seu contexto de operação, quase imediatamente após o envio da confirmação.

.

Por exemplo, o ChangeBlobTierHandler é um fluxo síncrono simples. O manipulador obtém um objeto de transferência de dados de solicitação (DTO), chama e aguarda um único serviço para fazer o trabalho e retorna uma resposta de sucesso ou falha.

Processamento assíncrono de eventos

Alguns pedidos são de longa duração. Por exemplo, a codificação de arquivos de mídia pode levar horas. Nesses casos, um manipulador de solicitação assíncrono avalia a solicitação, valida argumentos e inicia a operação de longa execução. Em seguida, o manipulador retorna uma resposta agendada para confirmar que solicitou a atividade de trabalho.

Ao concluir a atividade de trabalho, o manipulador de solicitação é responsável por fornecer um evento de Sucesso ou Falha concluído para o trabalho. Embora permaneça sem monitoração de estado, o manipulador deve recuperar o contexto da operação original e colocá-lo na carga útil da mensagem de evento Completed.

Por exemplo, o BlobCopyHandler mostra um fluxo assíncrono simples. O manipulador recebe um DTO de solicitação, chama e aguarda um único serviço para iniciar o trabalho e publica uma resposta agendada ou de falha.

Para concluir o fluxo de solicitação de longa execução, o BlobCreatedHandler consome o evento Microsoft.Storage.BlobCreatedda plataforma, extrai o contexto da operação original e publica uma resposta de conclusão de Êxito ou Falha.

Funções de execução prolongada

Quando o Gridwich implanta um novo aplicativo Functions, ele pode descartar os processos atuais de longa execução. Se esses processos terminarem abruptamente, não haverá status e nenhum relatório para o chamador. Gridwich deve implantar novos aplicativos de funções enquanto lida graciosamente com a transição para funções de longa execução e não falta nenhuma mensagem.

A solução deve:

• Não mantenha o estado de execução de instâncias do aplicativo Gridwich.
• Não matar processos apenas porque algo novo está implantando ou uma nova mensagem está solicitando a mesma atividade.
• Não invoque cargas de trabalho adicionais do Azure, como Funções Duráveis, Aplicativos do Functions, Aplicativos Lógicos ou Instâncias de Contêiner do Azure.

O Gridwich usa tokens de implantação e cancelamento de slots do Azure Functions para atender a esses requisitos para funções confiáveis e de longa execução.

O diagrama a seguir mostra como a maioria dos trabalhos de Gridwich funciona. A caixa verde representa um trabalho que Gridwich passa para um serviço externo. Gridwich então reage de forma orientada a eventos ao status. A caixa vermelha mostra uma função que é de longa duração no próprio Gridwich.

O tempo de execução do Functions adiciona o token de cancelamento quando o aplicativo é desligado. Gridwich deteta o token e retorna códigos de erro para todas as solicitações e processos em execução no momento.

A implantação de slots implanta novas versões de software. O slot de produção tem o aplicativo em execução e o slot de preparo tem a nova versão. O Azure executa uma série de etapas de implantação e, em seguida, troca as instâncias de slot. A instância antiga é reiniciada como a última etapa do processo.

O Gridwich espera 30 segundos após o remapeamento dos nomes dos hosts, portanto, para funções acionadas por HTTP, o Gridwich garante pelo menos 30 segundos antes da reinicialização para o slot de produção antigo. Outros gatilhos podem ser controlados pelas configurações do aplicativo que não têm um mecanismo para aguardar as atualizações das configurações do aplicativo. Essas funções correm o risco de serem interrompidas se a execução começar imediatamente antes do reinício do antigo slot de produção.

Para obter mais informações, consulte O que acontece durante uma troca de slot para os slots de implantação do Azure Functions e do Azure Functions.

Componentes

A solução de processamento de mídia Gridwich usa a Grade de Eventos do Azure, o Azure Functions, o Armazenamento de Blobs do Azure, os Aplicativos Lógicos do Azure e o Azure Key Vault. Os processos de orquestração CI/CD e saga usam Azure Repos, Azure Pipelines e Terraform.

• A Grade de Eventos do Azure gerencia o roteamento de eventos de Gridwich, com dois trabalhos de Grade de Eventos em sanduíche que permitem o processamento assíncrono de eventos de mídia. A Grade de Eventos é um ponto de extremidade de entrega de solicitações altamente confiável. A plataforma Azure fornece o tempo de atividade e a estabilidade necessários do ponto de extremidade de entrega de solicitações.

  Gridwich encapsula eventos dentro do objeto de propriedade do esquema Event.Data de Grade de Eventos, que é opaco para o agente de Grade de Eventos e a camada de transporte. Gridwich também usa os eventType campos e dataVersion objeto para rotear eventos. Para que o agente de solicitação de Grade de Eventos possa ser substituído por outros corretores de eventos de assinatura de publicação, o Gridwich depende do menor número possível de campos de evento e não usa os topic campos or subject .

• O Azure Functions permite executar código acionado por eventos sem precisar provisionar ou gerenciar explicitamente a infraestrutura. Gridwich é um aplicativo do Azure Functions que hospeda a execução de várias funções.

• O Armazenamento de Blobs do Azure fornece armazenamento em nuvem escalável e econômico e acesso a dados não estruturados, como ativos de mídia. O Gridwich usa blobs e contêineres de bloco do Armazenamento do Azure.

• O Azure Key Vault protege chaves criptográficas, palavras-passe e outros segredos que o Azure e aplicações e serviços de terceiros utilizam.

• O Azure DevOps é um conjunto de serviços de desenvolvedor e operações, incluindo repositórios de código baseados em Git e pipelines automatizados de compilação e lançamento, que se integram ao Azure. Gridwich usa o Azure Repos para armazenar e atualizar os projetos de código e o Azure Pipelines para CI/CD e outros fluxos de trabalho.

• Terraform é uma ferramenta de código aberto que usa infraestrutura como código para provisionar e gerenciar infraestruturas e serviços.

Alternativas

• As funções duráveis, que têm um armazenamento de estado integrado para operações de longa duração, também podem fornecer um contexto de operação opaco. Funções duráveis podem criar uma série de tarefas dentro de uma operação e salvar o contexto da operação como uma entrada ou saída para a operação. Na verdade, Gridwich poderia usar funções duráveis para todas as atividades de trabalho, mas essa abordagem aumentaria a complexidade do código.

• Você pode obter uma melhor dissociação da infraestrutura de Grade de Eventos refatoração o EventGridHandlerBase em um RequestHandlerBase, e removendo qualquer ligação a objetos ou tipos de Grade de Eventos. Essa classe refatorada lidaria apenas com DTOs de base, e não com tipos de objeto específicos de transporte. Da mesma forma, o IEventGridDispatcher pode se tornar um IResponseDispatcher com uma implementação específica EventGridDispatcher .

• A biblioteca Gridwich.SagaParticipants.Storage.AzureStorage também contém serviços de armazenamento que outros participantes da saga usam. Ter as interfaces em um projeto principal evita problemas de Inversão de Controle (IoC), mas você pode extrair as interfaces em uma biblioteca de gateway de infraestrutura de armazenamento principal separada.

• O aplicativo Gridwich Functions usa a injeção de dependência para registrar um ou mais manipuladores de solicitação para tipos de eventos e versões de dados específicos. O aplicativo injeta o EventGridDispatcher com a coleção de manipuladores de eventos da Grade de Eventos, e o dispatcher consulta os manipuladores para determinar quais processarão o evento.

  Como alternativa, você pode usar o mecanismo de assinatura e filtragem de eventos fornecido pela plataforma Grade de Eventos. Esse mecanismo impõe um modelo de implantação 1:1, onde uma Função do Azure hospeda apenas um manipulador de eventos. Embora Gridwich use um modelo 1:many, sua arquitetura limpa significa que refatoração a solução para 1:1 não seria difícil.

• Para obter um microsserviço alternativo em vez da arquitetura monolítica de Gridwich, consulte Alternativa de microsserviços.

Detalhes do cenário

Um conhecido conglomerado de mídia de massa e entretenimento substituiu seu serviço de streaming de vídeo local por uma solução baseada em nuvem para ingerir, processar e publicar ativos de vídeo. Os principais objetivos da empresa eram aproveitar a capacidade, o custo e a flexibilidade da nuvem do Azure para:

• Ingerir arquivos de vídeo brutos, processá-los e publicá-los e atender às solicitações de mídia.
• Melhore a codificação e os novos recursos de admissão e distribuição em escala e com uma abordagem arquitetada de forma limpa.
• Implemente integração e entrega contínuas (CI/CD) para o pipeline de gerenciamento de ativos de mídia (MAM).

Para atingir esses objetivos, a equipe de engenharia da Microsoft desenvolveu o Gridwich, uma estrutura de processamento de eventos sem estado impulsionada por um sistema de orquestração de fluxo de trabalho de saga externo.

Potenciais casos de utilização

A equipe de engenharia desenvolveu o Gridwich para se alinhar com os princípios e padrões da indústria para:

• Arquitetura monolítica limpa
• Estrutura e nomenclatura do projeto
• CI/CD
• Uso e dimensionamento do Armazenamento do Azure
• Registo

O sistema Gridwich incorpora as práticas recomendadas para processar e fornecer ativos de mídia no Azure. Embora o sistema Gridwich seja específico da mídia, a estrutura de processamento de mensagens e eventos pode ser aplicada a qualquer fluxo de trabalho de processamento de eventos sem monitoração de estado.

Implementar este cenário

• Vá para o repositório Gridwich no GitHub.
• Siga todos os procedimentos, começando com a configuração do Azure DevOps.

Recursos relacionados

• Projeto inicial Terraform para Azure Pipelines
• Função do Azure com amostra de Grade de Eventos e Terraform Sandwich. Inscreva uma Função do Azure em Eventos da Grade de Eventos via Terraform, usando um Terraform Sandwich.
• MediaInfoLib com Armazenamento do Azure. Azure Functions e exemplos de console que usam o .NET Core de plataforma cruzada para recuperar um relatório em um arquivo de mídia armazenado no Armazenamento do Azure.
• Visualizador de grade de eventos Blazor. Um aplicativo Event Grid Viewer, usando Blazor e SignalR, com suporte de autorização do Microsoft Entra.
• Função do Azure com Identidade de Serviço Gerenciado para Armazenamento do Azure. Use a Identidade de Serviço Gerenciado entre o Azure Functions e o Armazenamento do Azure.