Pular para o conteúdo

apps/scalability/blue-green-deployment

139 · Escalabilidade & Infraestrutura · ≈ 6 min de estudo

Blue-Green Deployment

Duas cópias completas do ambiente — azul e verde — atrás de um roteador que aponta para uma só. A versão nova sobe na cor ociosa, passa por smoke test e então recebe 100% do tráfego numa troca atômica do ponteiro; voltar atrás é a mesma troca no sentido inverso, em segundos. Use em releases grandes de serviços críticos, quando o rollback precisa ser imediato.

passos
6
arquivos
2
testes
0
tecnologias
3
Lógica puraTypeScriptBunElysia
Baixar cartão

Cenário

O motor de PIX do banco recebe uma versão nova. A 2.0.0-rc1 cobra tarifa onde não devia — o health check passa, mas a transação sintética do smoke test pega o erro e nenhum cliente é atingido. A 2.0.0 corrigida entra com um PIX ainda em processamento no azul, que termina lá mesmo. A 2.1.0 passa no smoke test mas falha em produção: o roteador percebe a taxa de erro e volta sozinho para a versão anterior.

Planta

Estados
5/5
AzulAtivoVerdeImplantadoVerdeAtivorequisicao em andamento termina no azultoda requisicao nova vai para o verdedeploy da versaonova na cor ociosasmoke test falhou,trafego intocadosmoke test ok,corte atomicorollback manual ouautomatico (erroacima de 5%)
5

5 passos — reproduza para seguir o fluxo

  • chamada
  • resposta ou assíncrono
  • falha
  • passo
  • toque num nó para focar
  • repouso ou sucesso
  • transição
  • falha ou recusa
  • Outras plantas de estados

Como funciona

6 passos

Troca instantânea entre dois ambientes.

Esconde cada passo: lembre antes de tocar para revelar.

  1. 01

    O roteador guarda um ponteiro para a cor ativa; POST /deploy registra a versão nova na cor ociosa, sem tráfego

  2. 02

    POST /cutover roda o smoke test na cor ociosa — /health e um PIX sintético com resposta conhecida (liquidado, tarifa zero) — e só então troca o ponteiro

  3. 03

    Cada requisição fixa a cor no início: a que estava em andamento termina no ambiente antigo, contada em inFlight até drenar

  4. 04

    POST /rollback é a mesma troca no sentido inverso

  5. 05

    Depois do corte, a versão nova é medida sozinha: com pelo menos 10 chamadas e taxa de erro acima de 5%, o roteador volta para a cor anterior

  6. 06

    A mudança da v2 é aditiva (endToEndId): as duas versões atendem os mesmos clientes durante a troca

Trade-offs

O que se ganha, o que se paga

4 vantagenscada ganho tem um preço4 custos

Vantagens

  • Rollback em segundos, sem redeploy

  • Smoke test antes de qualquer cliente

  • Sem downtime: requisições em andamento terminam

  • Rollback automático pela taxa de erro

Custos

  • Dois ambientes completos durante o deploy

  • Corte é tudo ou nada: sem observar com fração do tráfego

  • Schema do banco precisa servir as duas versões

  • Ambiente parado em standby dobra o custo se não for desligado

apps/scalability/blue-green-deployment

2 arquivos

src/

  • router_bluegreen.tsRoteador: ponteiro ativo, deploy na cor ociosa, smoke test, corte, rollback manual e automático
  • engine_pix.tsReleases do motor de PIX como serviços HTTP

Executar · só Bun

  1. bun install# dependências
  2. bun run demo# roda o cenário
  3. bun run test# testes unitários
Requisitos
Bun

Por que se relacionam

Teste rápido

Qual é o próximo passo depois de Blue-Green Deployment?

Próximo projeto · Escalabilidade & InfraestruturaCanary Deployment
Esc

↑ ↓ navegarEnter abrir191 resultados