Pular para o conteúdo
thiagoetipadrões

Contatos

apps/scalability/service-discovery

137 · Escalabilidade & Infraestrutura · ≈ 6 min de estudo

Service Discovery

As instâncias de um serviço se registram sozinhas num catálogo ao subir, provam que estão vivas por heartbeat e saem ao parar; os clientes consultam o catálogo em vez de guardar endereços. Use quando instâncias sobem e descem o tempo todo — auto-scaling, deploy rolante, containers — e nenhum IP pode ser fixado em configuração.

passos
6
arquivos
3
testes
0
tecnologias
5
Infraestrutura realTypeScriptBunElysiaConsulDocker
CenárioRelaçõesComparar
Baixar cartão

Cenário

As instâncias do processador de PIX mudam de endereço a cada deploy e escalonamento. Uma instância em manutenção sai do catálogo antes de parar; outra que trava some sozinha quando o heartbeat para. Uma versão nova entra ao lado das antigas e pode ser escolhida pelos metadados. Se o Consul ficar fora, os clientes continuam com a última lista que conhecem.

Planta

Sequência
7/7
loop[a cada 1s]register com check TTL 3s1check pass (heartbeat)2GET /health/service?passing&index=N&wait=5s3bloqueia ate o catalogo mudar4deregister (SIGTERM)5nova lista na hora6crash: sem heartbeat, TTL expira e o Consul tira a instanciaPOST /pix (endereco vindo do cache)7Instancia pix-NConsulCliente (cache local)
7

7 passos — reproduza para seguir o fluxo

Como funciona

6 passos

Registro encontra instâncias vivas.

Esconde cada passo: lembre antes de tocar para revelar.

Vocabulário compartilhado

ErrorNoInstance+1
  1. 01

    instancePixStart sobe a instância, registra no Consul com endereço, porta, metadados (versão, região) e check TTL, e manda o primeiro heartbeat para ficar descobrível

  2. 02

    O heartbeat renova o check; heartbeat × 3 ≤ TTL é exigido, para jitter de rede não derrubar instância viva

  3. 03

    Parada graciosa desregistra antes de encerrar; crash deixa o TTL expirar pelo relógio do Consul, nunca do cliente

  4. 04

    O cliente guarda a lista num cache local e a mantém com blocking query (index + wait): nenhuma requisição consulta o registry, e a mudança chega assim que acontece

  5. 05

    pick faz round-robin no cache e pode filtrar por metadados; sem instância compatível, ErrorNoInstance

  6. 06

    Falha ao atualizar mantém a lista anterior: o cliente sobrevive à queda do registry

Trade-offs

O que se ganha, o que se paga

4 vantagenscada ganho tem um preço4 custos

Vantagens

  • Nenhum endereço fixo em configuração

  • Parada graciosa sai do catálogo na hora

  • Cache local mantém o tráfego se o registry cair

  • Metadados permitem escolher versão e região

Custos

  • Registry vira dependência crítica: precisa de cluster em produção

  • Crash só sai depois do TTL

  • Cache pode apontar para instância que morreu no intervalo

  • Cliente precisa conhecer o registry (discovery client-side)

apps/scalability/service-discovery

3 arquivos

src/

  • instance_pix.tsInstância com autorregistro, heartbeat, desregistro e crash
  • client_discovery.tsCliente com cache local, watch por blocking query e seleção por metadados
  • registry_consul.tsChamadas à API HTTP do Consul

Executar · com Docker

  1. ./docker.sh up# sobe Consul
  2. bun install# dependências
  3. bun run demo# roda o cenário
  4. bun run test# integração contra o serviço real
Requisitos
BunDocker
Sobe junto
Consul

Relações

Onde ele se encaixa

Mapa
  1. Service Discovery
  • Combina com3

Por que se relacionam

Combina com

Teste rápido

Qual destes combina com Service Discovery?

Próximo projeto · Escalabilidade & InfraestruturaAuto-Scaling
Esc

↑ ↓ navegarEnter abrir191 resultados