Повторяет ли Jhipster сервисные вызовы?

Я использую JHipster версии 4.6.2 на своем шлюзе. У меня есть реестр JHipster и два экземпляра одного и того же микросервиса. В реестре JHipster я вижу, что шлюз и оба экземпляра микросервиса зарегистрированы правильно. Могу настроить, посмотреть здоровье и тд. Короче все работает нормально.

Микросервис был создан с помощью более новой версии JHipster (4.11.1). И шлюз, и микросервисы, похоже, хорошо взаимодействуют. Например, пользовательский интерфейс по умолчанию (сгенерированный) на шлюзе способен извлекать данные (объекты) из микросервисов. На шлюзе я просто использую логику, сгенерированную для меня Jhipster, для получения данных из микросервиса. В журналах я вижу, что вызовы направляются в оба экземпляра микросервиса.

Проблема, с которой я сталкиваюсь, заключается в том, что когда я закрываю один экземпляр микросервиса, шлюз все еще иногда пытается направить вызов службы к экземпляру микросервиса, который уже отключен. Конечно, через некоторое время все вызовы сервисов правильно маршрутизируются только на правильный / работающий экземпляр микросервисов. Но иногда сразу после завершения работы одного экземпляра микросервисов вызов может быть перенаправлен на «неправильный» экземпляр.

Я ожидал, что такие компоненты, как лента, zuul и eureka, автоматически попробуют другой экземпляр микросервиса, если вызов службы к первому экземпляру микросервиса завершится неудачно. Мои ожидания верны? Должна ли Jhipster «платформа микросервисов» автоматически повторять вызов службы для другого зарегистрированного экземпляра микросервиса?

Если по умолчанию повторная попытка не поддерживается, что мне делать, чтобы это произошло?


netflix-eureka netflix-zuul jhipster netflix-ribbon
person Jussi Seppälä    schedule 15.12.2017    source источник
comment
Вы должны настроить его в свойствах приложения шлюза, потому что это не включено по умолчанию в весеннем облаке. Документ Spring Cloud не очень прост, но вы можете настроить разные стратегии для каждого маршрута zuul, см. stackoverflow.com/questions/42651456/   -  person Gaël Marziou    schedule 16.12.2017
comment
У тебя есть решение.   -  person csu    schedule 14.05.2018

Ответы (1)


arrow_upward
1
arrow_downward

Спасибо за ответ, Гаэль. Я попробовал конфигурацию из предоставленной вами ссылки, но это не полностью решило мой случай.

Когда удалось избавиться от исходного исключения («com.netflix.client.ClientException: null»), я столкнулся со следующей проблемой («Вызвано: com.netflix.client.ClientException: количество повторных попыток на следующем сервере превысило максимум 2 попытки. , при звонке на: 192.168.1.4:8082 "). Мне нужно было настроить MaxAutoRetriesNextServer (см. https://github.com/spring-cloud/spring-cloud-netflix/issues/2052). Это продвинуло меня на шаг вперед, но по-прежнему были исключения hystrix («Вызвано: com.netflix.hystrix.exception.HystrixRuntimeException: истекло время ожидания myservice и нет возможности отката»).

Наконец, с помощью этих двух ссылок (https://github.com/jhipster/generator-jhipster/issues/3323 и https://github.com/spring-cloud/spring-cloud-netflix/issues/321) Мне удалось создать конфигурацию, которая обеспечивала 100% доступность в моих тестах (пока что).

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

zuul:
    routes:
        myservice:
            retryable: true
    host:
        connect-timeout-millis: 5000
        socket-timeout-millis: 20000            
ribbon:
    MaxAutoRetries: 1
    MaxAutoRetriesNextServer: 5
    OkToRetryOnAllOperations: true
    ReadTimeout: 2500
    restclient:
        enabled: true
hystrix:
    command:
        default:
            execution:
                isolation:
                    thread:
                        timeoutInMilliseconds: 20000
person Jussi Seppälä    schedule 20.12.2017