So verwenden Sie den Config-Server zum Bereitstellen von Ressourcenpaketen für Microservices

Question

Wir verwenden den Spring Cloud-Konfigurationsserver in unserem Projekt mit mehreren Microservices. Nachdem der Konfigurationsserver eingerichtet wurde, speichern wir nun alle Eigenschaften für alle Mikrodienste in einem zentralen Git-Repository. Jeder Microservice kann seine eigene Eigenschaftendatei basierend auf dem Anwendungsnamen und den Profilen abrufen. Wir versuchen, unsere Ressourcenbündel im zentralen Repository zu speichern und diese Ressourcenpakete vom config-Server an Microservices zu liefern. Unsere Ressourcenbündel enthalten Eigenschaftendateien wie messages_en.properties, messages_es.properties, messages_cn.properties usw. Wir können ein Ressourcenbündel über das Profil zum Konfigurationsserver laden, es fungiert jedoch als Eigenschaftendatei. Wir verwenden Ressourcenpaket in Geschwindigkeitsvorlage für GUI. Wie

<div class="top-content"> 
         <div class="intro-box"> 
          <h1 class="font-light">#**springMessageText("welcome.text2","W**elcome to <br/><strong>Our Website!")</strong> 
</h1> 

Könnte jemand vorschlagen, wie sie es getan haben? oder einen Link zur Verwendung des Config-Servers zum Laden von n mithilfe des Ressourcenpakets?

Answer 1

Ich würde vorschlagen, Spring Cloud Config-Server für Eigenschaften zu verwenden, die zwischen Umgebungen wechseln (dev/staging/prod/....) oder für konfigurierbare Eigenschaften wie Thread-Pool-Größe, DB-Verbindung Poolgröße, .... aber nicht für Nachrichtenbündel, da das Hinzufügen/Umbenennen von Schlüsseln auch davon ausgeht, dass eine Vorlage aktualisiert oder hinzugefügt werden müsste, was die Erstellung eines neuen Artefakts/einer neuen Binärdatei erfordert.

Answer 2

Ich hatte das gleiche Problem, ich um es funktionierte durch eine neue Unterklasse von ReloadableResourceBundleMessageSource und überwiegender protected List<String> calculateFilenamesForLocale(String basename, Locale locale)

Die überschriebene Methode abzuleiten füge die locale an der Basis URL-Varianten so für die Basis-URL http://localhost:8888/app-default und Locale.ENGLISH wir bekommen

• http://localhost:8888/app-default
• http://localhost:8888/app_en-default
• http://localhost:8888/app_en_GB-default

Es wird angenommen, dass der letzte Index von '-' im Basisnamen der Anfang des Profils ist.