Entendendo na Prática: o que e Service Discovery

O que e Service Discovery

Service Discovery e o mecanismo que permite microservicos se localizarem dinamicamente.

Em sistemas distribuídos com microservicos, o endereco de uma instância de serviço muda constantemente: containers reiniciam, instâncias escalam horizontalmente, pods mudam de IP a cada deploy. Configurar IPs fixos nos clientes seria insustentável. Service Discovery resolve isso com um mecanismo dinâmico: cada instância se registra em um catálogo central ao iniciar e remove seu registro ao parar. Clientes consultam esse catálogo para descobrir onde o serviço esta rodando no momento. Isso torna o sistema resiliente a mudancas de infraestrutura. Ferramentas como Consul, Eureka e o próprio Kubernetes implementam esse mecanismo de formas diferentes, mas com o mesmo objetivo: permitir que serviços se encontrem sem configuração estatica de IPs.

Por que e necessário em microservicos

Em ambientes dinâmicos com escalonamento automático, IPs fixos são inviáveis.

Em um ambiente estatico com poucos servidores e IPs fixos, configurar enderecos manualmente funciona. Mas em microservicos modernos rodando em Kubernetes ou ECS, o cenário e completamente diferente: um serviço pode ter 1 instância em horário de baixo uso e 20 durante o pico. Cada instância tem um IP diferente. Quando uma instância reinicia, ganha um novo IP. Quando um pod e recriado, o IP muda. Sem Service Discovery, o cliente precisária conhecer o IP de cada instância, o que e impossível de gerenciar. Com Service Discovery, o cliente apenas pergunta onde esta o serviço de Pagamentos e recebe um IP valido de uma instância saudável no momento da chamada.

Client-side vs Server-side Discovery

A diferença esta em quem consulta o registro e decide qual instância usar.

No Client-side Discovery, o próprio cliente consulta o Service Registry, obtem a lista de instâncias disponíveis e decide qual usar, geralmente com um algoritmo de load balancing como round-robin. A lógica de discovery fica no cliente. Exemplos: Netflix Ribbon com Eureka. No Server-side Discovery, o cliente faz a chamada para um intermediário, como um load balancer ou API Gateway, que consulta o registry e roteia a requisição para uma instância. O cliente não precisa saber nada sobre o registry. Exemplos: AWS ALB com ECS, Kubernetes Service. O Client-side e mais flexível mas acoplado ao registry. O Server-side e mais simples para os clientes mas adiciona um hop de rede.

Como o Kubernetes resolve o problema

O Kubernetes usa DNS interno para resolver nomes de serviço para IPs de pods automaticamente.

O Kubernetes tem Service Discovery nativo via DNS. Quando você cria um Service no Kubernetes, ele ganha um nome DNS interno no formato serviço.namespace.svc.cluster.local. Qualquer pod no cluster pode resolver esse nome para o IP virtual do Service, que faz load balancing entre os pods saudáveis. O desenvolvedor não precisa saber quantas instâncias existem nem quais são seus IPs. Basta chamar o nome do serviço e o Kubernetes cuida do resto. O kube-proxy mantem as regras de iptables que redirecionam o tráfego para pods saudáveis. Readiness Probes garantem que pods que ainda não estão prontos não recebam tráfego, integrando health check e discovery de forma nativa.

Consul como service registry

Consul oferece service registry, health check e configuração distribuída em um único tool.

O Consul da HashiCorp e uma das ferramentas mais populares para Service Discovery fora do Kubernetes. Cada serviço se registra no agente local do Consul informando nome, IP, porta e health check endpoint. O Consul monitora periodicamente o health check e remove instâncias não saudáveis do registry automaticamente. Clientes podem descobrir serviços via API HTTP ou via DNS. O Consul também oferece Key-Value store para configuração distribuída e service mesh com Consul Connect. E especialmente util em ambientes hibridos com VMs, bare metal e containers, onde o Service Discovery do Kubernetes não alcanca facilmente todos os recursos.

Service Mesh e discovery automático

Istio e Linkerd injetam sidecar proxies que fazem discovery e load balancing de forma transparente.

Service Mesh e uma camada de infraestrutura que assume o controle da comunicação entre microservicos. Ferramentas como Istio e Linkerd funcionam injetando um sidecar proxy, geralmente Envoy, em cada pod. Esse proxy intercepta todo o tráfego de entrada e saida do serviço. O discovery, o load balancing, o retry, o circuit breaker e a criptografia TLS passam a ser responsabilidade do proxy, não do código da aplicação. O desenvolvedor não precisa implementar nada dessas preocupações na aplicação. O service mesh consulta o control plane para obter a lista de endpoints saudáveis e roteia o tráfego automaticamente, simplificando muito o código dos serviços.

Exemplo com múltiplas instâncias

Quatro instâncias do serviço de Pedidos respondendo a chamadas de forma transparente.

Imagine um sistema onde o serviço de Pedidos escala automaticamente de 1 para 4 instâncias durante o pico de vendas. Sem Service Discovery, o gateway precisária ser reconfigurado manualmente a cada escalonamento. Com Kubernetes Service, o gateway chama o nome do serviço e o Kubernetes distribui as requisições entre as 4 instâncias usando round-robin. Quando o pico passa e as instâncias voltam para 1, o comportamento e o mesmo: o gateway continua chamando o mesmo nome e o Kubernetes redireciona para a única instância ativa. Todo esse processo e completamente transparente para o código do gateway e do serviço. O Service Discovery elimina a necessidade de qualquer configuração manual de infraestrutura a cada mudanca de escala.

Quando precisa de service discovery

Qualquer sistema com mais de um serviço em ambiente dinâmico precisa de alguma forma de discovery.

Se você tem microservicos rodando em Kubernetes, o Service Discovery ja esta incluído via DNS e não precisa de configuração adicional. Se você tem microservicos fora do Kubernetes, em VMs ou bare metal, precisara de uma solução como Consul ou Eureka. Se você tem apenas dois ou tres serviços com IPs fixos que raramente mudam, configuração estatica pode ser suficiente. Em geral, qualquer sistema com escalonamento automático, deploys frequentes ou múltiplas instâncias precisa de Service Discovery. A ausência de um mecanismo de discovery em sistemas distribuídos e um dos erros mais comuns que levam a incidentes quando instâncias mudam de IP inesperadamente.

Vantagens

Descoberta dinâmica, resiliência e escalonamento automático sem configuração manual.

As vantagens do Service Discovery são: eliminação de configuração estatica de IPs; escalonamento automático transparente para os clientes; health check integrado que remove instâncias não saudáveis automaticamente; load balancing nativo entre instâncias; e redução de incidentes causados por mudancas de infraestrutura. Com Service Discovery bem implementado, um dev pode adicionar ou remover instâncias de qualquer serviço sem alterar nenhuma configuração de outros serviços. O sistema se adapta automaticamente. Isso e fundamental para ambientes de produção modernos onde containers são efemeros e a infraestrutura muda constantemente a cada deploy.

Resumo

Service Discovery e a base para microservicos funcionarem de forma resiliente em ambientes dinâmicos.

Service Discovery permite que microservicos se encontrem em ambientes onde IPs mudam constantemente. O Service Registry centraliza o catálogo de instâncias saudáveis. No Client-side Discovery, o cliente consulta o registry e decide; no Server-side, um intermediário faz isso de forma transparente. O Kubernetes resolve o problema de forma nativa via DNS. Consul e a escolha natural para ambientes hibridos. Service Mesh vai além e assume toda a comunicação entre serviços de forma transparente. Em qualquer sistema distribuído com escalonamento automático, Service Discovery não e opcional: e o mecanismo que torna possível a operação de microservicos em produção de forma sustentável.