Google Cloud Pub/Sub — O que é? Como funciona?
Hoje em dia é bem comum ouvir falar sobre processamento em fila. Existem diversas ferramentas no mercado que tratam desse aspecto.
Mas se você busca algo de simples utilização e configuração, eu sugiro que você confira o serviço de mensagens da Google Cloud Plataform (GCP), o Cloud Pub/Sub!
“O Pub/Sub é um serviço de mensagens em tempo real totalmente gerenciado que permite o envio e o recebimento de mensagens entre aplicativos independentes.” (https://cloud.google.com/pubsub/docs)
Antes de mais nada
Antes de mais nada você precisa ter uma conta associada ao google (gmail) e habilitar sua conta na GCP ( https://cloud.google.com/).
Não entrarei em detalhes sobre esse ponto, subentende-se que você já tenha sua conta GCP ativa e um projeto configurado.
Entendendo por fora
Você pode criar um tópico no console (portal) da GCP, no menu lateral Pub/Sub. O tópico seria como uma porta de entrada para suas mensagens. E mensagem aqui pode ser qualquer valor ou objeto, que geralmente estará em um formato json.
A aplicação (ou sistema — chame como quiser) que coloca uma mensagem no tópico é chamada de Publisher.
Então uma aplicação “Publisher A” poderia colocar uma mensagem “Message 1” em um tópico “A” e uma aplicação “Publisher B” poderia colocar uma mensagem “Message 2” em um tópico “B” e assim por diante.
Com isso as mensagens vão sendo enfileiradas nesses tópicos, cada mensagem no seu respectivo tópico de destino.
Do outro lado, existirão outras aplicações que leem essas mensagens com a finalidade de executar algum procedimento ou processo com base nas informações contidas na mensagem.
Essas aplicações são chamadas de Subscribers e se “conectam” aos tópicos através de Subscriptions que também podem ser configuradas no console da GCP, no mesmo menu lateral Pub/Sub.
Então seguindo o exemplo acima, podemos ter uma aplicação “Subscriber X” que lê mensagens do tópico “A” através de uma subscription “XA” e também lê mensagens do tópico “B” através de uma subscription “XB”. Cada mensagem será processada por uma rotina dentro da aplicação “Subscriber X”.
Indo além, podemos ter várias Subscriptions para um unico tópico. E neste caso cada mensagem será entregue igualmente em cada uma das Subscriptions. Isso seria útil em um cenário de compra, por exemplo, e preciso disparar o processo de emissão de NF e de separação de estoque. Com uma mensagem unica, entregue em 2 Subscriptions eu poderia disparar cada um dos processos nas respectivas aplicações, de NF e de Estoque. E não necessariamente precisam ser aplicações separadas, porém essa abordagem de processamento é mais comum de ser utilizada em aplicações distribuídas (serviços ou microserviços).
Entendendo por dentro
Isso tudo explicado anteriormente é a visão externa do processo. Mas como o pub/sub controla quais mensagens já foram processadas, quais estão em processamento, etc? É um cenário bem comum eu ter algumas instâncias de uma dada aplicação rodando e puxando as mensagens via um Subscriber, como evita-se que uma mensagem seja consumida mais de uma vez e gere duplicidade no processamento?
Ao criar uma Subscription você tem algumas informações que são configuráveis:
Tipo de envio: Subscription do tipo PULL permitem que uma aplicação determine o momento de puxar a mensagem. Subscription do tipo PUSH entrega a mensagem para uma dada aplicação assim que a mensagem chega (na verdade de acordo com a ordem e vazão da fila).
Prazo de confirmação: aqui está uma configuração bem importante. Variando de 10 segundos até 10 minutos, esse campo indica o tempo que uma mensagem será dada como “Em Processamento” antes de ser disponibilizada novamente para processamento na fila. Ou seja, digamos que configuro essa informação com 10 segundos. Quando uma “mensagem 1” é obtida para processamento por um Subscriber X, no momento que ela é obtida, ela fica indisponível para qualquer outra instância ou aplicação naquela Subscription, por 10 segundos. Se em 10 segundos o Subscriber X não der uma confirmação de processamento OK, a “mensagem 1” volta para a fila e outras instâncias ou aplicações podem obter ela para processamento novamente. Esse ato de confirmar o processamento é chamado no Pub/Sub de Acknowledge. E por isso essa informação é importante pois se eu informar um valor baixo, como o minimo 10 segundos e o processo de consumo da mensagem levar mais tempo que isso, as mensagens começarão a ser processadas diversas vezes. Por padrão, sempre utilizo o tempo máximo de 10 minutos, exceto em casos específicos.
Duração de retenção da mensagem: em conjunto com o campo anterior, esse campo é bem importante também pois indica por quanto tempo a mensagem será mantida na fila, aguardando um Acknowledge, antes de ser desconsiderada. Esse campo pode ir de 10 minutos até 7 dias. E também é importante que não fique um valor muito pequeno, pois caso a aplicação que consome fique fora por muito tempo, as mensagens podem se perder. E não queremos isso, afinal, uma das vantagens de usar uma ferramenta como o Pub/Sub é que mesmo em casos de falha, a solução se torna resiliente e vai processar as mensagens em algum momento.
Indo além na GCP e Vantagens
O pub/sub como uma boa ferramenta de cloud se conecta com diversas outras ferramentas da GCP e isso pode ser uma vantagem para quem usa a cloud da Google.
Você pode enviar mensagens para o Pub/Sub direto de um Cloud Scheduler por exemplo, ou disparar um Cloud Function ou Cloud Run quando uma mensagem cair em um tópico.
E o Pub/Sub é utilizado por serviços do próprio Google e tem uma grande capacidade, é distribuído mundialmente, atende multi região, etc, tudo de forma transparente para quem usa. Ou seja, alta disponibilidade, segurança, etc. Tudo de bom!
A ideia deste artigo era dar uma passada geral nos conceitos envolvidos no Google Cloud Pub/Sub. Futuramente pretendo demonstrar com exemplos práticos com .NET Core a utilização e simplicidade do pub/sub.
Abaixo das imagens deste texto eu deixei referências para a documentação da Google, onde muitos outros detalhes são explicados.
Espero ter ajudado!
