В монолитной архитектуре всё было просто: функции вызывали друг друга в оперативной памяти. Когда мы перешли на микросервисы, вызовы стали сетевыми. Но как одному сервису узнать IP-адрес другого?
Явная проблема в продакшене — хардкод. Если захардкодить IP-адреса, система станет хрупкой. В облаке (особенно в Kubernetes) инстансы постоянно масштабируются, падают и поднимаются с новыми IP-адресами. Для решения этой проблемы был придуман механизм Service Discovery (Обнаружение сервисов).
Это достигается за счёт выделенного Service Registry (Реестра сервисов) — эдакой «телефонной книги», куда каждый сервис записывает свой актуальный IP-адрес при запуске.
Client-Side Service Discovery
- Клиент (например, BFF) обращается к Service Registry (Consul, Eureka) с вопросом: «Дай мне адреса всех инстансов Сервиса Пользователей».
- Registry возвращает список доступных IP-адресов.
- Клиент самостоятельно выбирает один из адресов (например, по алгоритму Round Robin) и отправляет туда HTTP-запрос.
- Плюсы: Нет единой точки отказа в виде балансировщика. Гибкость маршрутизации прямо в коде клиента.
- Минусы: Клиент становится слишком умным. Логику общения с реестром и балансировки (на клиенте) нужно писать и поддерживать на каждом языке программирования, который используется в компании.
Важный контекст: На собеседованиях часто всплывает стек Netflix Eureka + Ribbon. В 2015 году это был стандарт индустрии для Client-Side Discovery.
Однако сегодня этот паттерн считается устаревающим, так как всю эту логику теперь отдают на откуп инфраструктуре (Kubernetes / Service Mesh).