Visão geral do Eventarc

O Eventarc permite criar arquiteturas orientadas por eventos sem ter que implementar, personalizar ou manter a infraestrutura subjacente. Ele oferece uma solução padronizada para gerenciar o fluxo de alterações de estado, chamadas de eventos, entre microsserviços separados. Quando acionado, o Eventarc encaminha esses eventos para vários destinos (neste documento, consulte Destinos de eventos) e gerencia a entrega, segurança, autorização, observabilidade e erros de processamento para você.

É possível gerenciar o Eventarc no Console do Google Cloud, na linha de comando, usando a CLI gcloud ou a API Eventarc.

O Eventarc está em conformidade com estas certificações e padrões.

O Eventarc encaminha eventos de provedores de eventos a destinos de eventos.
Figura 1. O Eventarc encaminha eventos de provedores de eventos a destinos de eventos (clique no diagrama para ampliar).

1 Eventos de provedores do Google são enviados diretamente da origem (Cloud Storage, por exemplo) ou usando entradas de registros de auditoria do Cloud, e Pub/Sub como a camada de transporte. Os eventos de origens do Pub/Sub podem usar um tópico existente do Pub/Sub ou o Eventarc criará um tópico automaticamente e o gerenciará para você.

2 Eventos dos destinos do Google Kubernetes Engine (GKE), incluindo serviços de veiculação do Knative em execução em um cluster do GKE, usam o encaminhador de eventos do Eventarc para extrair novos eventos do Pub/Sub e encaminhá-los ao destino. Esse componente atua como mediador entre a camada de transporte do Pub/Sub e o serviço de destino. Ele funciona em serviços atuais e também oferece suporte a serviços de sinalização (incluindo os não expostos fora do cluster totalmente gerenciado), além de simplificar a configuração e a manutenção. O ciclo de vida do encaminhador de eventos é gerenciado pelo Eventarc. Se você excluir acidentalmente o encaminhador de eventos, o Eventarc restaurará esse componente.

3Os eventos de uma execução de fluxo de trabalho são transformados e transmitidos para o fluxo de trabalho como argumentos de tempo de execução. Os fluxos de trabalho podem combinar e orquestrar serviços do Google Cloud e de APIs baseados em HTTP na ordem que você definir.

4 Todas as funções orientadas a eventos nas funções do Cloud Run (2a geração) usam gatilhos do Eventarc para entregar eventos. É possível configurar gatilhos do Eventarc ao implantar uma função do Cloud Run usando a interface de funções do Cloud Run.

Principais casos de uso

O Eventarc é compatível com muitos casos de uso para aplicativos de destino. Por exemplo:

Configurar e monitorar
  • Configuração do sistema: instale uma ferramenta de gerenciamento de configurações em uma nova VM quando ela for iniciada.
  • Corrigir automaticamente: detecta se um serviço não está respondendo corretamente e o reinicia automaticamente.
  • Alertas e notificações: monitore o saldo de um endereço de carteira de criptomoedas e acione as notificações.
Harmonizar
  • Registros em diretórios: ative um selo de funcionário quando um novo funcionário entrar em uma empresa.
  • Sincronização de dados: acione um fluxo de trabalho de contabilidade quando um cliente em potencial for convertido em um sistema de CRM.
  • Rotulagem de recursos: rotule e identifique o criador de uma VM quando ela for criada.
Analisar
  • Análise de sentimento: use a API Cloud Natural Language para treinar e implantar um modelo de ML que anexe um índice de satisfação a um tíquete de atendimento ao cliente assim que ele for concluído.
  • Reprocessamento e análise de imagens: remova o plano de fundo e categorize automaticamente uma imagem quando um varejista a adicionar a um armazenamento de objetos.

Eventos

Um evento é um registro de dados que expressa uma ocorrência e o contexto dela. Um evento é uma unidade distinta de comunicação, independente de outros eventos. Por exemplo, um evento pode ser uma alteração de dados em um banco de dados, um arquivo adicionado a um sistema de armazenamento ou um job programado.

Consulte Tipos de evento compatíveis com o Eventarc.

Provedores de eventos

Os eventos são encaminhados de um provedor de eventos (a origem) para consumidores de eventos interessados. O roteamento é realizado com base nas informações contidas no evento, mas um evento não identifica um destino de roteamento específico. O Eventarc é compatível com eventos dos seguintes provedores:

  • Mais de 130 provedores do Google Cloud Eles enviam eventos (por exemplo, uma atualização de um objeto em um bucket do Cloud Storage ou uma mensagem publicada em um tópico do Pub/Sub) diretamente da origem ou por meio de entradas dos Registros de auditoria do Cloud.
  • Fornecedores terceirizados. Esses provedores enviam eventos diretamente da origem (por exemplo, provedores SaaS de terceiros, como o Datadog ou a plataforma Check Point CloudGuard).

Destinos de eventos

Os eventos são roteados para um destino específico (o destino) conhecido como receptor (ou consumidor) do evento por uma assinatura de push do Pub/Sub.

Funções do Cloud Run (2ª geração)

Todas as funções orientadas a eventos nas funções do Cloud Run (2a geração) usam gatilhos do Eventarc para entregar eventos. Um gatilho do Eventarc permite que uma função seja acionada por qualquer tipo de evento compatível com o Eventarc. Você pode Configurar gatilhos do Eventarc quando você implanta uma função do Cloud Run usando as funções do Cloud Run interface gráfica do usuário.

Cloud Run

Saiba como criar um serviço receptor de eventos que pode ser implantado no Cloud Run.

Para determinar a melhor maneira de encaminhar eventos para um serviço do Cloud Run, consulte Opções de roteamento do evento.

GKE

O Eventarc é compatível com a criação de gatilhos direcionados aos serviços do Google Kubernetes Engine (GKE). Isso inclui os endpoints públicos de serviços particulares e públicos em execução em um cluster do GKE.

  • Para que o Eventarc segmente e gerencie serviços em qualquer cluster, conceda todas as permissões necessárias à conta de serviço do Eventarc.

  • Ative a Federação de Identidade da Carga de Trabalho do GKE no cluster do GKE em que o serviço de destino está sendo executado. A Federação de Identidade da Carga de Trabalho para o GKE é obrigatória para configurar corretamente o encaminhador de eventos e é a forma recomendada de acessar serviços do Google Cloud de aplicativos em execução no GKE devido às propriedades de segurança e maleabilidade da ferramenta. Para mais informações, consulte Ativar a Identidade da carga de trabalho.

Endpoints HTTP internos em uma rede VPC

É possível configurar o roteamento de eventos para um endpoint HTTP interno em uma rede de nuvem privada virtual (VPC). Para configurar o gatilho, você também precisa fornecer um ID de anexo de rede. Para mais informações, consulte Rotear eventos para um endpoint HTTP interno em uma rede VPC.

Fluxos de trabalho

Uma execução do seu fluxo de trabalho é acionada:

  • Quando as mensagens são publicadas em um tópico do Pub/Sub
  • Quando um registro de auditoria é criado que corresponde aos critérios de filtro do gatilho
  • Em resposta a um evento não mediado, como uma atualização de um objeto em um bucket do Cloud Storage

Os fluxos de trabalho exigem um e-mail da conta de serviço do IAM que o gatilho do Eventarc usará para invocar as execuções do fluxo de trabalho. Recomendamos o uso de uma conta de serviço com os privilégios mínimos necessários para acessar os recursos necessários. Para mais informações, consulte Criar e gerenciar contas de serviço.

Formato e bibliotecas de eventos

O Eventarc entrega eventos, independentemente do provedor, para o destino em um formato CloudEvents que usa uma solicitação HTTP no modo de conteúdo binário. O CloudEvents é uma especificação para descrever metadados de eventos de maneira comum, na base de computação nativa da nuvem, e organizado pelo grupo de trabalho sem servidor da fundação.

Dependendo do provedor do evento, é possível especificar a codificação dos dados de payload do evento como application/json ou application/protobuf. Os buffers de protocolo (ou Protobuf) são um mecanismo extensível neutro em relação à linguagem e à plataforma para serializar dados estruturados. Observações:

  • Para origens personalizadas ou provedores terceirizados ou para eventos diretos no Pub/Sub, essa opção de formatação não é compatível.
  • Um payload de evento formatado em JSON é maior que um formatado em Protobuf e isso pode afetar a confiabilidade, dependendo do destino do evento e dos limites do tamanho do evento. Saiba mais em Problemas conhecidos.

Destinos alvo, como funções do Cloud Run, Cloud Run e GKE, consomem eventos no formato HTTP. Para destinos do Workflows, o serviço converte o evento em um objeto JSON e o transmite para a execução do fluxo de trabalho como um argumento do ambiente de execução.

O uso de uma maneira padrão para descrever metadados de evento garante consistência, acessibilidade e portabilidade. Os consumidores de eventos podem ler esses eventos diretamente ou usar os SDKs e bibliotecas do Google CloudEvents em várias linguagens (incluindo C#, Go, Java, Node.js e Python) para ler e analisar os eventos:

O Eventarc entrega eventos no formato CloudEvents. Leia os eventos
    diretamente ou use bibliotecas ou SDKs do Google CloudEvents para analisá-los.
Figura 2. O Eventarc entrega eventos no formato CloudEvents aos destinos dos eventos. Leia esses eventos diretamente ou use bibliotecas ou SDKs do Google CloudEvents para ler e analisar os eventos.

A estrutura do corpo HTTP de todos os eventos está disponível no repositório GitHub de eventos do Google Cloud.

Compatibilidade com versões anteriores

O Eventarc considera a adição dos seguintes atributos e campos compatíveis com versões anteriores:

  • Atributos de filtragem opcionais ou atributos somente saída
  • Campos opcionais para o payload do evento

gatilhos do Eventarc

Os eventos ocorrem independentemente de o destino reagir a eles. Crie uma resposta a um evento com um gatilho. Ele é uma declaração de que você tem interesse em um determinado evento ou grupo de eventos. Ao criar um gatilho, você especifica filtros que permitem capturar e tomar ações sobre esses eventos específicos, incluindo o roteamento de uma fonte de eventos para um destino. Para mais informações, consulte Representação REST de um recurso de gatilho e Provedores e destinos de eventos.

As assinaturas do Pub/Sub criadas para o Eventarc persistem independentemente da atividade e não expiram. Para alterar as propriedades da assinatura, consulte Propriedades de assinatura.

O Eventarc é compatível com gatilhos para esses tipos de evento:

Eventos de registros de auditoria do Cloud (CAL)
DescriçãoOs registros de auditoria do Cloud fornecem registros de auditoria de acesso de dados e atividade do administrador para cada projeto do Cloud, pasta e organização. Os serviços do Google Cloud gravam entradas nesses registros. O Eventarc oferece suporte a registros de auditoria para envolvidos no projeto. Para mais informações, consulte os valores serviceName e methodName específicos que são compatíveis com Eventarc como tipos de evento.
Tipo de filtro do eventoOs gatilhos d o Eventarc com type=google.cloud.audit.log.v1.written enviam solicitações para seu serviço ou fluxo de trabalho quando um registro de auditoria é criado e corresponde aos critérios de filtro do gatilho.
Eventos diretos
DescriçãoO Eventarc pode ser acionado por vários eventos diretos, como uma atualização de um bucket do Cloud Storage, uma atualização de um modelo da Configuração remota do Firebase ou alterações em recursos sobre os serviços do Google Cloud.

O Eventarc pode ser acionado por mensagens publicadas nos tópicos do Pub/Sub. Pub/Sub é um barramento de mensagens distribuído globalmente que é escalonado automaticamente conforme necessário. Como o Eventarc pode ser invocado por mensagens em um tópico do Pub/Sub, é possível integrar facilmente o Eventarc a qualquer outro serviço compatível com o Pub/Sub como destino.

Tipo de filtro do eventoOs gatilhos do Eventarc com tipos específicos de filtro de evento enviam solicitações ao serviço ou fluxo de trabalho quando ocorre um evento que corresponde aos critérios de filtro do gatilho. Por exemplo, type=google.cloud.storage.object.v1.finalized (quando um objeto é criado em um bucket do Cloud Storage) ou type=google.cloud.pubsub.topic.v1.messagePublished (quando uma mensagem é publicada no tópico do Pub/Sub especificado).

Local do gatilho

Os serviços do Google Cloud, como o Cloud Storage, podem ser configurados para serem regionais ou multirregionais. Alguns serviços, como o Cloud Build, podem ser configurados globalmente.

O Eventarc permite criar gatilhos regionais ou, em alguns eventos, um gatilho global e receber eventos de todas as regiões. Para ver mais informações, consulte Entender os locais do Eventarc.

Especifique o local do gatilho do Eventarc para corresponder ao local do serviço do Google Cloud que está gerando eventos e evite problemas de desempenho e residência de dados causados por um gatilho global.

É possível especificar locais de gatilho usando uma sinalização --location com cada comando. Para destinos do Cloud Run, se uma sinalização --destination-run-region não for especificada, presumirá que o serviço está na mesma região que o acionador. Para mais informações, consulte a referência da CLI do Google Cloud.

Confiabilidade e entrega

As expectativas de exibição são as seguintes:

  • Os eventos que usam os registros de auditoria do Cloud são entregues em menos de um minuto (Embora um gatilho de Registros de auditoria do Cloud seja criado imediatamente, pode levar até dois minutos para que ele se propague e filtre eventos.)
  • Os eventos que usam Pub/Sub são enviados em segundos

Não há garantia de entrega por ordem de chegada. A ordem estrita prejudicaria os recursos de disponibilidade e escalonabilidade do Eventarc que correspondem aos da camada de transporte, o Cloud Pub/Sub. Para mais informações, consulte Como ordenar mensagens.

A latência e a capacidade são os melhores esforços. Elas variam com base em vários fatores, incluindo se o gatilho do Eventarc é regional, multirregional ou global; a configuração de um serviço específico; e a carga da rede nos recursos de uma região do Google Cloud.

cotas e limites de uso que se aplicam geralmente ao Eventarc. Há também cotas e limites de uso específicos do Workflows.

Política de repetição de eventos

As características de nova tentativa do Eventarc correspondem às da camada de transporte, o Cloud Pub/Sub. Para mais informações, consulte Novas tentativas de solicitações e Espera de push.

A duração padrão de retenção de mensagens definida pelo Eventarc é de 24 horas com um atraso de espera exponencial.

É possível atualizar a política de nova tentativa pela assinatura do Pub/Sub associada ao gatilho do Eventarc:

  1. Abra a página Detalhes do gatilho.
  2. Clique no tópico.
  3. Clique na guia Assinaturas.

Qualquer assinatura criada automaticamente pelo Eventarc terá este formato: projects/PROJECT_ID/subscriptions/eventarc-REGION-TRIGGER_ID-sub-SUBSCRIPTION_ID. Para mais informações sobre limites de assinatura, consulte Limites de recursos do Pub/Sub.

Se o Pub/Sub tentar entregar uma mensagem, mas o destino não conseguir reconhecê-la, o Pub/Sub vai enviar a mensagem novamente com uma espera exponencial mínima de 10 segundos. Se o destino ainda não confirmar a mensagem, mais tempo será adicionado ao atraso em cada nova tentativa (até o máximo de 600 segundos) e a mensagem será reenviada para o destino.

O Workflows reconhece eventos assim que a execução do fluxo de trabalho é iniciada.

Tópicos de mensagens inativas

Se o destino não receber a mensagem, será possível encaminhar as mensagens não entregues para um tópico de mensagens inativas (também conhecido como fila de mensagens inativas). Um tópico de mensagens inativas pode armazenar mensagens que o destino não consegue confirmar. Defina um tópico de mensagens inativas ao criar ou atualizar uma assinatura do Pub/Sub, não ao criar um tópico do Pub/Sub ou quando o Eventarc cria um tópico do Pub/Sub. Para saber mais, consulte Como corrigir falhas nas mensagens.

Erros que não garantem novas tentativas

Quando os aplicativos usam o Pub/Sub como a fonte do evento e o evento não é entregue, ele é repetido automaticamente, com exceção dos erros que não garantem novas tentativas. Não ocorrerão novas tentativas de eventos de nenhuma origem para o destino do fluxo de trabalho. Se a execução do fluxo de trabalho começar, mas depois falhar, as execuções não serão repetidas. Para resolver esses problemas de serviço, você precisa processar erros e novas tentativas no fluxo de trabalho.

Duplicar eventos

Eventos duplicados podem ser entregues aos manipuladores de eventos. De acordo com a especificação do CloudEvents, a combinação dos atributos source e id é considerada única e, portanto, todos os eventos com a mesma combinação são considerados duplicados. Implemente manipuladores de eventos idempotentes como prática recomendada.

Observabilidade

Registros detalhados do Eventarc, Cloud Run, GKE e Pub/Sub e Workflows estão disponíveis nos Registros de auditoria do Cloud.

Recuperação de desastres

Aproveite as zonas e regiões para ter confiabilidade em caso de interrupções. Para saber mais sobre como garantir que o objetivo do tempo de recuperação (RTO, na sigla em inglês) e o objetivo do ponto de recuperação (RPO, na sigla em inglês) sejam atendidos para tempos de backup e recuperação ao usar o Eventarc, consulte Como arquitetar a recuperação de desastres para infraestrutura em nuvem falhas temporárias.

A seguir