Em ambientes nativos da nuvem, as arquiteturas assíncronas são essenciais para desacoplar serviços, melhorando a escalabilidade e reforçando a confiabilidade do sistema. Uma fila de mensagens forma a base de uma arquitetura assíncrona, e você pode escolher uma entre inúmeras opções, desde ferramentas de código aberto como Kafka e RabbitMQ até sistemas gerenciados como Google Cloud Pub/Sub e AWS SQS. No entanto, testar fluxos de trabalho assíncronos enfileirados apresenta desafios únicos. Este artigo explora abordagens pragmáticas para testar esses fluxos de trabalho usando OpenTelemetry, com foco na relação custo-benefício, otimização de recursos e simplicidade operacional.
Adicionar uma fila como Kafka ao seu ambiente envolve configurações complexas com vários corretores, produtores e consumidores. Tentar replicar um ambiente com uma fila para teste envolve uma grande quantidade de aumento operacional, com considerações como segurança, replicação, particionamento e manutenção de uma réplica atualizada. A complexidade aumenta ao tentar consumir mensagens com serviços em diversas linguagens e estruturas, tornando os testes isolados de ponta a ponta uma tarefa exigente.
Observe que para esses vários modelos e no exemplo a seguir, “inquilino” tem um significado específico.
Por “locatário”, queremos dizer um desenvolvedor ou equipe que precisa executar um cenário de teste isoladamente. Se duas equipes estiverem trabalhando juntas e colaborando em uma versão, elas poderão ser um único locatário. Mas geralmente, isso significará uma equipe que deseja testar algumas mudanças sem que essas mudanças afetem mais ninguém.
Ao usar uma fila grande e complexa com muitos editores e assinantes, dois métodos são a solução mais comum para criar um ambiente de teste. Com infraestrutura isolada, todo o cluster é copiado com todos os serviços, editores e assinantes relacionados para cada locatário. Com tópicos isolados, a fila é configurada para usar um canal especial para editores e assinantes de teste. Ambas as abordagens têm suas desvantagens, incluindo custos de manutenção e configuração, e a precisão final (às vezes duvidosa) desses novos ambientes de teste para produção. Por enquanto, consideraremos uma solução que ofereça uma solução altamente escalável para vários locatários, com um ambiente que se assemelhe muito à produção.
Em vez de replicar componentes que não deveriam ser alterados por um locatário, podemos nos concentrar nas partes do cluster que queremos isolar: as mensagens que passam entre os serviços. Com o isolamento de mensagens, podemos compartilhar todos os recursos necessários e até permitir que nossos serviços em teste se comuniquem com a versão “baseline” de outros serviços.
Isso começa estabelecendo um ambiente de linha de base compartilhado com segurança entre os locatários, usando roteamento dinâmico para solicitações e mensagens, adicionando propagação de contexto via OpenTelemetry. Esta abordagem minimiza a configuração da infraestrutura, as despesas operacionais e os custos, ao mesmo tempo que garante ambientes atualizados através da integração contínua. Também não há aumento para incluir um inquilino de teste adicional.
Neste modelo, cada locatário recebe um ID exclusivo, com mapeamentos para versões de serviço específicas. Para a maioria dos serviços, qualquer inquilino espera interagir com uma versão de base, com apenas alguns serviços selecionados sincronizados com uma versão mais recente. Esses serviços modificados podem se comunicar entre si ou com outros serviços no cluster normalmente.
Os IDs de locatário são usados para roteamento em comunicações síncronas (HTTP, gRPC) e assíncronas (enfileiradas). Ou seja, tanto as mensagens de e para serviços individuais quanto as mensagens que entram e saem da fila precisarão de instruções de roteamento especializadas. Um dos métodos para conseguir isso é usar uma malha de serviço.
Há suporte em qualquer sistema de filas para adicionar cabeçalhos arbitrários para afetar o roteamento. No Apache Kafka, os produtores incluem IDs de locatário nos cabeçalhos das mensagens e os consumidores usam esses IDs para processamento seletivo de mensagens. Esta configuração requer a modificação dos consumidores Kafka e o aproveitamento do OpenTelemetry para propagação de contexto. O processo é bastante semelhante ao usar o RabbitMQ, que também pode incorporar cada mensagem com um ID de locatário.
A implementação do isolamento de mensagens para testes e experimentação baseados em isolamento de solicitações possui alguns componentes necessários.
Neste exemplo, um locatário pode criar novas versões de serviços (B” e C”) e adicioná-los como produtores e consumidores sem interferir no processo de teste de outras equipes.
Uma convenção de nomenclatura simples para esses novos grupos de consumidores seria os grupos de consumidores originais do serviço com “-(nome da sandbox)” anexado.
Alguma consideração deve ser dada ao implementar este sistema para fluxos que não começam com uma única solicitação. Se, por exemplo, um cron job estiver lendo linhas de uma tabela, processando-as e publicando cada uma delas como uma mensagem em sua fila, você precisará emitir um ID de locatário à medida que cada linha for lida, exigindo que você projete o sistema de acordo com seus objetivos. . Uma vez que haja clareza sobre como as versões de referência e “em teste” dos consumidores particionarão as mensagens originadas do banco de dados, o sistema precisará ser projetado adequadamente.
A abordagem de isolamento de mensagens oferece uma solução escalonável e econômica para testar fluxos de trabalho assíncronos baseados em Kafka. Reduz a necessidade de infraestrutura extensa, mantendo alto isolamento e flexibilidade. Este método, extensível a outras filas de mensagens, é uma escolha estratégica para aplicações assíncronas modernas.
A continuação deste artigo abordará os detalhes da implementação do isolamento de mensagens com um fluxo de trabalho assíncrono usando Signadot.
Para obter mais informações e conselhos detalhados de implementação sobre testes com filas internas, participe da discussão no canal Slack da comunidade da Signadot.
YOUTUBE.COM/THENEWSTACK
A tecnologia avança rápido, não perca um episódio. Inscreva-se em nosso canal no YouTube para transmitir todos os nossos podcasts, entrevistas, demonstrações e muito mais.
SE INSCREVER
