2015-07-10 4 views
0

Есть два сервера eureka (скажем, ES1 и ES2) с нижней конфигурацией.Обновление кэша сервера Eureka

spring: 
    profiles: production 

server: 
    port: 8761  

eureka: 
    client: 
    registerWithEureka: true 
    fetchRegistry: true 
    serviceUrl: 
     defaultZone: http://${eureka.peer.hostname}:8761/eureka/ 

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

Для регистрации клиентов eureka ниже конфигурации используется.

eureka: 
    instance: 
    metadataMap: 
     instanceId: ${service.contextPath}:${spring.application.instance_id:${random.value}} 
    client: 
    serviceUrl: 
     defaultZone: http://localhost:8761/eureka/ 

Почему старые экземпляры не подлежат регистрации с сервера eureka? Из-за этого мы должны полностью завершить работу и перезагрузить нашу инфраструктуру.

+0

Надеюсь, что это помогает - https://github.com/spring-cloud/spring-cloud-netflix/issues/373#issuecomment-110331739 –

ответ

0

Я предполагаю, что вы видите результат самосохранения Eureka. Короче говоря, сервер Eureka автоматически прекращает истечение срока аренды лизинга, когда он замечает, что в течение последней минуты он получил менее 80% ожидаемых обновлений. Когда ES1 опускается, ES2 больше не получает сердечных сокращений от клиентов, которые первоначально были зарегистрированы с ES1 - тогда он, вероятно, активирует режим самосохранения.

Чтобы избежать этой ситуации, вы должны настроить своих клиентов как с ES1 , так и с ES2: клиент автоматически переключится на ES2, если ES1 недоступен. Для этого нужно просто перечислить оба адреса следующим образом:

eureka: 
    client: 
    serviceUrl: 
     defaultZone: http://ES1:8761/eureka/,http://ES2:8761/eureka/ 

Вы также можете отключить функцию самозащиты - но это не ожидаемая конфигурация, когда в кластере - так что ожидать странное поведение :-(

+0

@Vibhaanshu какие-либо новости по этому вопросу? Соответствует ли приведенный выше анализ вашему делу? –

+0

Прошу прощения за опоздание. заметил, что стратегия развертывания, которая была соблюдена, была неправильной. Мы не разрешали службам должным образом регистрироваться из-за эврики, из-за того, что этот сервер peer eureka имеет устаревшие идентификаторы экземпляра службы. есть службы на одном сервере с сервером eureka, работающим на одном сервере, и обслуживает один другой регистр с сервером eureka на этом сервере. Синхронизация происходит между двумя серверами eureka. Будет проверять ваш подход, а также в процессе определения стратегии развертывания служб с разными версиями без какого-либо простоя. – Vibhaanshu

Смежные вопросы