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.
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 no Cloud Functions (2a geração) usam gatilhos do Eventarc para entregar eventos. É possível configurar gatilhos do Eventarc ao implantar uma função do Cloud usando a interface do Cloud Functions.
Principais casos de uso
O Eventarc é compatível com muitos casos de uso para aplicativos de destino. Por exemplo:
| Configurar e monitorar |
|
| Harmonizar |
|
| Analisar |
|
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.
Cloud Functions (2ª geração)
Todas as funções orientadas a eventos no Cloud Functions (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. É possível configurar gatilhos do Eventarc ao implantar uma função do Cloud usando a interface do Cloud Functions.
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 Identidade da carga de trabalho no cluster do GKE em que o serviço de destino está sendo executado. A Identidade da carga de trabalho é necessária para configurar corretamente o Encaminhador de eventos e é a maneira indicada de acessar os serviços do Google Cloud a partir de aplicativos executados no GKE devido às propriedades de segurança e capacidade de gerenciamento. 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 Cloud Functions, 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:
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ção | Os registros de auditoria do Cloud fornecem registros de auditoria de atividade do administrador e acesso a dados para cada projeto, pasta e organização do Cloud.
Os serviços do Google Cloud gravam
entradas nesses registros. Essa lista de
eventos compatíveis
inclui um diretório de valores
serviceName e methodName. |
| Tipo de filtro do evento | Os 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ção | O 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 evento | Os 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.
Há 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:
- Abra a página Detalhes do gatilho.
- Clique no tópico.
- 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
- Teste o Codelab.
- Criar um gatilho para um provedor, tipo de evento e destino específicos
- Resolver problemas