Livre-se da Prisão do Legado: Migrando RPC JMS de Alta Escala para o Tanzu RabbitMQ

Muitas empresas dependem de sistemas de mensagens comerciais tradicionais para suas aplicações mais críticas. Frequentemente, esses sistemas utilizam a API Java Message Service (JMS), particularmente para padrões de Request/Response (RPC). Embora confiáveis, essas plataformas legadas podem ser caras, proprietárias e representam uma forma de “aprisionamento tecnológico legado” (legacy lock-in) que pode impedir a adoção de arquiteturas modernas.

Você pode estar se perguntando: “Queremos modernizar, mas uma plataforma moderna e open source pode realmente lidar com nossa carga de trabalho específica e de alta demanda?” A equipe VMware Tanzu recentemente fez uma parceria com um cliente para responder exatamente a essa pergunta. O cliente desejava migrar seu sistema baseado em JMS de um broker proprietário tradicional para o VMware Tanzu RabbitMQ.

Mas, primeiro, precisávamos validar se o Tanzu RabbitMQ poderia suportar a carga de trabalho deles, que não era um caso de uso simples; envolvia uma carga de trabalho RPC em escala massiva com uma rotatividade de conexões (connection churn) extrema. Este cenário é um teste de estresse perfeito para qualquer broker de mensagens moderno, e é uma história que acreditamos que muitos arquitetos e líderes de TI considerarão familiar.

O Desafio: Uma “Tempestade Perfeita” de Carga de Trabalho

Para entender o desafio, vamos analisar o ambiente do cliente conforme eles o descreveram, em suas próprias palavras. Esta não é uma carga de trabalho típica com algumas dezenas de conexões de longa duração. Este é um sistema de alto throughput definido por processos efêmeros.

Aqui está o que tivemos que replicar:

• Rotatividade Massiva de Conexões (Massive connection churn): A configuração da aplicação podia criar até 20.000 conexões paralelas. Crucialmente, cada uma dessas conexões tem vida curta; o sistema estabelece uma nova conexão para cada operação individual de request/response.
• Alto Throughput: O sistema processa de 4 milhões a 6 milhões de requisições diariamente em média, com a volatilidade elevando esse número para 20 milhões (ou até 50 milhões em algumas estimativas).
• Picos Extremos de Taxa: Durante os bursts (picos de uso), o sistema deve lidar com até 8.000 requisições por minuto, com um requisito de pico de 4.000 requisições por segundo em uma única queue (fila).
• O Padrão: A aplicação utiliza o clássico padrão JMS Request/Response, onde um cliente envia uma requisição e aguarda uma resposta em uma queue temporária.

Essa combinação de 20.000 conexões simultâneas e a constante conexão/desconexão (churn) a uma taxa de 4.000 por segundo é o teste definitivo das capacidades de manipulação de conexões de um broker.

O Teste: Simulando o Churn em Escala

Nosso objetivo era validar a carga de trabalho conforme descrita pelo cliente e provar que o Tanzu RabbitMQ poderia não apenas lidar com essa carga, mas fazê-lo com facilidade. Não rodamos apenas um benchmark simples. Escrevemos uma ferramenta de performance RPC dedicada para a ocasião, a fim de simular com precisão esse ambiente de alto churn.

Montamos um cluster Tanzu RabbitMQ de três nodes (nós) e o configuramos para lidar com um grande número de conexões usando configurações de tuning (ajuste fino) bem documentadas.

Uma característica chave do Tanzu RabbitMQ que é perfeita para este caso de uso RPC é a otimização direct reply-to (resposta direta). Esse mecanismo permite que um cliente receba uma resposta diretamente, sem a sobrecarga de criar e gerenciar milhares de queues temporárias, o que é um gargalo comum em outros sistemas.

Rodamos dois cenários principais:

1. Teste de Linha de Base (Baseline): Primeiro, estabelecemos uma linha de base com 20.000 conexões de longa duração (sem churn). O cluster lidou facilmente com 20.000 requisições por segundo. Este foi um bom começo.
2. O Teste de Churn do Mundo Real: Este foi o evento principal. Acionamos clientes para criar 20.000 conexões simultâneas, com cada cliente conectando, enviando uma requisição, recebendo uma resposta e desconectando. Miramos no pico do cliente de 4.000 requisições/segundo e, em seguida, aumentamos em 25% para 5.000 requisições/segundo.

O Resultado: Validação Confirmada

Os resultados do nosso teste de validação foram definitivos. Sob a carga extrema de 20.000 clientes simultâneos, o cluster Tanzu RabbitMQ de três nodes sustentou com sucesso as 5.000 operações de request/response por segundo — mesmo quando cada requisição envolvia uma nova conexão e desconexão.

Este teste inicial deu uma indicação clara de que o RabbitMQ poderia lidar com a exigente carga de trabalho. Mas a história não termina aí. Estamos entusiasmados em compartilhar que testes subsequentes realizados pelo cliente em seus próprios sistemas estão gerando resultados iniciais positivos. Nessas validações, o RabbitMQ sustentou com sucesso a carga deles, sugerindo que é uma escolha forte e viável para seu ambiente de produção.

Além do JMS: Sua Porta de Entrada para a Modernização

Aqui está o ponto mais importante: o Tanzu RabbitMQ não é apenas um substituto mais barato e moderno para seu broker legado. É um upgrade para toda a sua arquitetura.

O Tanzu RabbitMQ pode lidar de forma confiável com sua carga de trabalho JMS existente, oferecendo um caminho imediato para modernizar e reduzir custos. Mas isso é apenas o começo. A migração para o Tanzu RabbitMQ pode destravar um ecossistema muito mais amplo:

• Flexibilidade de Protocolo: Com as aplicações não mais presas apenas ao JMS, você pode obter suporte nativo para AMQP 0.9.1, AMQP 1.0, MQTT, STOMP e muito mais.
• Padrões de Dados Modernos: Você pode começar a usar recursos poderosos como Tanzu RabbitMQ Streams para event logs de alto throughput e "reproduzíveis" (replayable), indo além do simples RPC.
• Evolua sua Arquitetura: Aquela aplicação RPC legada pode começar a evoluir para algo mais moderno ou elaborado. Você pode introduzir novos microservices escritos em qualquer linguagem (não apenas Java) que consumam os mesmos dados, permitindo uma transição gradual e segura para uma verdadeira arquitetura event-driven (orientada a eventos).

Não deixe que sistemas legados ditem seu futuro. O Tanzu RabbitMQ oferece um caminho comprovado e de baixo risco para migrar até mesmo as aplicações JMS mais críticas, dando a você a confiabilidade de que precisa hoje e a flexibilidade que desejará amanhã.