Руководство по самосохранению и обновлению Эврики

1. Обзор

В этом уроке мы узнаем о самосохранении и обновлении Eureka .

Мы начнем с создания сервера Eureka вместе с несколькими экземплярами клиента Eureka.

Затем мы зарегистрируем этих клиентов на нашем сервере Eureka, чтобы показать, как работает самосохранение.

2. Эврика самосохранения

Прежде чем говорить о самосохранении, давайте разберемся, как сервер Eureka поддерживает реестр экземпляров клиента.

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

Чтобы справиться с неизящным завершением работы клиента, сервер ожидает тактовые импульсы от клиента через определенные промежутки времени. Это называется обновлением . Если сервер перестанет получать контрольные сообщения в течение заданного времени, он начнет вытеснять устаревшие экземпляры.

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

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

Давайте посмотрим на это в действии.

3. Создание сервера

Давайте сначала создадим сервер Eureka, аннотировав наш основной класс Spring Boot с помощью @EnableEurekaServer :

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

Но теперь давайте добавим основные конфигурации для запуска сервера:

eureka.client.registerWithEureka=false
eureka.client.fetchRegistry=false
eureka.instance.hostname=localhost

Поскольку мы не хотим, чтобы наш сервер Eureka регистрировался сам, мы установили для свойства eureka.client.registerWithEureka значение false . Здесь свойство eureka.instance.hostname=localhost особенно важно, поскольку мы запускаем его на локальной машине. В противном случае мы можем закончить тем, что создадим недоступную реплику на сервере Eureka, что испортит подсчет сердцебиения клиента.

Теперь давайте посмотрим на всю конфигурацию и ее актуальность в контексте самосохранения в следующем разделе.

3.1. Конфигурации самосохранения

По умолчанию серверы Eureka работают с включенным самосохранением.

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

• eureka.server.enable-self-preservation : Конфигурация для отключения самосохранения — значение по умолчанию — true .
• eureka.server.expected-client-renewal-interval-seconds : сервер ожидает тактов клиента с интервалом, настроенным с помощью этого свойства — значение по умолчанию равно 30 .
• eureka.instance.lease-expiration-duration-in-seconds : указывает время в секундах, которое сервер Eureka ожидает с момента получения последнего пульса от клиента, прежде чем он сможет удалить этот клиент из своего реестра — значение по умолчанию — 90 .
• eureka.server.eviction-interval-timer-in-ms : это свойство указывает серверу Eureka запускать задание на этой частоте, чтобы вытеснить клиентов с истекшим сроком действия — значение по умолчанию — 60 секунд .
• eureka.server.renewal-percent-threshold : на основе этого свойства сервер рассчитывает ожидаемое число ударов сердца в минуту от всех зарегистрированных клиентов — значение по умолчанию — 0,85 .
• eureka.server.renewal-threshold-update-interval-ms : это свойство указывает серверу Eureka запустить задание на этой частоте, чтобы рассчитать ожидаемые пульсации от всех зарегистрированных клиентов в эту минуту — значение по умолчанию — 15 минут .

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

4. Регистрация клиентов

Теперь давайте создадим Eureka Client и запустим шесть экземпляров:

@SpringBootApplication
@EnableEurekaClient
public class EurekaClientApplication {

    public static void main(String[] args) {
        SpringApplication.run(EurekaClientApplication.class, args);
    }
}

Вот конфигурации клиента:

spring.application.name=Eurekaclient
server.port=${PORT:0}
eureka.client.serviceUrl.defaultZone=http://localhost:8761/eureka
eureka.instance.preferIpAddress=true
eureka.instance.lease-renewal-interval-in-seconds=30

Эта конфигурация позволяет нам запускать несколько экземпляров одного и того же клиента с программным аргументом PORT . Конфигурация eureka.instance.lease-renewal-interval-in-seconds указывает интервал тактов, которые клиент отправляет на сервер. Значение по умолчанию — 30 секунд, что означает, что клиент будет отправлять один пульс каждые 30 секунд.

Давайте теперь запустим эти шесть клиентских экземпляров с номерами портов, начинающимися с 8081 по 8086, и перейдем к http://localhost:8761 , чтобы проверить, зарегистрированы ли эти экземпляры на сервере Eureka.

На снимке экрана видно, что на нашем сервере Eureka зарегистрировано шесть экземпляров клиентов, а общий порог продления составляет 11. Расчет порога основан на трех факторах:

• Общее количество зарегистрированных клиентских экземпляров – 6
• Настроенный интервал обновления клиента – 30 секунд
• Настроенный порог процента продления — 0,85.

Учитывая все эти факторы, в нашем случае порог равен 11.

5. Проверка самосохранения

Чтобы смоделировать временную сетевую проблему, давайте установим свойство eureka.client.should-unregister-on-shutdown как false на стороне клиента и остановим один из наших экземпляров клиента. Поскольку мы установили для флага should-unregister-on-shutdown значение false , клиент не будет вызывать вызов отмены регистрации, и сервер предполагает, что это неизящное завершение работы .

Теперь давайте подождем 90 секунд, заданных нашим свойством eureka.instance.lease-expiration-duration-in-seconds , и снова перейдем к http://localhost:8761 . Текст, выделенный красным жирным шрифтом, указывает на то, что сервер Eureka теперь находится в режиме самосохранения и прекратил вытеснение экземпляров.

Теперь давайте проверим раздел зарегистрированных экземпляров, чтобы узнать, доступен ли остановленный экземпляр. Как мы видим, он доступен, но со статусом DOWN :

Единственный способ , которым сервер может выйти из режима самосохранения, — это либо запуск остановленного экземпляра, либо отключение самого самосохранения. Если мы повторим те же шаги, установив для флага eureka.server.enable-self-preservation значение false , то сервер Eureka удалит остановленный экземпляр из реестра после настроенного свойства продолжительности срока действия аренды.

6. Заключение

В этом руководстве мы узнали, как работает самосохранение Eureka и как мы можем настроить различные параметры, связанные с самосохранением.

Все примеры, которые мы здесь продемонстрировали, можно найти на GitHub .