Konfiguration verwalten

[DaBe1812]

Hallo,

ich habe mal eine Stelle im Code, die ich aktuell nicht so schön finde und wollte mal eure Meinung dazu hören, wie man es eleganter lösen könnte.
Wir haben eine Webanwendung, die hinter einem Loadbalancer auf zwei Servern läuft, die wiederum auf eine gemeinsame Datenbank zugreifen.

Für die Konfiguration der Anwendung habe ich dazu eine Tabelle.

Mittlerweile habe ich für jeden Use-Case eine Klasse gebaut die sich ihren Teil aus der Tabelle lädt. Dies mache ich mittlerweile On Demand, also jedes Mal, wenn die Konfiguration gebraucht wird, wird sie neu von der Datenbank geladen. Hatte das ganze mal ApplicationScoped gemacht, wegen der Performance, dann hatten wir aber das Problem, dass wenn man im laufenden Betrieb etwas an der Konfiguration geändert hat, dann hat das der andere Server nicht mitbekommen und lief weiter mit der alten Konfiguration.

Jetzt hatte Baeldung sich diesen Monat mal die Guava Bibliothek vorgenommen und da auch mal den Cache vorgestellt. Dem kann ich quasi Elemente hinzufügen und denen ein Haltbarkeitsdatum verpassen. so könnte man theoretisch erzwingen, dass die Konfiguration alle X neu geladen wird.

Gibt es da vielleicht eine Lösung, um das bei redundanten Servern zu erzwingen? Wie haltet ihr eure Konfiguration? Gibt es dafür vielleicht ein Framework?

 

[KonradN]

Ich würde diese Problematik erst einmal etwas tiefer hinterfragen, denn das hört sich nach einer Optimierung an und da ist immer die Frage, ob das überhaupt Sinn macht.

Daher ist die Fragestellung: Was wird denn an Konfiguration wie oft geladen?
Ich habe in der Vergangenheit vor allem mit Anwendungen zu tun gehabt, die sehr intensiv mit Daten gearbeitet haben. Und da war dann sicher gestellt:

• Die Verbindung hin zur Datenbank war immer schnell (bei uns 10 GBit), also in einem RZ und an einem Managed Switch hingen die Systeme. (Schnell war immer in Bezug auf die Clients die zugriffen ... die waren aber auch im RZ mit 10GBit dran ...)
• Die Zugriffe bezüglich Konfiguration waren extrem geringer als die Zugriffe bezüglich der Daten. Daher macht es da keinen Sinn zu optimieren, wenn da sowohl die Anzahl der Abfragen als auch die Datenmenge zu gering ist.

==> Vor einer Optimierung daher wirklich prüfen, ob sowas überhaupt Sinn macht!

Wenn es da eine Notwendigkeit gibt, dann ist hier die Frage: was sind die genauen Anforderungen? Und wie / wer ändert die Konfiguration?

Und ob ich wegen sowas ein Framework oder eine Library einbauen würde? Das ist aus meiner Sicht mit Kanonen auf Spatzen geschossen!

Einfach mal ein paar Möglichkeiten, die einfach zu benennen sind.
a) Angenommen, Du kannst eine Anforderung definieren, dass nach einer Änderung die Konfiguration innerhalb von x min/sec/... übernommen werden muss. Da Sessions vom LB fest einem System zugeordnet werden, kann es kleine Abweichungen zwischen den Systemen geben. Dann kann man die Konfiguration im ConfigService (sowas in der Art wirst Du ja vermutlich haben) cachen mit einem Zeitstempel und bei Zugriffen wird dann geprüft, ob die Daten neu geladen werden müssen oder ob die gecachte Version genommen wird. (Wobei da bei vielen Anfragen pro Sekunde ggf. ein Cache von wenigen Sekunden schon eine gute Entlastung bringen könnte...)
b) Ähnlich wie a) aber die Server sollen möglichst gleichzeitig aktualisieren. Dann Lösung wie a) nur eben wird zu festen Zeitpunkten neu geladen. Und die Systeme werden ja die Zeit synchronisiert haben ....
c) Wenn die Änderungen einen festen Weg haben, dann kann jeder Server auch die Konfiguration lokal halten. Und bei Änderungen kann man dann über einen Config-Endpunkt das neu laden beauftragen
d) Falls Änderungen generell geplant werden (Change Management und so? ITIL wird ja meist doch umgesetzt), dann gibt es immer eine Planung. Änderungen können dann eingeplant werden. Da es hier in der Regel um Tage geht, kann man da also problemlos regelmäßig nach Änderungen schauen. Dann weiss der Client immer genau, wann etwas einzuspielen ist und kann dies gezielt machen ... (Aber das klingt mir jetzt nach Overkill - aber evtl. ist das ja die Anforderung...)
....

So kann ich Stunden lang rum spinnen (Ich habe zu viel Zeit im Bereich CM zugebracht und dort Tools bereit gestellt )

Also in Kürze sind die Fragestellungen einfach:

• Was sind die genauen Anforderungen?
• Was ist das konkrete Problem (wird also nicht erfüllt)

 

[DaBe1812]

Also die Fragestellung ist schonmal gut.
Bei der Konfiguration geht es u.a. um Zugangsdaten zu anderen Systemen, also wenn sich da ein Passwort ändert, dann sollte das in beiden Systemen direkt hinterlegt sein.
Ich habe dafür aus das caching vom Eclipselink deaktiviert, weil das trotz neuladen dazu geführt hat, dass Server B nicht davon ausgegangen ist, dass es eine Änderung gegeben haben könnte und deswegen die alten Daten einfach aus dem Cache genommen hat.

Es geht auch nicht um wirklich viele Daten. Meistens nur so ca. 4 - 5 Datensätze, die zu einer Konfiguration gehören. Also ist dafür eine neue Lösung evtl. wirklich Overkill.

Das aktuelle System funktioniert und Performancemäßig hab ich tatsächlich schlimmere Baustellen. War nur dadurch, dass ich die Möglichkeiten von Guava gesehen habe am überlegen, ob da noch etwas geht.

Bei ConfigService musst du mich mal abholen. Ich habe ein paar Klassen für die unterschiedlichen Arten von Konfigurationen, z.B. Mail-Konfiguration, Webservice-Konfiguration(en), Timer-Konfigurationen, ...
Dazu habe ich eine Klasse, die aus der Datenbank genau die Konfiguration ließt, die ich anhand eines übergebenen Schlüssels haben möchte.

Also technisch gesehen sage ich ich brauche eine new MailConfig und er lädt mir die 4 Zeilen aus der Config Tabelle, die als Schlüssel MAIL in der Spalte stehen haben.

 

[KonradN]

Bei ConfigService musst du mich mal abholen. Ich habe ein paar Klassen für die unterschiedlichen Arten von Konfigurationen, z.B. Mail-Konfiguration, Webservice-Konfiguration(en), Timer-Konfigurationen, ...

Da ging es mehr um die Layer, die ich so kenne und die man oft (Bei so typischen Web Anwendungen, die ich kenne) findet. Wenn man sich eine Spring Boot Anwendung anschaut, dann hast du oft (so es einen Web Part gibt) einen Controller. Das ist sozusagen der Endpunkt nach außen. Da kommt aber keine Business Logik oder so rein.
Dann hast du einen Service. Das ist der Part mit der Business Logik.
Und zuletzt hast du den Datenbank Layer. Das ist bei Spring Boot in der Regel das Repository Interface.
Controller greift auf den Service zu. Der Service greift auf das Repository zu.

Das ist aber jetzt eine Gliederung, die evtl. für dein Projekt so nicht zutrifft. Das ist keinerlei Wertung sondern das war jetzt nur eine Erklärung zu meiner Wortwahl / Formulierung, die evtl. zu spezifisch für mein übliches Arbeitsumfeld war so dass ich da etwas vorausgesetzt habe, das schlicht nicht da sein muss. Man kann Projekte natürlich anders strukturieren und andere Frameworks mögen andere Wege gehen! Hoffe, ich konnte es etwas erläutern und damit die erste Antwort verständlicher machen.

 

[Oneixee5]

Meiner Meinung nach fehlen hier noch Infos, z.B. um was für ein System es sich hier überhaupt handelt. Im JEE-Bereich verwendet man Cluster. Cluster werden über einen Master organisiert. Dieser kümmert sich um die Verteilung und Aktualisierung der Konfiguration.
Spring (Boot) hat mehrere eingebaute Mechanismen für solche Belange, z.B. über Actuator.
Bei Mikroservices startet man einfach neue Instanzen mit geänderter Konfiguration wenn sie benötigt werden.
Ich sehe hier eher ein konstruiertes Problem.

 

[DaBe1812]

@KonradN: gut, dann hab ich nix verpasst, nur das Wording hat mich verwirrt.
@Oneixee5: das mit dem Clustern wäre schön, keine Ahnung, ob ich hier dazu die Möglichkeit habe. Muss ich mich mal schlau lesen.
Spring hat damals nicht geklappt aus Gründen. Ich hoffe dieses Jahr die Zeit zu finden von Eclipse auf IntelliJ um zu ziehen, dabei will ich das Projekt komplett neu aufsetzen u.a. von ANT auf Maven umstellen, dabei werde ich nochmal probieren Spring zu verwenden. Muss mich nach 4 Jahren nur mal wieder einlesen/ ein Demoprojekt bauen, damit ich wieder auf Spring klar komme.

Und ich denke auch, dass ich mir da in einem Anflug von Selbstzweifel ein Problem konstruiert habe, dass eigentlich gar nicht existent ist.

Im Fall von Microservices wäre es ja auch so, dass bei jeder Verwendung des Microservice die Konfiguration neu geladen wird. Die Tabelle ist sauber Strukturiert und nicht allzu groß, d.h. das kostet theoretisch keine merkliche Performance.