Контекст
Паттерны межсервисной коммуникации
Коммуникация между сервисами становится хрупкой без корректного discovery и routing слоя.
Service discovery решает базовую задачу распределенной среды: как сервисы находят друг друга в условиях динамических инстансов, failover и масштабирования. Надежный discovery-контур снижает time-to-recovery и уменьшает каскадные инциденты.
Модели discovery
Client-side discovery
Клиент сам получает список инстансов из registry и выбирает endpoint через local load balancing.
Server-side discovery
Клиент обращается к стабильной точке входа (LB/proxy), а маршрутизация к сервисам скрыта внутри инфраструктуры.
DNS-based discovery
Сервисы публикуются как DNS-имена; клиенты используют стандартные DNS-резолверы и TTL-политику.
Client-side discovery
SDK делает lookup в registry, хранит локальный пул инстансов и маршрутизирует запросы на стороне клиента.
Сильные стороны
- Максимальный контроль маршрутизации и retry-логики на стороне клиента.
- Быстрая реакция на локальные метрики latency и error-rate.
- Независимость от центрального proxy в data path.
Ограничения
- Нужно поддерживать discovery SDK во всех сервисах и языках.
- Сложнее обеспечить единообразные правила на всей платформе.
Request Queue
Discovery plane
Клиент сам выполняет lookup и локально выбирает endpoint по policy.
service-a-01
service-a-02
service-a-03
Готово к симуляции discovery-потока.
Последнее решение: —
Ключевые компоненты
- Service registry: хранит актуальные endpoint-ы и метаданные инстансов.
- Health checks: readiness/liveness сигнализируют, можно ли направлять трафик на инстанс.
- Heartbeat/session TTL: автоматическое удаление неактивных нод из discovery-контура.
- Load balancing policy: round-robin, least-loaded, locality-aware routing.
- Retry/timeout policy: защита от кратковременных сбоев и сетевых колебаний.
Foundation
DNS
DNS - базовый building block для многих service discovery реализаций.
Trade-offs
Consistency vs availability registry
Слишком строгая консистентность может ухудшить доступность discovery при сетевых проблемах.
TTL freshness vs DNS/query overhead
Короткий TTL ускоряет обновление маршрутов, но повышает нагрузку на DNS/control plane.
Centralized control vs local autonomy
Централизованный control plane удобен, но увеличивает blast radius при ошибках конфигурации.
Dynamic endpoints vs cache staleness
Кеши ускоряют lookups, но могут держать устаревшие адреса во время failover.
Практический чеклист
- Реализована автоматическая deregistration логика при падении/изолировании ноды.
- Проверено поведение discovery в partition-сценариях и при контроллерных сбоях.
- Настроены retries/timeouts с jitter и ограничением повторов.
- Есть мониторинг stale endpoints и latency lookup в discovery path.
- Сервисные имена и ownership стандартизированы на уровне платформы.
Связанные главы
DNS
Базовая механика name resolution, на которой строится часть discovery-стратегий.
Service Mesh Architecture
Mesh добавляет policy-aware routing поверх service discovery механизмов.
Паттерны межсервисной коммуникации
Паттерны коммуникации и discovery проектируются в связке.
Kubernetes Fundamentals
Практика service discovery через Kubernetes Service, Endpoints и DNS.
Паттерны отказоустойчивости
Discovery должен работать вместе с retry/circuit breaker и health-policy.