Estratégias de Deployment e Gerenciamento de Tráfego de APIs
Blue-Green, Canary, Rolling, Failover, Progressive Delivery e os controles de tráfego que tornam releases de APIs seguros
Guia prático de releases sem downtime, deslocamento controlado de tráfego e gateways resilientes
Por João Ricardo Dutra••Material integral
Resumo
Espera-se que modernas evoluam continuamente sem ficarem indisponíveis. Essa expectativa parece simples, mas muda toda a arquitetura da entrega de software. Um não é mais meramente o ato de substituir um binário por outro; é um movimento controlado de tráfego, risco, configuração, estado e exposição de usuários. Este artigo explica as principais estratégias de de e os padrões de usados para tornar esse movimento mais seguro: ,, Rolling, ,,, divisão ponderada de tráfego, feature ,, arquiteturas e ,, e mecanismos relacionados. O objetivo é oferecer a arquitetos, engenheiros de , profissionais de DevOps, SREs e times de plataforma um modelo mental que seja neutro em relação a fornecedores, mas concreto o bastante para ser aplicado a , balanceadores de carga, recursos de ingress e do Kubernetes, service meshes, plataformas de gerenciamento de em nuvem e reversos tradicionais.
Conteúdo
34.1 Introdução: das janelas de manutenção à entrega controlada de software
34.2 A base conceitual: ,, roteamento e
34.3 Estratégias centrais de
34.4 Padrões de usados por
34.5 Mecanismos de confiabilidade que tornam os deployments mais seguros
34.6 Como os padrões se relacionam entre si
34.7 Escolhendo a estratégia certa
34.8 Exemplo prático: um rollout controlado de
34.9 Erros comuns e armadilhas arquiteturais
34.10 Conclusão
Glossário e Referências
34.1 Introdução: das janelas de manutenção à entrega controlada de software
Durante boa parte da história do software, o era tratado como um evento. Uma equipe preparava um , anunciava uma janela de manutenção, parava um sistema, copiava novos arquivos ou instalava um novo pacote, reiniciava serviços e torcia para que a produção se comportasse como o ambiente de teste. Esse modelo era tolerável quando os releases eram pouco frequentes e as aplicações relativamente isoladas. Ele se tornou cada vez mais caro à medida que a web, as aplicações móveis, o internet banking, o comércio eletrônico, os serviços em nuvem e os ecossistemas orientados a tornaram o software continuamente disponível e profundamente interconectado.
A ascensão da Integração Contínua e da Entrega Contínua mudou a pergunta. Em vez de perguntar "Como tornamos seguro um grande a cada poucos meses?", as equipes de engenharia passaram a perguntar "Como tornamos pequenos releases rotineiros, observáveis, reversíveis e de baixo risco?". As estratégias de discutidas neste artigo nasceram dessa mudança. O formalizou a ideia de manter dois ambientes capazes de operar em produção e alternar o tráfego entre eles. Martin Fowler documentou o padrão em 2010 ao discutir entrega automatizada e as práticas emergentes que logo seriam associadas ao movimento de Continuous Delivery [1]. Os releases mais tarde se tornaram um método amplamente usado para expor apenas uma pequena população a uma nova versão antes da promoção ampla [2].
A metáfora por trás de "" é anterior ao software. Historicamente, mineradores usavam canários como mecanismo de alerta antecipado para gases perigosos: a ave era exposta antes da população humana maior. O software tomou emprestado o mesmo princípio de gestão de risco. Em vez de expor todos os clientes a um novo de uma só vez, uma pequena porcentagem se torna a primeira coorte. Se a telemetria mostrar erros, latência ou regressões de negócio, o rollout pode ser interrompido antes que o cresça.
À medida que a infraestrutura de nuvem, os , o Kubernetes, os service meshes, as feature e os sofisticados amadureceram, o se tornou ainda mais programável. Em 2018, o analista da RedMonk James Governor introduziu o termo "" após observar as práticas de experimentação progressiva da Microsoft. O termo ampliou a discussão para além da automação de : o software poderia ser implantado primeiro, liberado depois, exposto gradualmente e governado por telemetria, coortes de usuários, experimentação e controles automatizados de segurança [8].
Essa evolução importa para além da conveniência de engenharia. Um confiável reduz indisponibilidades em sistemas dos quais a sociedade depende cada vez mais: pagamentos, serviços governamentais, transporte, comunicação, plataformas de saúde, educação, logística e comércio. Quando um consegue deslocar 5% do tráfego para uma nova implementação, observar o resultado e reverter a mudança em segundos, o se torna uma forma de gestão de risco operacional. A tecnologia é invisível para a maioria dos usuários, mas seu valor social fica visível sempre que um serviço crítico permanece disponível durante a mudança.
Para o leitor, esses padrões fornecem um vocabulário para raciocinar sobre um dos problemas mais difíceis da engenharia de produção: como mudar um sistema enquanto ele está sendo usado. Ao final do artigo, e não parecerão mais buzzwords isoladas de DevOps. Eles se encaixarão em um modelo mais amplo que conecta , roteamento de ,,,,, feature , compatibilidade de versões e .
34.2 A base conceitual: ,, roteamento e
Antes de comparar estratégias, é útil separar quatro conceitos que costumam ser misturados.
: colocar uma versão de software ou configuração em um ambiente onde ela possa executar.
: tornar uma capacidade disponível para usuários ou consumidores. Uma funcionalidade pode estar implantada mas ainda não liberada.
: controlar quais requisições chegam a quais versões, regiões, ou .
: manter o serviço disponível quando componentes, regiões, redes ou novos releases falham.
Essas distinções explicam por que um é tão importante. O fica no caminho da requisição e pode atuar como um ponto de controle programável entre consumidores e . Dependendo da plataforma, ele pode rotear por porcentagem, , identidade, path, host, região, versão de , subscription ou saúde. Em outras palavras, o consegue transformar uma estratégia de em uma política de tráfego.
Figura 1 - Separar de é o que permite controlar a exposição de forma independente da mudança de infraestrutura.
34.2.1 O vocabulário de risco: ,, e
: o alcance de usuários, requisições, serviços ou regiões afetados se uma mudança falhar.
: retornar o tráfego ou o software a uma versão anterior reconhecidamente boa.
: corrigir a nova versão e implantar um corrigido em vez de voltar para o antigo.
: um período deliberado de observação após uma etapa do rollout, permitindo que métricas e falhas tardias apareçam.
: uma sonda ou sinal usado para determinar se uma instância ou deve receber tráfego.
: se um processo está pronto para servir tráfego de produção, o que nem sempre equivale a apenas estar vivo.
: um Service Level Objective, como uma meta de latência ou disponibilidade usada para julgar se o permanece aceitável.
: a quantidade de indisponibilidade tolerada antes que um seja violado; frequentemente usado para equilibrar velocidade de entrega e confiabilidade.
: a capacidade de inferir o comportamento do sistema a partir de sinais como métricas, ,, eventos e indicadores de negócio.
34.2.2 Tráfego é fácil; o estado torna tudo mais difícil
Diagramas de costumam mostrar uma requisição passando limpamente da versão v1 para a v2. Sistemas reais carregam estado. Sessões podem ser sticky. podem cachear respostas. podem referenciar escopos que mudaram. Bancos de dados podem migrar . Mensagens assíncronas podem permanecer em filas. Conexões de longa duração, como , podem continuar presas a um nó de antigo. A estratégia de deve, portanto, ser compatível com o modelo de estado da aplicação.
É por isso que a compatibilidade retroativa é um pré-requisito oculto para uma segura. Durante um rolling ou , duas versões frequentemente coexistem. Se a v2 grava uma representação de banco de dados que a v1 não consegue ler, um de 5% ainda pode corromper a experiência dos 95% de tráfego que permanecem na v1. Técnicas como migrações de banco expand-and-contract, tolerant readers, eventos versionados e mudanças aditivas de reduzem esse risco.
34.3 Estratégias centrais de
Tabela 1 - As seis estratégias centrais de , sua ideia central e o trade-off que cada uma aceita.
Estratégia
Ideia principal
Força principal
Principal trade-off
Dois ambientes capazes de operar em produção; o tráfego é comutado do ambiente atual para o novo.
Cutover e rápidos
Infraestrutura extra e sincronização de estado
Uma pequena porcentagem ou coorte recebe a nova versão primeiro; a exposição cresce progressivamente.
pequeno
Exige telemetria forte e controle de roteamento
Instâncias ou nós são substituídos gradualmente.
Uso eficiente da infraestrutura
Versões antiga e nova coexistem
/ Big Bang
A versão antiga é parada e a nova inicia em seguida.
Simplicidade operacional
Downtime e amplo
Anéis sucessivos de usuários ou ambientes recebem a mudança em etapas.
Exposição organizacional controlada
Desenho de coortes e coordenação
Um modelo mais amplo que combina exposição gradual, controle de funcionalidades, telemetria e automação.
Controle de risco granular
Mais maturidade de plataforma e processo
34.3.1
O mantém dois ambientes capazes de operar em produção, tão equivalentes quanto for prático. O ambiente "blue" representa a versão que atende o tráfego de produção no momento; o ambiente "green" contém a próxima versão. O time implanta e valida o novo no green e depois altera uma camada de roteamento - comumente um balanceador de carga, controle de , ingress, service mesh ou - para que o tráfego de produção passe para o green. A descrição de Fowler enfatiza o problema do cutover: ter dois ambientes transforma uma atualização in-place arriscada em uma decisão de roteamento [1].
Para , o padrão é especialmente atraente quando o próprio de precisa ser atualizado. Uma nova frota de pode ser construída com as mesmas definições de , políticas, certificados, trust stores, integrações de identidade, plugins e rotas de rede. Depois de testes sintéticos e validação semelhante à produção, o balanceador de carga externo envia tráfego para a frota green. Se o novo se comportar de forma incorreta, a organização pode redirecionar o tráfego para o blue enquanto o ambiente original ainda está intacto.
Antes do cutover
Clientes -> Load Balancer -> Cluster de Gateway BLUE -> Backends de API
Cluster de Gateway GREEN (validado, sem tráfego de produção)
Depois do cutover
Clientes -> Load Balancer -> Cluster de Gateway GREEN -> Backends de API
Cluster de Gateway BLUE (mantido temporariamente para rollback)
Figura 2 - Dois ambientes capazes de operar em produção transformam uma atualização in-place arriscada em uma decisão de roteamento reversível.
Melhor uso: upgrades de de alto risco, substituição de infraestrutura, migrações de configuração e mudanças em que o imediato é valioso.
Fique atento a: compatibilidade de banco de dados, afinidade de sessão, , diferenças de certificados, drift de ambiente e o custo de manter capacidade duplicada temporariamente.
34.3.2
Um expõe um novo a uma fatia deliberadamente limitada de tráfego real de produção. A coorte inicial pode ser 1%, 5%, 10%, um grupo interno de usuários, uma região, um tenant ou um grupo de consumidores de . Se as métricas técnicas e de negócio permanecerem saudáveis, a fatia aumenta. Fowler descreveu o padrão como colocar a nova versão em parte da infraestrutura e rotear um subconjunto de usuários para ela antes do amplo [2]. de nuvem modernos frequentemente tornam a ideia explícita: o Amazon , por exemplo, oferece configurações de que desviam uma porcentagem configurável do tráfego do stage para um [6].
O poder do não é a porcentagem em si. É o ciclo de feedback. Um útil compara taxa de erro, latência p95/p99, , saturação, falhas de autorização, erros de dependências e resultados de negócio entre baseline e candidato. Plataformas maduras conseguem automatizar essa comparação e interromper ou reverter o rollout quando os limiares são excedidos.
Figura 3 - O valor de um é o ciclo de feedback, não a porcentagem: baseline e candidato precisam ser medidos separadamente.
Melhor uso: mudanças cujo comportamento pode ser avaliado com segurança em uma pequena coorte de produção e nas quais o tráfego real fornece evidência valiosa.
Fique atento a: de baixo volume que não geram dados suficientes, operações não idempotentes, contaminação de coortes, acoplamento oculto de estado e métricas que agregam a versão antiga e a nova.
34.3.3 Rolling
Um atualiza instâncias de forma incremental em vez de criar um ambiente paralelo completo. Se um tem seis nós, um ou dois podem ser retirados de serviço, atualizados, verificados por e devolvidos antes que os próximos nós sejam substituídos. O Kubernetes usa esse modelo para Deployments, substituindo gradualmente Pods antigos por novos enquanto mantém a aplicação disponível [4].
Rolling updates são eficientes em infraestrutura e frequentemente a estratégia padrão das plataformas de . O trade-off é a coexistência: durante o rollout, v1 e v2 servem tráfego ao mesmo tempo. Isso exige compatibilidade de protocolo, evolução segura do banco de dados, comportamento cuidadoso de e tratamento previsível de sessões. Um também pode ser mais lento que no , porque a frota precisa ser revertida nó a nó.
Figura 4 - Rolling updates trocam infraestrutura duplicada por uma janela de coexistência na qual ambas as versões precisam permanecer compatíveis.
Melhor uso: serviços , escalados horizontalmente e releases rotineiros em que ambientes duplicados seriam desnecessariamente caros.
Fique atento a: comportamento com versões misturadas, conexões de longa duração, skew de configuração, escolhas de maxUnavailable/maxSurge e se os checks realmente representam prontidão para produção.
34.3.4 / Big Bang
é conceitualmente a estratégia mais simples: parar a versão antiga, substituí-la e então iniciar a nova versão. Janelas de manutenção tradicionais são essencialmente deployments . O modelo ainda é apropriado para alguns sistemas internos, ambientes de desenvolvimento, cargas de trabalho em batch ou aplicações em que executar duas versões é tecnicamente impossível.
Sua fraqueza é o tamanho do compromisso. Como não há sobreposição, a disponibilidade é sacrificada durante a transição. Como todo usuário vê a nova versão imediatamente, o é máximo. Para uma pública ou um de pagamentos, isso raramente é desejável, a menos que uma janela de manutenção seja aceitável e explicitamente prevista no contrato do serviço.
34.3.5
O organiza a exposição do em grupos sucessivos, em vez de apenas porcentagens. Uma sequência comum pode ser: usuários de engenharia, funcionários internos, parceiros selecionados, um segmento de clientes de baixo risco, uma região, várias regiões e, finalmente, a população global. O conceito está fortemente associado a serviços de software de grande escala porque coortes de usuários fornecem uma fronteira de segurança mais rica do que tráfego aleatório sozinho.
Para , os anéis podem ser mapeados para , IDs , tenants, subscriptions, regiões, produtos ou grupos contratuais de parceiros. Um consegue reconhecer o consumidor e roteá-lo para um candidato. Isso torna o valioso quando "quem" recebe o importa mais do que "qual porcentagem" o recebe.
34.3.6
é o conceito guarda-chuva que conecta várias práticas deste artigo. Ele estende a Entrega Contínua ao controlar não apenas se o software pode ser implantado, mas como a exposição se expande após o . A abordagem ganhou nome em 2018, quando James Governor descreveu "" a partir do modelo de experimentação progressiva da Microsoft [8]. Na prática moderna, ela normalmente combina rollout em etapas, feature ,, experimentação, análise automatizada e clareza sobre quem decide o .
Uma de suas ideias mais importantes é a separação entre e . O código pode chegar à infraestrutura de produção enquanto uma funcionalidade permanece desabilitada. Uma pode então expô-la a funcionários, depois a 1% dos clientes, depois a 10%, depois a 50% e finalmente a todos. Isso reduz a pressão organizacional para transformar cada em produção em um "momento de lançamento" irreversível.
34.4 Padrões de usados por
As estratégias de descrevem como as versões são introduzidas. Os padrões de descrevem como as requisições são direcionadas enquanto essas versões coexistem. Na arquitetura de , as duas camadas são inseparáveis.
34.4.1 Divisão ponderada de tráfego
O envia uma fatia definida de requisições para cada . Um pode rotear 95% para a v1 e 5% para a v2, depois mudar os pesos para 80/20, 50/50 e finalmente 0/100. A do Kubernetes documenta exatamente esse estilo de divisão gradual entre duas versões de serviço [5]. Os pools do também suportam atributos de peso e prioridade para distribuir requisições entre [7].
O roteamento por porcentagem nem sempre é a escolha mais segura. podem rotear de forma determinística usando da requisição. Um grupo interno de testes pode enviar X--Ring: beta. Uma aplicação parceira pode ser identificada pelo client_id . Uma plataforma multi-tenant pode expor a v2 apenas a tenants selecionados. Isso cria coortes estáveis, o que facilita a depuração porque o mesmo consumidor alcança consistentemente o mesmo .
Sinais típicos de roteamento incluem:
e
de e identificadores de cliente
, produtos ou subscriptions
hostnames e paths de
geografia ou região
dispositivo ou versão da aplicação
rede de origem ou identidade interna
34.4.3
O pode usar a mesma maquinaria de roteamento do , mas o objetivo é diferente. O pergunta principalmente se um é seguro. O pergunta qual variante produz um resultado melhor. Um pode rotear coortes comparáveis para dois algoritmos de recomendação, fluxos de checkout, serviços de precificação ou formatos de resposta enquanto a analítica compara conversão, engajamento, latência ou outra métrica de negócio. Como a experimentação de negócio e a experimentação de confiabilidade podem parecer semelhantes na infraestrutura, as equipes devem ser explícitas sobre o propósito da divisão.
34.4.4 / espelhamento de tráfego
O duplica requisições de produção para um sistema candidato enquanto a resposta devolvida ao usuário ainda vem da versão estabelecida. Isso é poderoso para validar um novo , runtime, motor de busca, modelo de fraude ou implementação de contra tráfego realista sem deixar que o candidato afete as respostas visíveis ao usuário.
Cliente -> API Gateway -> backend v1 -> resposta devolvida ao cliente
\--> cópia da requisição -> backend shadow v2 -> resposta ignorada/comparada
Figura 5 - O espelhamento valida um candidato contra tráfego real, mas caminhos de escrita duplicados precisam ser isolados ou neutralizados.
O espelhamento exige cuidado com efeitos colaterais. Uma requisição /payments duplicada não pode criar um segundo pagamento real. Ambientes shadow frequentemente precisam de transformação de requisição, dependências isoladas, caminhos de escrita desabilitados, contas sintéticas ou controles de idempotência.
34.4.5 e feature
Um coloca código ou infraestrutura em produção antes que a capacidade esteja amplamente visível. Feature são um mecanismo comum de controle. O código pode já estar implantado, mas a funcionalidade permanece desabilitada ou habilitada apenas para uma coorte aprovada. Em plataformas de , as podem existir dentro da aplicação, na camada de policies do ou em um serviço dedicado de gerenciamento de funcionalidades.
Essa separação entre "implantar" e "liberar" é uma das mais fortes melhorias de segurança na entrega moderna. Ela permite que times de plataforma validem a infraestrutura separadamente dos times de produto que decidem quando os usuários devem ver uma funcionalidade.
34.4.6 Versionamento de como ferramenta de
O versionamento é frequentemente discutido como tema de design de , mas também é um mecanismo de roteamento de . Um pode manter /v1/orders mapeado para o existente enquanto /v2/orders roteia para uma nova implementação. A seleção de versão também pode ocorrer por media types, , hostnames ou configuração do consumidor. Isso permite que a migração avance em um cronograma consumidor a consumidor, em vez de forçar todos os clientes a atualizar simultaneamente.
34.5 Mecanismos de confiabilidade que tornam os deployments mais seguros
34.5.1 , e remoção automática
Uma estratégia de é tão confiável quanto seus sinais de saúde. Um processo pode estar "vivo" e ainda assim ser incapaz de servir tráfego útil. Os checks devem, portanto, validar as dependências que determinam se a instância pode receber requisições com segurança. e balanceadores de carga usam esses sinais para evitar rotear tráfego para nós que estão iniciando, drenando, não saudáveis ou desconectados de dependências críticas.
34.5.2 e shutdown gracioso
Quando um nó de é removido durante um , ele normalmente deve parar de aceitar novo tráfego antes de ser encerrado. Sessões existentes, requisições de , ou transações em andamento precisam de tempo para concluir. Esse período é comumente chamado de , deregistration delay ou graceful shutdown. Sem ele, um rollout tecnicamente "sem downtime" ainda pode gerar resets de conexão evitáveis.
34.5.3 Circuit breakers, e pools
O roteamento de tráfego e o tratamento de falhas se encontram no pool. Se um novo começa a falhar, um pode precisar parar de rotear para ele, tentar outra instância ou abrir um para impedir chamadas repetidas a uma dependência não saudável. Plataformas de gerenciamento de em nuvem cada vez mais expõem esses controles como policies explícitas de . O , por exemplo, documenta pools e configuração de como parte do gerenciamento de [7].
Os precisam ser desenhados com cuidado. Repetir um idempotente costuma ser mais seguro do que reexecutar um de criação de pagamento. O precisa de uma estratégia de idempotência, orçamento de , hierarquia de e consciência sobre se a operação pode ser repetida com segurança.
34.5.4 e
Esses padrões descrevem topologia de disponibilidade em vez de estratégia de , mas estão intimamente relacionados ao . Na arquitetura , múltiplas regiões ou de servem tráfego de produção simultaneamente. Na arquitetura , um ambiente secundário permanece pronto mas recebe pouco ou nenhum tráfego normal. A segunda reduz a complexidade simultânea; a primeira pode melhorar o uso de capacidade e a regional, mas exige consistência e desenho de roteamento mais fortes.
Figura 6 - A topologia de disponibilidade decide o que o realmente consegue fazer: um standby que nunca serve tráfego raramente está comprovado.
34.5.5
é o redirecionamento controlado de tráfego após uma falha. Pode ocorrer entre nós, zonas de disponibilidade, regiões, data centers ou versões de . Os mecanismos incluem balanceadores de carga globais, de ,, ingress controllers e service meshes. Um plano de deve especificar tempo de detecção, autoridade de decisão, deslocamento de tráfego, recuperação de estado e como a organização fará o fail back após o incidente.
34.5.6 versus
O é atraente porque parece restaurar um estado conhecido. No entanto, escritas em banco de dados, mudanças de , mensagens e efeitos colaterais externos podem tornar uma reversão verdadeira impossível. O - implantar uma versão corrigida - pode ser mais seguro quando os dados de produção já evoluíram. de entrega maduros, portanto, definem os dois caminhos com antecedência em vez de supor que o é sempre trivial.
34.6 Como os padrões se relacionam entre si
Muitas discussões sobre estratégias de surgem de tratar os padrões como mutuamente exclusivos. Na prática, as organizações os combinam. Um ambiente pode usar deslocamento de tráfego antes da troca final. Um pode ser governado por . Um pode usar feature . Regiões podem rodar cada uma seu próprio de forma independente. A pergunta útil não é "Qual padrão único estamos usando?", e sim "Quais mecanismos controlam substituição de infraestrutura, exposição de usuários, roteamento de tráfego e recuperação de falhas?".
Tabela 2 - Os padrões não são rivais; cada um responde a uma pergunta diferente sobre mudança controlada.
Pergunta sendo resolvida
Padrões relevantes
Substituição de infraestrutura
, Rolling,
Controle de exposição
,, Feature ,
Direcionamento de requisições
, roteamento por , roteamento por identidade, versionamento de
Validação
,, análise automatizada de ,
Contenção de falhas
,,,
Topologia de disponibilidade
,
Modelo operacional
Continuous Delivery,
34.7 Escolhendo a estratégia certa
Não existe um padrão de universalmente melhor. A escolha correta decorre de risco, reversibilidade, estado, custo, volume de tráfego e da capacidade da organização de observar o resultado.
Quão caro é o downtime?: Se o downtime é inaceitável, o se torna menos atraente e as estratégias sem downtime se tornam importantes.
Com que rapidez o precisa acontecer?: O pode oferecer reversão de tráfego muito rápida quando o ambiente antigo permanece intacto.
Duas versões podem coexistir com segurança?: e Rolling exigem compatibilidade entre versões, dados compartilhados e dependências.
Você tem tráfego suficiente para confiança estatística?: Uma de baixo volume pode não revelar regressões rapidamente durante um de 1%.
O tráfego pode ser segmentado de forma determinística?: Se os consumidores podem ser identificados por tenant, ou de , um rollout baseado em anéis pode ser mais seguro do que porcentagens aleatórias.
A infraestrutura duplicada é viável financeiramente?: O pode dobrar temporariamente a capacidade de computação ou de .
Quão madura é a ?: Estratégias progressivas sem telemetria confiável podem criar falsa confiança.
As operações são idempotentes?: , espelhamento e podem ser perigosos para operações de escrita sem controles de idempotência.
Qual é o modelo de migração do banco de dados?: A compatibilidade de frequentemente determina se o é de fato possível.
34.7.1 Um guia prático de decisão
Tabela 3 - Um ponto de partida, não uma regra: o cenário determina qual mecanismo carrega o risco.
Cenário
Ponto de partida provável
Upgrade de plataforma de com requisito estrito de
frequente de microserviço
Mudança de comportamento de de alto risco com telemetria forte
+
para funcionários, depois parceiros, depois clientes
Novo que precisa ser testado com tráfego real mas não pode afetar usuários
Recuperação de desastres multirregional
ou +
Pequeno serviço interno em que a manutenção é aceitável
pode ser suficiente
34.8 Exemplo prático: um rollout controlado de
Considere uma de pagamentos exposta por meio de um . A versão v1 é estável. A versão v2 introduz uma nova integração de fraud scoring e um caminho de autorização refatorado. O time não quer expor todas as transações à v2 imediatamente.
Passo 1 - Implantar sem exposição ampla
Implante payments-v2 ao lado de payments-v1. Mantenha a v1 como padrão. Valide inicialização, certificados, validação /, conectividade , e transações sintéticas.
Passo 2 - Criar um pequeno
Roteie 5% do tráfego elegível para a v2. Mantenha clientes de alto risco ou não suportados fixados na v1 se necessário.
Passo 3 - Observar sinais técnicos e de negócio
Compare 5xx, falhas de autenticação, taxa de , latência p95, falhas de dependências, latência do serviço de fraude, taxa de aprovação de pagamentos e reconciliação de transações.
Passo 4 - Bake
Mantenha o de 5% tempo suficiente para observar jobs periódicos, efeitos de , dependências externas e falhas tardias.
Passo 5 - Promover gradualmente
Vá para 20%, 50% e 100% se o candidato permanecer dentro dos limiares acordados.
Passo 6 - Parar ou reverter em caso de regressão
Se a taxa de erro ou os resultados de negócio degradarem, defina o peso da v2 como 0 e investigue. O ponto central é que a política de roteamento contém o .
Figura 7 - A promoção é uma mudança de política, não um novo : cada passo é uma decisão informada por telemetria.
34.8.1 Exemplo com da do Kubernetes
O exemplo simplificado a seguir demonstra a ideia usando um HTTPRoute com duas referências de . A suporta divisão ponderada de tráfego entre versões de serviço [5].
A promoção se torna uma mudança de política em vez de um novo . Os pesos podem ir de 95/5 para 80/20, depois 50/50 e finalmente 0/100. Um padrão equivalente pode ser implementado em muitos , service meshes, ingress controllers e produtos de balanceamento de carga em nuvem, embora sintaxe e capacidades variem.
34.8.2 O que o exemplo ensina
A lição mais importante é que e exposição são decisões separadas. A versão v2 pode existir na infraestrutura de produção antes de receber tráfego significativo. O se torna uma válvula de . A determina se a válvula abre mais. Essa é a essência da aplicada a .
34.9 Erros comuns e armadilhas arquiteturais
Chamar qualquer arranjo de dois servidores de "": trata de dois ambientes capazes de operar em produção e de um cutover controlado, não simplesmente de ter redundância.
Usar sem métricas por versão: Se a telemetria mistura v1 e v2, o pode falhar enquanto os agregados continuam parecendo saudáveis.
Supor que saúde significa prontidão: Um processo que devolve 200 em /health ainda pode ser incapaz de alcançar provedores de identidade, bancos de dados ou críticos.
Ignorar a compatibilidade do banco de dados: O banco frequentemente torna o difícil. Trate a migração de como parte do desenho do .
Espelhar escritas inseguras: O pode duplicar efeitos colaterais a menos que o candidato esteja isolado ou as requisições sejam transformadas.
Repetir operações não idempotentes cegamente: Uma política de pode transformar um transitório em transações de negócio duplicadas.
Deixar o ambiente antigo para sempre: Ambientes devem ter uma política explícita de retenção e desativação; caso contrário, a "capacidade temporária de " vira custo permanente e drift.
Escolher porcentagens sem tráfego suficiente: Um de 1% em uma de baixo volume pode não exercitar os modos de falha que importam.
Tratar a estratégia de como substituta dos testes: O rollout progressivo reduz a exposição; ele não elimina a necessidade de testes funcionais, de integração, de segurança, de desempenho e de .
Ignorar configuração e certificados: Incidentes de frequentemente vêm de mudanças em policies, rotas, trust stores, certificados, segredos ou configuração de identidade, e não do código da aplicação.
34.10 Conclusão
,,,, e são respostas diferentes para a mesma pergunta operacional: como um sistema pode mudar enquanto os usuários continuam dependendo dele? O reduz o risco do cutover mantendo um ambiente alternativo pronto. O limita o inicial. O troca infraestrutura duplicada por substituição controlada instância a instância. O adiciona coortes deliberadas de usuários. A transforma todos esses mecanismos em um modelo operacional mais amplo, guiado por exposição controlada e feedback.
Para , o é frequentemente onde essas ideias se tornam reais. O pode implementar um . O roteamento baseado em identidade pode criar anéis de . O roteamento por versão pode sustentar migrações longas. O espelhamento de tráfego pode validar um candidato. Saúde de , circuit breakers, e podem impedir que problemas de se tornem indisponibilidades em todo o serviço. O , portanto, não é meramente um componente de segurança ou de protocolo; ele pode ser parte do control plane de entrega de software.
As organizações mais fortes não escolhem um padrão da moda e o aplicam em todo lugar. Elas desenham a segurança do em torno dos modos de falha específicos de cada : estado, efeitos colaterais, compatibilidade de clientes, volume de tráfego, criticidade de negócio, e restrições de . Nesse sentido, a estratégia de é arquitetura. Ela determina não apenas como o código chega à produção, mas quanta incerteza o sistema consegue absorver enquanto está mudando.
Minha visão é que a é o enquadramento mais útil para plataformas de modernas porque trata o como uma decisão contínua em vez de uma única chave. ,, Rolling, feature , divisão de tráfego e se tornam ferramentas dentro desse modelo. O objetivo prático não é "risco zero" - que não existe -, e sim menores, detecção mais rápida, exposição controlada e recuperação mais rápida. Essa combinação é o que transforma a mudança frequente de uma ameaça à disponibilidade em uma capacidade rotineira de engenharia.
Principais conclusões
otimiza cutover e .
otimiza o controle do .
otimiza a eficiência da infraestrutura.
otimiza a exposição baseada em coortes.
combina controle de exposição com telemetria e automação.
tornam essas estratégias acionáveis por meio de controles de roteamento, saúde e policies.
Glossário
Tabela 4 - Vocabulário essencial do capítulo.
Termo
Definição
Topologia de disponibilidade em que múltiplas regiões ou de servem tráfego de produção simultaneamente.
Topologia de disponibilidade em que um ambiente secundário permanece pronto mas recebe pouco ou nenhum tráfego normal.
Período deliberado de observação após uma etapa do rollout, permitindo que métricas e falhas tardias apareçam.
O alcance de usuários, requisições, serviços ou regiões afetados se uma mudança falhar.
Dois ambientes capazes de operar em produção nos quais o tráfego é comutado do ambiente atual para o novo.
exposto primeiro a uma pequena porcentagem ou coorte, com exposição crescendo progressivamente.
Controle que interrompe chamadas repetidas a uma dependência não saudável após um limiar de falhas.
Período em que um nó para de aceitar novo tráfego mas deixa as requisições em andamento concluírem antes do encerramento.
Colocar código ou infraestrutura em produção antes que a capacidade esteja amplamente visível.
Colocar uma versão de software ou configuração em um ambiente onde ela possa executar.
A quantidade de indisponibilidade tolerada antes que um seja violado.
Redirecionamento controlado de tráfego após uma falha, entre nós, zonas, regiões ou versões de .
Mecanismo de controle que mantém uma funcionalidade implantada desabilitada ou habilitada apenas para uma coorte aprovada.
Controlar quais requisições chegam a quais versões, regiões, ou .
Sonda ou sinal usado para determinar se uma instância ou deve receber tráfego.
Capacidade de inferir o comportamento do sistema a partir de métricas, ,, eventos e indicadores de negócio.
Modelo operacional que controla como a exposição se expande após o , combinando rollout em etapas, , telemetria e automação.
Se um processo está pronto para servir tráfego de produção, o que nem sempre equivale a apenas estar vivo.
Estratégia em que a versão antiga é parada e a nova inicia em seguida.
Tornar uma capacidade disponível para usuários ou consumidores; uma funcionalidade pode estar implantada mas ainda não liberada.
Manter o serviço disponível quando componentes, regiões, redes ou novos releases falham.
Anéis sucessivos de usuários ou ambientes recebendo a mudança em etapas.
Corrigir a nova versão e implantar um corrigido em vez de voltar para o antigo.
Retornar o tráfego ou o software a uma versão anterior reconhecidamente boa.
Estratégia em que instâncias ou nós são substituídos gradualmente.
Enviar uma fatia definida de requisições para cada , como 95% para a v1 e 5% para a v2.
Duplicar requisições de produção para um sistema candidato enquanto o usuário ainda recebe a resposta da versão estabelecida.
Um Service Level Objective, como uma meta de latência ou disponibilidade usada para julgar se o permanece aceitável.
Divisão cujo objetivo é descobrir qual variante produz um resultado de negócio melhor, e não se um é seguro.
, service meshes, ingress controllers e plataformas de entrega em nuvem evoluem continuamente. Antes de aplicar qualquer exemplo, confirme a versão do recurso, as capacidades da sua implementação e o estado atual de estabilidade de cada funcionalidade na documentação do fornecedor.
