Service discovery на собеседовании системного аналитика

Зачем service discovery

Микросервисы — instances dynamically scale. Address не fixed.

order-service: instances on 10.0.1.5:8080, 10.0.1.6:8080, 10.0.1.7:8080

Каждый restart / scale — new IPs. Nobody hard-codes.

Service discovery — runtime lookup «где X-service».

Client-side discovery

Client queries registry → gets instances → load balances itself.

Client → Registry: "Where is order-service?"
Registry: ["10.0.1.5:8080", "10.0.1.6:8080"]
Client: round-robin / random pick

Pros: simple registry, client-side LB strategy flexible.

Cons: caclient must implement LB logic. Multi-language clients duplicate.

Server-side discovery

Client → load balancer / API gateway → registry → instances.

Client → LB → (LB queries registry) → instance

Pros: Logic centralized. Client just hits LB endpoint.

Cons: LB — additional hop, more infra.

В k8s — service discovery server-side через kube-proxy или service mesh.

Service registry

Central store «what services / instances are alive».

Functions:

• Service registers itself на startup.
• Heartbeat to indicate alive.
• Deregister on shutdown.
• Health check.

Tools: Consul, etcd, Eureka, ZooKeeper.

DNS-based

Use DNS как simple registry.

order-service.internal → returns multiple A records

Standard DNS, language-neutral.

Cons: TTL — slow updates.

В k8s — CoreDNS делает service-name → cluster IP mapping.

Tools

Consul (HashiCorp). Health check + KV + DNS + service mesh.

etcd. Used by k8s internal.

ZooKeeper. Older, used by Hadoop ecosystem.

Eureka (Netflix, deprecated). Spring Cloud history.

Service mesh (Istio, Linkerd) — built-in service discovery.

Связанные темы

• Service mesh для SA
• API Gateway и BFF для SA
• Микросервисы vs монолит для SA
• Circuit Breaker для SA
• Подготовка к собесу системного аналитика

FAQ

Это официальная информация?

Нет. Статья основана на индустриальных практиках микросервисов.

Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.