Spring Cloud Config Server-Suche durch Eureka mit Java anstelle von bootstrap.yml

Question

Ich versuche Code in unsere Basis Pom zu bauen, die Spring Cloud Config Server-Lookup durch Eureka automatisch konfiguriert. Wir tun dies, um Template-Eigenschaften für Entwickler, die Microservices erstellen, zu vermeiden. Zum Beispiel wollen wir auf Java-Config alle Verhalten von diesen Eigenschaften ausgelöst:

spring: 
    application: 
    name: MyMicroservice 
    cloud: 
    config: 
     enabled: true 
    server: 
     prefix: /diagnostics/admin/config 
    failFast: true 
    discovery: 
     enabled: true 
     serviceId: echo 

management: 
    context-path: /diagnostics/admin 

eureka: 
    password: password 
    client: 
    serviceUrl: 
     defaultZone: http://user:${eureka.password}@localhost:8761/eureka/ 
    instance: 
    leaseRenewalIntervalInSeconds: 10 
    statusPageUrlPath: /diagnostics/admin/info 
    healthCheckUrlPath: /diagnostics/admin/health 

Nach viel experimentieren, der folgende Ansatz funktioniert meist mit Ausnahme des Eureka-entdeckte Config Server (was keine überschriebenen Konfigurationseigenschaften):

@Order(-1) 
public class AdditionalBootstrapPropertySourceLocator implements PropertySourceLocator { 

    @Override 
    public PropertySource<?> locate(Environment environment) { 
     Map<String, Object> theBootstrapYmlConfig = new HashMap<>(); 
     theBootstrapYmlConfig.put("spring.cloud.config.enabled", new Boolean(true)); 
     theBootstrapYmlConfig.put("spring.cloud.config.server.prefix", "/diagnostics/admin/config"); 
     theBootstrapYmlConfig.put("spring.cloud.config.failFast", new Boolean(true)); 
     theBootstrapYmlConfig.put("spring.cloud.config.discovery.enabled", new Boolean(true)); 
     theBootstrapYmlConfig.put("spring.cloud.config.discovery.serviceId", "echo"); 

     theBootstrapYmlConfig.put("management.context-path", "/diagnostics/admin"); 

     theBootstrapYmlConfig.put("eureka.client.serviceUrl.defaultZone", "http://user:password@localhost:8761/eureka/"); 
     theBootstrapYmlConfig.put("eureka.instance.leaseRenewalIntervalInSeconds", new Integer(10)); 
     theBootstrapYmlConfig.put("eureka.instance.statusPageUrlPath", "/diagnostics/admin/info"); 
     theBootstrapYmlConfig.put("eureka.instance.healthCheckUrlPath", "/diagnostics/admin/health"); 

     return new MapPropertySource("myExtraBootstrap", theBootstrapYmlConfig);  
    }  
} 

Und ich scheinen diese Bean auch brauchen:

@ConditionalOnWebApplication 
@Configuration 
@Import(EurekaClientAutoConfiguration.class) 
public class WorkfrontDiscoveryClientConfigServiceBootstrapConfiguration { 

    @Bean 
    @ConditionalOnClass({ DiscoveryClient.class, ConfigServicePropertySourceLocator.class }) 
    @ConditionalOnMissingBean 
    DiscoveryClientConfigServiceBootstrapConfiguration discoveryClientConfigServiceBootstrapConfiguration() { 
     DiscoveryClientConfigServiceBootstrapConfiguration discoveryClientConfigServiceBootstrapConfiguration = 
       new DiscoveryClientConfigServiceBootstrapConfiguration(); 
     return discoveryClientConfigServiceBootstrapConfiguration; 
    } 

} 

Schließlich ich habe sowohl in spring.factories, um sicherzustellen, sie aufgebaut sind. Das Problem besteht darin, dass der PropertySourceLocator nie zum Erstellen des Aufrufs in ConfigServicePropertySourceLocator verwendet wird, um die Eigenschaften abzurufen. Egal, was ich mache, ich kann nicht mit den Verhaltensweisen übereinstimmen, die durch die Angabe der Eigenschaften in bootstrap.yml erzeugt würden.

bearbeiten 4 Tage später

Der Schlüsselfaktor (bzw. Einschränkung) hier ist die Fähigkeit, den Konfigurationsserver über Eureka nachzuschlagen. In der aktuellen Frühjahrs-Cloud-Version (1.0.2) wird die Eigenschaftsquelle zu früh im Frühjahrs-Initialisierungszyklus für die Config-Lookup-Through-Eureka-Java-Eigenschaftsquellkonfiguration, die ich oben habe, abgerufen und konstruiert. Wenn der Eureka-Server zum Zeitpunkt des Bootstrap-Starts langsam oder nicht verfügbar ist, wird die Property-Quelle des Config-Servers nie rekonstruiert, wenn Eureka schließlich erscheint. Dies ist in meinen Augen ein Fehler.

löste ich das alles durch das Konzept der Beseitigung dieser Mindest config in bootstrap.yml die Config-Server über Eureka und erfordern aufzublicken:

spring: 
    application: 
    name: MyMicroservice 
    cloud: 
    config: 
     uri: http://localhost:8888/diagnostics/admin/config 

eureka: 
    client: 
    serviceUrl: 
     defaultZone: http://user:password@localhost:8761/eureka/ 

und dann in der Java-AdditionalBootstrapPropertySourceLocator

den Rest Einstellung

30 Tage später bearbeiten

Java-konfigurierende Bootstrap-Eigenschaften sind weiterhin eine Herausforderung. Ich mache das, weil ich ein Framework ohne Templating oder Code-Generierung entwickle (die Prämisse von Spring Boot). Ich habe Spring-Retry hinzugefügt und client-to-config wird wiederholt, aber Neuregistrierung bei Eureka funktioniert nicht. Deshalb musste Eureka-first für mich aufgegeben werden. Ich würde mich dafür einsetzen, Spring-Retry in den Eureka-Registrierungsprozess zu integrieren, damit ich für mein Framework zu Eureka-first zurückkehren kann. Immer noch auf Spring Cloud 1.0.2.

bearbeiten 100 Tage später

Update für, wo wir am Ende. Weiter entlang unser Mantra zu vermeiden Eigentum Templating, .. innerhalb Code Richtlinien und Praktiken durchzusetzen und ohne Eureka-first-Konzept fort, verlassen wir PropertySourceLocator und verwendet einfach eine SpringApplicationRunListener wie folgt:

public class OurFrameworkProperties implements SpringApplicationRunListener { 
    : 
    public void started() { 
    if (TestCaseUtils.isRunningFromTestCase()) { 
     System.setProperty("spring.cloud.config.failFast", "false"); 
     System.setProperty("spring.cloud.config.enabled", "false"); 
     System.setProperty("eureka.client.enabled", "false"); 
    } else { 
     // set production values same way 
    } 
    } 
} 

Eine Warnung, dass dieser gestartet () wird tatsächlich zweimal innerhalb des Federcodes aufgerufen (sobald keine Programmargumente mehr übergeben werden), jedes Mal, wenn Ihre Spring-Anwendung ausgeführt wird oder eine Aktuatoraktualisierung() erhält.

Answer 1

Wenn Ihr PropertySourceLocator in spring.factories aufgeführt wird (ich nehme als BootstrapConfiguration), dann braucht es eine @Component (oder vielleicht sogar ein @Configuration) zu sein.