Sistema de mídia de nuvem do Gridwich

Os pipelines do Gridwich ingerem, processam, armazenam e fornecem ativos de mídia com a ajuda de dois novos métodos, o sanduíche da Grade de Eventos do Azure e o Sanduíche do Terraform.

Arquitetura

A arquitetura Gridwich apresenta dois sanduíches que atendem aos requisitos de processamento de eventos assíncronos e infraestrutura como código:

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

  

  Baixe um Arquivo Visio dessa arquitetura.

• O Sanduíche do Terraform é um padrão Terraform de vários estágios atualizado para dar suporte à infraestrutura como código. Separar a infraestrutura e as versões de 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 do 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á em execução.

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

Workflow

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

• Criação
• Transporte
• Recepção
• Expedir para componentes do Gridwich
• Confirmação e ações
• Respostas

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

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

2. O agente de solicitação é responsável por enviar solicitações aos ouvintes de solicitação do Gridwich em um modelo tradicional de publicação-assinatura. 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 Azure Functions do Gridwich consome eventos da Grade de Eventos. Para obter uma melhor taxa de transferência, Gridwich define um ponto de extremidade HTTP como um modelo de push iniciado pela Grade de Eventos, em vez do modelo de sondagem de associação da Grade de Eventos que o Azure Functions fornece.

4. O aplicativo Azure Functions lê as propriedades do evento e envia eventos para partes do código do Gridwich que lidam com esse tipo de evento e versão.

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

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

   Para solicitações de execução longa, um manipulador assíncrono avalia a solicitação, valida os argumentos e inicia a operação de execução longa. 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 concluído com Sucesso ou Falha para o trabalho.

   O serviço de publicação de eventos comunica as mensagens Confirmação, Falha, Agendada ou Sucesso para o agente de solicitação da Grade de Eventos.

6. O editor de eventos no Azure Function 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 assina o tópico e consome as mensagens. A plataforma da Grade de Eventos fornece sua lógica de repetição normal para publicação no sistema externo.

Ordem da mensagem

Embora uma Confirmação preceda as respostas de Sucesso e Agendadas, o Gridwich não garante que uma resposta agendada sempre preceda a resposta de Sucesso correspondente. Uma sequência de resposta válida pode ser Confirmada > Agendada > Sucesso ou Confirmada > Sucesso > Agendada.

Falhas de solicitação

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 sem tratamento. Quase todas as falhas têm o mesmo formulário de mensagem e incluem o valor de contexto de operação original. A classe EventGridHandlerBase comum normalmente envia respostas de Falha à Grade de Eventos por meio da interface do editor de eventos do Azure Function. O Application Insights também registra em log as falhas por meio de log estruturado.

Contexto de operação

O sistema externo pode gerar milhares de solicitações por dia, por hora ou por segundo. Cada evento de solicitação para o 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 do Gridwich deverá incluir um contexto de operação opaco correspondente, seja de execução curta ou de execução longa. Esse contexto de operação persiste durante o tempo de vida de solicitações de execução muito longa.

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

Especificamente, o sistema externo tem:

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

• Não há problema com propriedades extras presentes, portanto, o Gridwich, tendo recebido {"b":2,"a":1}, poderia retornar {"a":1,"b":2,"~somethingExtra":"yes"} de forma válida. Para minimizar a possibilidade de colisões, o Gridwich prefixa os nomes das propriedades adicionadas com um bloco (~), 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 estar dentro da representação de cadeia de caracteres do JSON. O Gridwich capitaliza essa falta de dependência de formatação compactando o espaço em branco desnecessário em representações de cadeia de caracteres dos objetos JSON. Confira JSONHelpers.SerializeOperationContext.

Participantes da saga e contexto de operação

No sistema de orquestração da saga do 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 uma única solicitação.

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

• As operações síncronas de execução curta mantêm o contexto de 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, confira 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 Confirmação, Falha, Agendada ou Sucesso para o agente de solicitação 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 envia o trabalho para a classe derivada.

Processamento de eventos síncronos

Para solicitações fáceis de executar e rápidas de serem concluídas, o manipulador faz o trabalho de forma síncrona e retorna o evento Sucesso, 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 DTO (objeto de transferência de dados de solicitação), chama e aguarda um único serviço para fazer o trabalho e retorna uma resposta de Sucesso ou Falha.

Processamento de eventos assíncronos

Algumas solicitações são de execução prolongada. Por exemplo, a codificação de arquivos de mídia pode levar horas. Nestes casos um manipulador de solicitações assíncronas avalia a solicitação, valida os argumentos e inicia a operação de execução prolongada. 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 concluído com Sucesso ou Falha para o trabalho. Embora permaneça sem estado, o manipulador deve recuperar o contexto de operação original e colocá-lo no conteúdo da mensagem de evento Concluído.

Por exemplo, o BlobCopyHandler mostra um fluxo assíncrono simples. O manipulador obtém 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 execução prolongada, o BlobCreatedHandler consome o evento de plataforma Microsoft.Storage.BlobCreated, extrai o contexto de operação original e publica uma resposta de conclusão de Sucesso ou Falha.

Funções de longa execução

Quando o Gridwich implanta um novo Aplicativo de Funções, ele pode descartar os processos atuais de execução prolongada. Se esses processos terminarem abruptamente, não haverá nenhum status e nenhum relatório para o chamador. O Gridwich deve implantar novos Aplicativos de Funções enquanto lida normalmente com a transição para funções de execução prolongada e não faltam mensagens.

A solução deve:

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

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

O diagrama a seguir mostra o funcionamento da maioria dos trabalhos do Gridwich. A caixa verde representa um trabalho que o Gridwich passa para um serviço externo. O Gridwich reage de forma orientada a eventos para o status. A caixa vermelha mostra uma função que é de execução prolongada no próprio Gridwich.

O runtime do Functions adiciona o token de cancelamento durante o desligamento do aplicativo. O Gridwich detecta o token e retorna códigos de erro para todas as solicitações e processos em execução no momento.

A implantação de slot 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 troca as instâncias do slot. A instância antiga é reiniciada como a última etapa do processo.

O Gridwich aguarda 30 segundos depois de remapear os nomes de host, portanto, para funções disparadas por HTTP, o Gridwich garante pelo menos 30 segundos antes da reinicialização do slot de produção antigo. Outros gatilhos podem ser controlados por configurações de aplicativo sem um mecanismo para aguardar as atualizações de configuração do aplicativo. Essas funções correm o risco de interrupção se a execução for iniciada antes da reinicialização do slot de produção antigo.

Para obter mais informações, confira O que acontece durante uma troca de slots para o Azure Functions e Slots de implantação 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 Cofre de Chaves do Azure. Os processos de orquestração de CI/CD e saga usam Azure Repos, Azure Pipelines e Terraform.

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

  O Gridwich encapsula eventos no objeto de propriedade esquema da Grade de EventosEvent.Data, que é opaco para o agente da Grade de Eventos e a camada de transporte. O Gridwich também usa os campos de objeto eventType e dataVersion para rotear eventos. Para que o agente de solicitação da Grade de Eventos possa ser substituído por outros agentes 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 campos topic ou subject.

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

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

• O Azure Key Vault protege chaves criptográficas, senhas e outros segredos que o Azure e os serviços e aplicativos de terceiros usam.

• O Azure DevOps é um conjunto de serviços de desenvolvedores e operações, incluindo repositórios de código baseados em Git e pipelines automatizados de build e lançamento, que se integram ao Azure. O 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.

• O Terraform é uma ferramenta de software livre que usa a Infraestrutura como Código para provisionar e gerenciar infraestruturas e serviços.

Alternativas

• Durable Functions, que têm um repositório de estado interno para operações de longa execução, também pode fornecer um contexto de operação opaco. O Durable Functions poderia criar uma série de tarefas dentro de uma operação e salvar o contexto de operação como uma entrada ou saída para a operação. Na verdade, o Gridwich poderia usar o Durable Functions para todas as atividades de trabalho, mas essa abordagem aumentaria a complexidade do código.

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

• 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 IoC (Inversion of Control), mas você pode extrair as interfaces em uma biblioteca de gateway de infraestrutura de armazenamento principal separada.

• O Gridwich Functions App usa injeção de dependência para registrar um ou mais manipuladores de solicitação para tipos de eventos específicos e versões de dados. 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 a assinatura do evento e o mecanismo de filtragem que a plataforma da Grade de Eventos fornece. Esse mecanismo impõe um modelo de implantação 1:1, em que uma Azure Function hospeda apenas um manipulador de eventos. Embora o Gridwich use um modelo 1:muitos, sua arquitetura limpa significa que refatorar a solução para 1:1 não seria difícil.

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

Detalhes do cenário

Um conhecido conglomerado de mídia e entretenimento em massa substituiu seu serviço de streaming de vídeo local por uma solução baseada em nuvem para ingestão, processamento e publicação de ativos de vídeo. As principais metas 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 a solicitações de mídia.
• Aprimore a codificação e os novos recursos de ingestão e distribuição em escala e com uma abordagem bem arquitetada.
• Implemente a CI/CD (integração e entrega contínua) no pipeline de MAM (gerenciamento de ativos de mídia).

Para atingir essas metas, a equipe de engenharia da Microsoft desenvolveu o Gridwich, uma estrutura de processamento de eventos sem estado orientada por um sistema de orquestração de fluxo de trabalho de saga externa.

Possíveis casos de uso

A equipe de engenharia desenvolveu o Gridwich para se alinhar com princípios e padrões do setor para:

• Arquitetura de monólito limpo
• Estrutura e nomenclatura do projeto
• CI/CD
• Uso e dimensionamento do Armazenamento do Azure
• Logging

O sistema Gridwich incorpora as práticas recomendadas para o processamento e a entrega de ativos de mídia no Azure. Embora o sistema Gridwich seja específico para mídia, o processamento de mensagens e a estrutura de eventos podem ser aplicados a qualquer fluxo de trabalho de processamento de eventos sem estado.

Implantar este cenário

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

Recursos relacionados

• Projeto inicial do Terraform para o Azure Pipelines
• Exemplo do Azure Function com Grade de Eventos e sanduíche do Terraform. Assine uma Azure Function para Eventos da Grade de Eventos por meio do Terraform, usando um Sanduíche do Terraform.
• MediaInfoLib com Armazenamento do Azure. O Azure Functions e os exemplos de console que usam o .NET Core multiplataforma para recuperar um relatório em um arquivo de mídia armazenado no Armazenamento do Azure.
• Blazor do Visualizador da Grade de Eventos. Um aplicativo Event Grid Viewer, usando Blazor e SignalR, com suporte de autorização do Microsoft Entra.
• Azure Function com Identidade de Serviço Gerenciada para Armazenamento do Azure. Use a Identidade de Serviço Gerenciado entre o Azure Functions e o Armazenamento do Azure.