При переходе к распределённым системам с большим количеством инстансов сервисов в полный рост встают проблемы их обнаружения (service discovery) и балансировки запросов (load balancing) между ними. Как правило, для их решения используются такие специализированные инструменты как Consul, Eureka или старый добрый Zookeeper, в сочетании с Nginx, HAProxy и некоторым мостом между ними (см. registrator).

Основная проблема в подобном подходе это большое количество интеграций, и, как следствие, точек где что-то может пойти не так. Ведь помимо вышеупомянутых решений наверняка будет использоваться локальный маленький PaaS (например Mesosphere Marathon или Kubernetes). Последние, к слову, уже хранят необходимую конфигурацию об окружении (ведь через них идёт весь деплоймент). И встаёт вопрос, а можем ли мы отказаться от специализированных инструментов для service discovery и переиспользовать тот же Marathon для этой задачи?

Краткий ответ — можем. Если интересно как — читайте дальше.

Диспозиция

Итак, что у нас есть в наличии:

Apache Mesos и его верный фреймворк Marathon в качестве системы оркестрации сервисов
Сервисы, которые написаны с использованием фреймворка Spring Boot и его расширения Spring Cloud

Mesos без сахара (читай без фреймворков) это система управления ресурсами кластера, которую можно расширять с помощью фреймворков. Фреймворки служат разным целям. Какие-то умеют запускать широкий спектр краткосрочных задач (Chronos), другие долгоживущих (Marathon). А некоторые заточены под конкретные продукты, такие как Hadoop или Jenkins.

Mesosphere Marathon представляет из себя тот самый фреймворк, который умеет управлять запуском, остановкой и в целом планированием работы долгоживущих задач, к которым можно отнести сервисы, обрабатывающие клиентские, и не очень, запросы на длительном промежутке времени.

Spring Cloud это тоже фреймворк, но уже для разработки этих самых сервисов, в котором реализованы как основные паттерны для их работы в распределённых системах, так и конкретные интеграции этих паттернов с существующими на рынке решениями (например, с тем же Consul-ом).

В рамках Spring Cloud-а для решения задачи обнаружения сервисов есть фактически две реализации.

Первую, с помощью Netflix Zuul, можно отнести к шаблону Server-Side Service Discovery. Суть шаблона заключается в том, что мы делаем некоторое количество роутеров, которые знают текущее местоположение и различную мета-информацию об инстансах сервисов, и предоставляют постоянные http-ресурсы, через которые идёт проксирование запросов к ним. Если абстрагироваться от Spring-а, то классическим роутером является nginx при условии его динамической конфигурации.

Server-Side Service Discovery pattern

Вторая реализация относится к классу Client-Side Service Discovery. Основное её отличие от предыдущей состоит в отсутствии роутера, а следовательно промежуточного звена и лишней точки отказа, как класса. Вместо этого в качестве роутера используется "умный" клиентский балансировщик, который также знает всё, что нужно знать, про инстансы сервисов, которые он вызывает. В Spring Cloud в качестве такого балансировщика используется Netflix Ribbon.
Client-Side Service Discovery pattern

В этом цикле статей мы подробнее остановимся на клиентской реализации шаблона, хотя и про серверную тоже поговорим.

@EnableDiscoveryClient

В Spring-е почти всё можно сделать работающим влепив над классом/методом/переменной один-другой десяток аннотаций и прописав немножко конфигурации в yaml-файл. Ну ок, предположим, что не всё, но многое.

Методичка учит нас, что добавив magic-аннотацию @EnableDiscoveryClient над своим приложением, у нас будет работать (после пары зависимостей и настроек, но об это чуть позже) обнаружение сервисов. По крайней мере локально внутри нашего приложения. Сделать это можно очень просто, даже напрягаться не надо:

@SpringBootApplication
@EnableDiscoveryClient
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

После этого начинается магия в которой нет волшебства. Spring увидев эту аннотацию загружает все конфигурации, которые указаны в META-INF/spring.factories в качестве загружаемых для EnableDiscoveryClient:

org.springframework.cloud.client.discovery.EnableDiscoveryClient=\
org.springframework.cloud.xxx.discovery.XXXDiscoveryClientConfiguration

Откуда и какие вообще могут быть загружены конфигурации? Для ответа на этот вопрос нужно сказать, что сам Spring Cloud состоит из базовой части, в которой есть необходимые интерфейсы и общая логика реализации различных шаблонов, и коннекторы, которые поставляются в виде starter-ов, и в которых есть конкретная имплементация для конкретных решений. Схематично мы можем изобразить это так: spring-cloud-scheme
Например, если мы подключим стартер для Netflix Eureka, то у нас в classpath будет одна фабричная конфигурация. Если же стартер для Consul-а, то другая.

Засада тут однако в том, что сама по себе аннотация, при промышленной, а не "хэллоуворлд" разработке, чуть менее чем полностью бесполезна, поскольку весь профит находится в области прописывания правильных настроек в bootstap.yml. И для каждого коннектора они, как вы уже наверное догадались, свои.

Почему так сделано понять несложно. Eureka, Consul и Marathon устроены совершенно по разному. К ним нужно по разному подключаться. У них разный API и фичи, которые специфичны для конкретного решения. Сделать универсальный конфиг невозможно, да и в общем-то незачем.

Однако вернёмся к конфигурации, которая тянется с помощью @EnableDiscoveryClient. И первое что приходит в голову, и что быстро находится через поиск в любимой IDE, это реализация интерфейса DiscoverClient. Самый главный (по крайней мере на первый взгляд) интерфейс выглядит так:

public interface DiscoveryClient {
    public String description();
    public ServiceInstance getLocalServiceInstance();
    public List<ServiceInstance> getInstances(String serviceId);
    public List<String> getServices();
}

В принципе, тут всё довольно очевидно. Мы можем получить описание для HealthIndicator-а. Можем получить сами себя. Можем получить все инстансы по некоторому идентификатору сервиса. И, наконец, можем получить список всех известных сервисов (точнее их идентификаторов).

Самое время реал��зовать интерфейс для того, чтобы получать данные из Marathon-а.

Первая кровь

Как получить данные? Это первый вопрос, который нам нужно решить. И это не то, чтобы трудно.

Во-первых, у него есть мощный API. Во-вторых, есть уже готовый для Java SDK.

Берём ноги в руки и реализуем получение списка всех сервисов:

@Override
public List<String> getServices() {
    try {
        return client.getApps()
                .getApps() //тавтология, но что поделать
                .parallelStream()
                .map(App::getId) //получаем идентификаторы
                .map(ServiceIdConverter::convertToServiceId) //немного магии не помешает
                .collect(Collectors.toList());
    } catch (MarathonException e) {
        return Collections.emptyList();
    }
}

Никакой магии за исключением ServiceIdConverter::convertToServiceId. Что это за странный конвертер спросите вы. И тут надо сказать об одной особенности представления идентификаторов сервисов в Marathon-е. В общем случае они подчиняются следующему шаблону:

/group/path/app

но символ / не может использоваться для построения виртуального хоста. И, таким образом, некоторые части Spring Cloud-а, в которых используется идентификатор сервиса в качестве виртуального хоста, работать не будут. Поэтому вместо / будем использовать другой разделитель, который разрешён присутствовать в имени хоста, а именно точку. Именно поэтому мы вынуждены получить соответствие /group/path/app на group.path.app. Что собственно конвертер и делает.

Получение всех инстансов сервиса реализовано несколько сложнее, но тоже никакого ракетостроения:

@Override
public List<ServiceInstance> getInstances(String serviceId) {
    try {
        return client.getAppTasks(ServiceIdConverter.convertToMarathonId(serviceId))
                .getTasks()
                .parallelStream()
                .filter(task -> null == task.getHealthCheckResults() || //health-чеков нет, ну и ладно
                        task.getHealthCheckResults()
                        .stream()
                        .allMatch(HealthCheckResult::isAlive) //все должны быть живы
                )
                .map(task -> new DefaultServiceInstance(
                        ServiceIdConverter.convertToServiceId(task.getAppId()),
                        task.getHost(),
                        task.getPorts().stream().findFirst().orElse(0), //magiс zero
                        false
                ))
                .collect(Collectors.toList());
    } catch (MarathonException e) {
        log.error(e.getMessage(), e);
        return Collections.emptyList();
    }
}

Основное, что нам нужно проверить, это то, что для сервиса прошли все health-чеки: HealthCheckResult::isAlive, ведь наша задача работать только с теми, кто жив. Механизм health-чеков предоставляется самим Marathon-ном, который даёт возможность их настройки и сам же следит за здоровьем вверенных ему сервисов, раздавая безвозмездно эту информацию через API.

Помимо этого, нам нужно не забыть опять же сконвертировать идентификатор в правильное представление и выбрать только один, первый, порт: task.getPorts().stream().findFirst().orElse(0).

Так так так, скажете вы. А что же делать, если портов у приложения несколько? К сожалению, выбор у нас невелик. Мы с одной стороны должны вернуть объект, реализующий интерфейс ServiceInstance, у которого есть метод getPort, который понятное дело может вернуть только один порт. А с другой, мы на самом деле не знаем, какой порт из списка брать. Marathon не даёт нам об этом какой-либо информации. Поэтому берём тот, что указан первым. Авось повезёт.

Можно попробовать решить эту проблему так, как решает её registrator при регистрации сервисов в том же Consul-е. Это учитывать порт сервиса в его идентификаторе. Тогда идентификатор сервиса будет примерно таким: group.path.app.8080 в случае, если портов больше одного.

Немного отвлеклись. Самое время добавить новоиспечённую имплементацию как бин:

@Configuration
@ConditionalOnMarathonEnabled
@ConditionalOnProperty(value = "spring.cloud.marathon.discovery.enabled", matchIfMissing = true)
@EnableConfigurationProperties
public class MarathonDiscoveryClientAutoConfiguration {

    @Autowired
    private Marathon marathonClient;

    @Bean
    public MarathonDiscoveryProperties marathonDiscoveryProperties() {
        return new MarathonDiscoveryProperties();
    }

    @Bean
    @ConditionalOnMissingBean
    public MarathonDiscoveryClient marathonDiscoveryClient(MarathonDiscoveryProperties discoveryProperties) {
        MarathonDiscoveryClient discoveryClient =
                new MarathonDiscoveryClient(marathonClient, marathonDiscoveryProperties());
        return discoveryClient;
    }
}

Что тут важно. Во-первых мы используем conditional-аннотации: @ConditionalOnMarathonEnabled и @ConditionalOnProperty. То есть, если в настройках будет отключена функциональность, например через настройку spring.cloud.marathon.discovery.enabled, то конфигурация грузиться не будет.

Во-вторых, над нашим клиентом стоит волшебная аннотация @ConditionalOnMissingBean, которая даёт возможность в конкретном приложении переопределить бин так, как это будет нужно пользователю.

Нам остаётся сделать самую малость. Сконфигурировать клиента для Marathon-а. Наивная, но при этом рабочая, реализация конфигурации выглядит так:

spring:
    cloud:
        marathon:
            scheme: http       #url scheme
            host: marathon     #marathon host
            port: 8080         #marathon port

Для этого нам нужен класс с его настройками:

@ConfigurationProperties("spring.cloud.marathon")
@Data //lombok is here
public class MarathonProperties {
    @NotNull
    private String scheme = "http";

    @NotNull
    private String host = "localhost";

    @NotNull
    private int port = 8080;

    private String endpoint = null;

    public String getEndpoint() {
        if (null != endpoint) {
            return endpoint;
        }

        return this.getScheme() + "://" + this.getHost() + ":" + this.getPort();
    }
}

и очень похожая на предыдущую конфигурация:

@Configuration
@EnableConfigurationProperties
@ConditionalOnMarathonEnabled
public class MarathonAutoConfiguration {
    @Bean
    @ConditionalOnMissingBean
    public MarathonProperties marathonProperties() {
        return new MarathonProperties();
    }

    @Bean
    @ConditionalOnMissingBean
    public Marathon marathonClient(MarathonProperties properties) {
        return MarathonClient.getInstance(properties.getEndpoint());
    }
}

После этого мы можем радостно идти в наше приложение, заавтовайрить DiscoveryClient:

@Autowired
private DiscoveryClient discoveryClient;

и, к примеру, получить список всех инстансов для некоторого сервиса:

@RequestMapping("/instances")
public List<ServiceInstance> instances() {
    return discoveryClient.getInstances("someservice");
}

И тут нас ожидает первый сюрприз. Наша цель ведь не в том, чтобы получить список инстансов, а в том, чтобы делать балансировку между ними. И оказывается, что DiscoveryClient для этого не то чтобы сильно полезен, потому что просто напросто никак в реализации балансировки не участвует. Ок, вру. Немного участвует, например при динамической регистрации endpoint-ов в Zuul-е. Ещё он используется для health-индикаторов. Но это в принципе всё его стандартное применение. Не так уж много правда?

Итого

Мы смогли проинтегрироваться с Marathon-ом. Это хорошо. Мы даже можем теперь получить список сервисов и их инстансов.

Но вместе с тем, у нас остались как минимум две нерешённые проблемы. Первая связана с тем, что у нас в конфигурации указан лишь один инстанс мастера Marathon-а для подключения. Если он упадёт, то мы перестанем владеть информацией, а следовательно и миром.

Вторая — мы так и не добрались до реализации клиентской балансировки и в руках у нас пока что детская игрушка, а не инструмент решающий проблемы.

Продолжение следует

Скрестить ежа (Marathon) с ужом (Spring Cloud). Эпизод 1