🟢 Junior Level

Service Discovery — это механизм, который позволяет сервисам находить друг друга в динамической среде, где IP-адреса постоянно меняются.

В контейнеризованной среде (Docker, Kubernetes) поды и контейнеры создаются и уничтожаются динамически. Каждый новый контейнер получает новый IP. Хардкодить адреса невозможно.

Проблема: В микросервисах сервисы запускаются и останавливаются (особенно в Kubernetes). IP-адрес меняется каждый раз. Как сервису A найти сервис B?

Решение: Service Discovery — как “телефонная книга” для сервисов.

Сервис A → Service Discovery: "Где сервис B?"
Service Discovery → Сервис A: "Сервис B на 10.0.0.5:8080"
Сервис A → 10.0.0.5:8080 → Сервис B

---

🟡 Middle Level

Типы Service Discovery

1. Client-side discovery:

Сервис A → Service Registry → получает IP → вызывает Сервис B

2. Server-side discovery:

Сервис A → Load Balancer → Service Registry → Сервис B

Компоненты

Service Registry:

Хранит список сервисов и их адресов
Примеры: Consul, Eureka, ZooKeeper, etcd

Service Registration:

Сервис при старте регистрируется в Registry
При остановке — deregister

Типичные ошибки

1. Stale entries: ``` Сервис упал, но не успел deregister Registry всё ещё отдаёт старый IP Решение: health checks + TTL

TTL (Time-To-Live) — запись в реестре «протухает» через N секунд. Если сервис не обновил запись вовремя — она удаляется автоматически.

---

### Когда Service Discovery НЕ нужен

- **2-3 сервиса** со статическими IP — проще DNS
- **Монолит на пути к микросервисам** — пока нет динамического масштабирования
- **Single-server deployment** — всё на одной машине

---

## 🔴 Senior Level

### Архитектурные Trade-offs

| Client-side                    | Server-side         |
| ------------------------------ | ------------------- |
| Больше контроля                | Проще для клиентов  |
| Нужно реализовать балансировку | LB берёт на себя    |
| Зависимость от Registry client | Независимые клиенты |

### Production Experience

**Kubernetes:**

K8s имеет встроенный Service Discovery:

• Service → DNS name
• kube-proxy → load balancing
• Endpoints → список Pod IP

Сервис A → my-service.default.svc.cluster.local → kube-proxy → Pod B

### Best Practices

✅ Health checks для каждого сервиса ✅ TTL для entries ✅ Client-side caching с expiry ✅ Graceful shutdown → deregister

❌ Без health checks ❌ Долгий TTL (stale data) ❌ Без fallback при недоступности Registry ```

---

🎯 Шпаргалка для интервью

Обязательно знать:

• Service Discovery — “телефонная книга” для микросервисов в динамической среде
• Два типа: client-side (клиент сам ищет) и server-side (LB ищет)
• Service Registry хранит список сервисов и их адресов (Consul, Eureka, etcd)
• Health checks + TTL решают проблему stale entries
• В Kubernetes встроен: Service → DNS name → kube-proxy → Pod
• Graceful shutdown → deregister из Registry
• НЕ нужен для 2-3 сервисов со статическими IP

Частые уточняющие вопросы:

• Что такое stale entries? Сервис упал, но запись в Registry ещё жива — решение: health checks + TTL.
• Client-side vs server-side? Client-side = больше контроля, server-side = проще для клиентов.
• Зачем TTL? Запись “протухает” через N секунд, если сервис не обновил — удаляется автоматически.
• K8s Service Discovery как работает? Service → DNS name → kube-proxy → Endpoints (список Pod IP).

Красные флаги (НЕ говорить):

• “Service Discovery нужен всегда” — нет, для 2-3 сервисов хватит DNS
• “TTL не важен, сервисы стабильны” — в контейнеризованной среде IP меняются постоянно
• “Client-side не нужен, только server-side” — Netflix Ribbon, Spring Cloud LoadBalancer
• “Registry = single point of failure, значит не нужен” — нужен fallback и кластеризация

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

• [[8. В чём разница между client-side и server-side discovery]]
• [[9. Что такое API Gateway и какие задачи он решает]]
• [[12. Как реализовать горизонтальное масштабирование микросервисов]]
• [[26. Какие инструменты используются для оркестрации микросервисов]]
• [[15. Как организовать коммуникацию между микросервисами]]