As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Padrão Pub/sub
Quando uma plataforma cresce, pode ser difícil para diferentes microsserviços interagirem sem criar interdependência. O padrão de publicação/assinatura (pub/sub) fornece comunicação assíncrona entre vários Os serviços, AWS como o Amazon SQS, o Lambda ou o Amazon Simple Storage Service (Amazon S3), sem criar interdependência. Nesse padrão, os microsserviços publicam eventos como mensagens em um canal que os assinantes podem ouvir. Por exemplo, uma fábrica pode usar um padrão pub/sub para permitir que o equipamento publique problemas ou falhas em um canal; um assinante pode então exibir e registrar esses problemas de equipamento.
Você deve considerar o uso desse padrão se:
-
Você tem uma arquitetura orientada por eventos.
-
Você pode habilitar a arquitetura fracamente acoplada.
-
Você não precisa concluir todas as partes operacionais de uma transação antes da resposta ao sistema de chamada (certas operações podem ser assíncronas).
-
Você precisa escalar para volumes que estão além da capacidade de um datacenter tradicional. Esse nível de escalabilidade se deve principalmente a operações paralelas, cache de mensagens, roteamento baseado em árvore e outros recursos incorporados ao modelo pub/sub.
Existem várias desvantagens em usar esse padrão. Por exemplo, o padrão pub/sub normalmente não garante a entrega de mensagens para todos os tipos de assinantes, embora determinados serviços, como o Amazon Simple Notification Service (Amazon SNS), possam fornecer entrega exatamente uma vez para alguns subconjuntos de assinantes. Outra desvantagem é que um editor pode presumir que um assinante está ouvindo um canal quando, na verdade, não está.
Caso de uso
Nesse caso de uso, um tópico do SNS é usado para publicar eventos em vários microsserviços dependentes em um sistema de seguro. Depois que um cliente faz o pagamento mensal, as informações devem ser atualizadas em subsistemas como “Cliente” ou “Vendas”, e um e-mail deve ser enviado ao cliente com a confirmação do pagamento. Esse padrão pode ser implementado usando o Amazon SNS ou o Amazon EventBridge.
O EventBridge filtra eventos entre vários assinantes. A implementação do EventBridge fornece as duas opções a seguir:
-
Envie três eventos com diferentes tipos de eventos. O alvo distante os pega com base na regra do evento.
-
Envie uma mensagem com três regras de evento ouvindo o mesmo tipo de evento. Dados desnecessários são filtrados antes que alvos específicos sejam invocados.
Implementação do Amazon SNS
A ilustração a seguir mostra como o Amazon SNS é usado para implementar o padrão pub/sub. Depois que um usuário faz um pagamento, uma mensagem do SNS é enviada pela função do Lambda “Pagamentos” para o tópico do SNS “Pagamentos”. Esse tópico do SNS tem três assinantes que recebem uma cópia da mensagem e a processam.
Implementação do Amazon EventBridge
Na ilustração a seguir, o EventBridge é usado para criar uma versão do padrão pub/sub na qual os assinantes são definidos usando regras de eventos. Depois que um usuário faz um pagamento, a função do Lambda “Pagamentos” envia uma mensagem para o EventBridge usando o barramento de eventos padrão com base em um esquema personalizado que tem três regras diferentes apontando para alvos diferentes. Cada microsserviço processa as mensagens e executa as ações necessárias.
