Přeskočit na obsah
_CORE
AI & Agentic Systems Core Informační Systémy Cloud & Platform Engineering Data Platforma & Integrace Security & Compliance QA, Testing & Observability IoT, Automatizace & Robotika Mobile & Digital Banky & Finance Pojišťovnictví Veřejná správa Obrana & Bezpečnost Zdravotnictví Energetika & Utility Telco & Média Průmysl & Výroba Logistika & E-commerce Retail & Loyalty
Reference Technologie Blog Knowledge Base O nás Spolupráce Kariéra
Pojďme to probrat

Service Discovery: jak se služby najdou v dynamickém prostředí

12. 10. 2015 2 min čtení CORE SYSTEMSai

V dynamickém kontejnerovém prostředí se IP adresy a porty neustále mění. Service discovery řeší fundamentální problém — jak služby najdou jedna druhou.

Proč statická konfigurace nestačí

V tradičním prostředí stačí konfigurační soubor s IP adresami služeb. V kontejnerovém prostředí to nefunguje — kontejnery se dynamicky vytvářejí a ruší, IP adresy se mění, služby se škálují horizontálně.

Service discovery automaticky registruje služby při startu a odregistrovává při ukončení. Klienti se dotazují registru místo hardcoded adres.

Client-side vs server-side discovery

Dva základní přístupy:

Client-side discovery — klient se dotáže registru a vybere instanci:

  • Klient má kontrolu nad load balancing strategií
  • Přímá komunikace bez prostředníka
  • Netflix Eureka + Ribbon je typický příklad

Server-side discovery — klient volá load balancer, ten řeší routing:

  • Jednodušší pro klienty
  • Centrální bod pro monitoring
  • AWS ELB, Kubernetes Service jsou příklady

Kubernetes používá server-side discovery s kube-dns pro DNS-based resolution.

Consul, etcd a ZooKeeper

Tři populární nástroje pro service discovery:

  • Consul** (HashiCorp) — service discovery + health checking + KV store + multi-datacenter. Nejkompletnější řešení.
  • etcd** (CoreOS) — distribuovaný KV store, základ Kubernetes. Jednoduchý, spolehlivý.
  • ZooKeeper** (Apache) — veterán, komplexní, vyšší operační náklady.

Consul nabízí DNS interface — služby jsou dostupné jako service-name.service.consul, což zjednodušuje integraci.

Health checking a resilience

Service discovery bez health checkingu je nebezpečný — klienti mohou být směrováni na nefunkční instance.

Consul podporuje:

  • HTTP health checks
  • TCP port checks
  • Script-based checks
  • TTL-based heartbeats

Kombinace service discovery s circuit breaker pattern (Hystrix) zajistí, že selhání jedné služby nezpůsobí kaskádový výpadek celého systému.

Závěr: základ microservices infrastruktury

Service discovery je nezbytný stavební blok pro microservices architekturu. Consul doporučujeme jako výchozí volbu díky kompletní feature sadě. Pro Kubernetes prostředí je discovery built-in — ale pochopení principů je klíčové i tam.

service discoveryconsuletcdmicroservicesinfrastrukturadistribuované systémy