PT
RU
EN
ES
ZH
FR
DE
AR
HI
Deployments Canary com Java: como lançar novas versões sem risco para a produção
\n\nImagine: você é o capitão de um submarino. Precisa testar um novo sonar, mas não pode simplesmente ligá-lo na potência máxima — de repente, ele cega toda a tripulação ou, pior, dá um falso alarme. O que você faz? Solta um canário (o passarinho que, antigamente, alertava os mineiros sobre vazamento de gás). Se o passarinho está vivo — o sistema está ok.
\n\nNo mundo do desenvolvimento Java, esse princípio se chama canary deployments (implantação canário). É uma estratégia onde a nova versão da aplicação é enviada primeiro para uma pequena porcentagem de usuários (geralmente 1–5%). Se tudo estiver bem — o tráfego aumenta gradualmente. Se não — revertemos sem catástrofe.
\n\nNeste artigo, vamos analisar como implementar canary deployments em Java com exemplos reais: desde configurações simples até técnicas avançadas com Kubernetes e Spring Cloud. Vamos nessa!
\n\nPor que canary, e não blue-green ou rolling update?
\n\nVamos comparar rapidamente três estratégias populares de implantação:
\n\n- \n
- Blue-Green: você tem dois ambientes idênticos (azul e verde). Você muda todo o tráfego de uma vez. Rápido, mas se um bug aparecer — todos serão afetados. \n
- Rolling update: você atualiza pods/servidores um por um. Mais lento, mas também em massa. \n
- Canary: você envia a nova versão apenas para 2% dos usuários. Se eles não reclamarem — expande para 10%, depois 50%, depois 100%. \n
Canary é a única estratégia que permite testar A/B a nova versão em usuários reais sem risco para todos. Isso é especialmente crítico para microsserviços Java, onde um único erro pode causar uma falha em cascata.
\n\nComo funciona em Java? Arquitetura técnica
\n\nVamos imaginar um sistema Java típico: uma aplicação Spring Boot que atende a uma API REST. Para implementar o canary, precisamos de:
\n\n- \n
- Roteamento de tráfego: parte das requisições direcionadas para a nova versão (v2), o restante para a antiga (v1). \n
- Métricas e monitoramento: coletar erros, latências, número de requisições. \n
- Reversão automática: se a porcentagem de erros exceder o limite — revertemos o canary. \n
- Aumento gradual: se tudo estiver ok — aumentamos o peso do canary. \n
A maneira mais simples de fazer isso é usar Kubernetes com Service Mesh (por exemplo, Istio) ou Spring Cloud Gateway com pesos de roteamento. Abaixo — exemplos para ambas as abordagens.
\n\nExemplo 1: Canary com Spring Cloud Gateway (sem Kubernetes)
\n\nSe você não tem Kubernetes, mas tem Spring Cloud, pode usar o Spring Cloud Gateway com configuração de pesos. Veja como fica:
\n\n// application.yml\nspring:\n cloud:\n gateway:\n routes:\n - id: my-app-canary\n uri: http://my-app-v2:8080\n predicates:\n - Weight=my-app, 10 # 10% do tráfego\n filters:\n - SetPath=/api/v2/**\n - id: my-app-stable\n uri: http://my-app-v1:8080\n predicates:\n - Weight=my-app, 90 # 90% do tráfego\n filters:\n - SetPath=/api/v1/**\nAqui usamos o predicado Weight — um recurso embutido do Spring Cloud Gateway. Ele distribui aleatoriamente as requisições na proporção 10/90. Se a v2 funcionar de forma estável, mudamos o peso para 50/50, depois para 100/0.
Prós: simples, não requer ferramentas externas.
\nContras: sem automação — os pesos são alterados manualmente ou via API.
Exemplo 2: Canary com Kubernetes e Istio (avançado)
\n\nEste é o padrão ouro para microsserviços Java. Usamos o Istio VirtualService
Blogs
Book Recommendations
Leia também
Algoritmos e estruturas de dados em Kotlin: guia prático
