Levantar só parte dos microsserviços

Atualizado: 22 de agosto de 2026

O teu sistema tem doze serviços e tu vais tocar em dois. A máquina aguenta doze —a custo— mas arrancá-los todos demora quatro minutos, come a memória e não acrescenta nada à mudança que estás a fazer. A pergunta não é se se pode recortar: é para onde chamam os que levantas.

O recorte não é o problema; o destino é

Levantar um subconjunto é trivial em qualquer ferramenta: escolhes dois e arrancas. O que ninguém resolve por ti é o que acontece quando um desses dois chama um terceiro que já não está.

Cada dependência que sai do recorte tem exatamente três destinos possíveis:

• Local — está de pé mesmo ao lado. É o caso fácil e também o que arrasta: se o levantas, arrastas a sua própria cauda de dependências.
• A nuvem — o vosso ambiente partilhado. Poupa-te levantá-lo, em troca de VPN, de dados que mudam debaixo dos teus pés, e de que se esse ambiente estiver em baixo, tu também.
• Um mock — perfeito quando a resposta dele não é o que estás a testar. Em troca de manter o stub.

A decisão é por dependência, não por ambiente. É aí que está a diferença em relação a quase tudo o resto: não queres «modo local» ou «modo nuvem», queres esta chamada para o serviço que tens aberto, aquela para a nuvem e uma terceira para um mock, e mudar de ideias a meio da tarde.

Porque é que um compose não distingue

docker compose up bff orders levanta dois serviços, sim. Mas dentro de um compose tudo é um contentor da mesma rede, e os URLs entre eles são nomes de serviço dessa rede. A configuração do bff diz http://payments:8081, e o payments agora não existe: obténs uma falha de resolução de nome.

A saída habitual é editar o URL à mão na configuração do bff —um repositório que muitas vezes não é teu—, lembrar-te de não o comitar, e desfazê-lo quando quiseres testar outra coisa. Multiplicado por serviços e por vezes ao dia, é daí que sai o LOCAL_SETUP.md de quarenta passos.

O que se parte ao recortar mal

Duas falhas, e a segunda é muito pior do que a primeira:

1. Falha ruidosamente. connection refused ou um nome que não resolve. Chato, mas honesto: dás por isso à primeira tentativa.
2. Funciona sem que ninguém o tenha decidido. A configuração trazia por omissão o URL do ambiente partilhado, por isso a chamada sai para a nuvem, responde, e tudo parece bem. Dás por isso no dia em que essa chamada escreve: uma migração, uma encomenda de teste, um email enviado a um cliente real a partir da tua máquina.

A segunda é o que justifica que isto mereça uma decisão explícita em vez de um valor por omissão. Um ambiente local que chega a produção por descuido não avisa.

E um caso que quase toda a gente faz mal

Se um serviço está mesmo levantado ao lado, a chamada devia ir para ele —mesmo que o ficheiro de configuração geral diga «nuvem»—. Parece óbvio e quase nenhuma ferramenta o faz: acabas com um serviço arrancado na tua máquina a quem o vizinho chama pela internet. Consome VPN, é mais lento, e no dia em que a VPN cai tens um cenário inteiro em local que não arranca por causa de um serviço que tinhas ao lado.

A regra correta: o que se levanta mesmo ao lado chama-se em local, e a configuração geral só decide sobre o que não está no cenário.

Como o Aseptic o resolve

Um cenário é exatamente isto: o subconjunto que queres levantar, com a decisão tomada para cada dependência que fica de fora.

• Escolhes o que entra. Dois de doze, ou os que forem, agrupados por fluxo —«Checkout», «Registo de cliente»— e guardados com nome, para não voltares a decidi-lo amanhã.
• Por cada dependência escolhes destino —local, nuvem ou mock— e o motor reescreve o URL ao arrancar, injetado como propriedade -D ou variável de ambiente. Os teus repositórios não se tocam.
• O que está no cenário chama-se em local, acima do que diga o manifesto: a decisão recente e específica ganha à geral.
• Se as declarações se contradizem, o arranque é cortado em vez de desempatar em silêncio. Duas verdades sobre a mesma dependência é o bug que acaba com o painel a dizer «nuvem» enquanto um serviço chama o vizinho local.
• O cenário partilha-se como ficheiro autocontido: quem chega de novo importa e arranca, sem ler o documento de ninguém.

Quanto é preciso levantar mesmo

A regra que funciona: só os serviços que vais mudar, mais aqueles cujo comportamento estás a verificar. Tudo o resto é um URL a apontar para outro sítio. Na prática, na maior parte das tardes isso são dois ou três serviços de um sistema de doze.

Se ao recortar descobrires que um dos dois não arranca, está porque um microsserviço não levanta em local; e se o que precisas é de substituir os que deixas de fora, mockar um serviço que não controlas. O panorama completo está em o que precisa um ambiente local de microsserviços.

← Voltar ao início