Programm strukturieren

Hallo zusammen,

ich hab in einem anderen Forum schon mal interessante Ideen und Input für mein Problem erhalten und möchte noch weiteren Input bekommen (falls das hier jemandem bekannt vorkommt :)).

Ich habe derzeit einen (verteilten) Monolithen und möchte den aufbrechen um flexibler zu werden.
Wir haben derzeit immer wieder Probleme das System zu erweitern, da die Services zu abhängig von einander sind. Zb möchten wir den MainService updaten, müssen aber warten bis alle anderen Services fertig sind da sie den brauchen (dazu mehr weiter unten)

Ich versuche mal zu schildern was wir dezeit haben. Grundsätzlich Spring Boot, das möchte ich auch gern weiterhin einsetzen und „echte Microservices“ zu bauen

Unser System macht im groben folgendes:

Wir beliefern Werkstätten mit Produktdaten von Ersatzteilherstellern. Jede Werkstatt hat bei uns eine Tenante datenbank auf einem zentralen DB Server. Darin werden alle Artikeldaten gespeichert. Jeder User hat 1 oder mehrere Ersatzteillieferanten.

User System holt im fixen Intervall beim Hersteller Daten ab (API, CSV, TXT jeder hat da eine andere Anbindung) .Wir haben nun für jeden Hersteller einen eigenen Service, welcher die Daten abholt, aufbereitet und an den MainService übergibt, welcher die Daten in die Datenbank (tenant per schema) speichert, updated usw. Dabei haben wir wesentliche Logiken im MainService zb Preise berechnen (Kunde gibt an xxx Aufschlag drauf machen), Bestände updaten und dann noch viele weitere Einstellmöglichkeiten die der User treffen kann, wie zb „Artikelnamen nicht updaten“

Wenn die Daten in der Kunden DB angekommen sind, gehts weiter - der Kunde kann die Daten bearbeiten, erweitern etc. und diese dann in sein Werkstattprogramm übertragen (API). Bestandsänderungen übergeben wir direkt an das Kundensystem, da muss er. nix manuell machen.

Nun nehmen wir an, es ist ein fetter Bug im MainService und es berechnet alle Preise falsch. Allerdings läuft noch ein Import mit 100.000 Artikeln auf einen Kunden. Wenn ich jetzt den MainService runter fahre, wars das dann ist nix mehr erreichbar. Kein Importservice kann arbeiten und das Frontend bekommt auch nix mehr, weil das Frontend über REST Daten vom MainService holt.

Diese Abhängigkeit möchte ich lösen und alles wesentlich loser gekoppelt haben, damit mal mal was updaten kann ohne andere Services zu beeinflussen.

Eine Idee wäre es, jedem Importservice eine DB zu geben, damit jeder Importservice die Artikeldaten für seine User bei sich speichert, berechnet usw. Problem hier ist aber, dass wenn ich was nachträglich einbauen will alle 50 Import-Services anfassen muss um da zb ein DB Feld ein zu bauen oder die Preisberechnung zu ändern etc.

Eine andere Idee wäre es einen einzigen Importservice zu bauen, welcher alle Hersteller kennt und weiß wie die Daten da abzuholen sind.

Irgendwie hab ich null Plan welche Richtung die richtige ist. Wichtig ist skalierbarkeit und Stabilität

Es ist schwierig, da jetzt eine Ferndiagnose abzugeben, zu dem Thema gibt es hunderte Bücher und Artikel, und zehntausende überbezahlte Consultants.

Der eine Ratschlag, den ich dir geben kann, wird dir wahrscheinlich nicht gefallen: Versuche dich erst einmal von den technischen Details zu lösen, versuche eine Vision(*) zu entwickeln. Warum? Es hört sich so an, als ob ihr einige Schmerzen habt, und jetzt soll mit Microservices alles gut werden. Aber die eigentliche Frage sollte nicht sein „wie komme ich am schnellsten zu Microservices?“, sondern „Welche Art von Microservices brauche ich, wenn überhaupt?“. Es kann sein, dass eure Anforderungen auch mit einem Monolithen erfüllt werden können, nur nicht mit dem Modell „Big Ball of Mud“, sondern Layern, hexagonaler Architektur u.s.w. Bei den Microservices gibt es ebenfalls enorm viele Möglichkeiten, diese zu strukturieren und zu orchestrieren, und wenn man nicht aufpasst, fängt man sich hässliche Nachteile ein. Die richtige Reihenfolge ist also: Problemanalyse -> welche Architektur löst diese Probleme -> wie komme ich dahin. Meiner Meinung nach seid ihr dabei, den dritten Schritt vor dem zweiten zu tun. Es scheint im Tagesgeschäft oft so zu sein, dass man für eine ausführliche Analyse und Planung keine Zeit hat, aber ohne das bekommt man am Ende wieder nur halbgare Lösungen.

Anfangen würde ich damit, alle Datenflüsse (die ja das Hauptproblem zu sein scheinen) zu erfassen, zu schauen, wie man den Ablauf vereinfachen könnte, was alles asynchron ablaufen könnte, was in Transaktionen ablaufen muss, Ausfallsicherheit u.s.w. Dann würde ich schauen, welche Architektur das am besten abbilden könnte, und erst dann würde ich schauen, wie ich dahin komme.

(*) Ja, ich weiß, wer Visionen hat, sollte zum Arzt gehen…

Ich meine das Thema gab es schon mal vor ueber einem Jahr oder so?

Ach ja, hier: Microservice Design

Meine Ansichten zu MS vs Monolithen haben sich seitdem nicht geaendert, sondern verfestigt :slight_smile:

Die Frage fuer mich ist, ob das eine „echte“ Anforderung ist oder eine „nice to have“ Idee, den MS kommen fuer einen heftigen Preis was Komplexitaet etc. betrifft.

Mit MS kann eine Firma/Organisation skalieren, aber umsonst ist das nicht, jeder MS muss in einem eigenen Code Repo leben, einen eigenen Release und Deployment Zyklus haben, dafuer sorgen dass die API Vorwaerts- und Rueckwaertskompatibel ist, duerfen keinen Code teilen etc. pp.
Das hat alles recht grosse Auswirkungen darauf wie Teams ihre Arbeit auf einander abstimmen und der zusaetzliche Aufwand ist IME enorm.

Monolithen sind da recht simpel im Vergleich, eine Codebasis, eine SW Repo, eine release und Deployment Zyklus.
API festlegen geht auch in Monolithen, wenn man das da nicht schafft, dann aendert sich das mit MS nicht sondern wird zum Blocker.

1 Like

Danke euch, stimmt ich hatte schon mal einen Post. Das hast du dir gemerkt? ;D

In der Tat ist aktuell der Datenfluss ein Problem als auch die Last. Wir hatten früher einen Monolithen, den wir aber null skalieren konnten. Das hat ein Teil so viel Ram benötigt, dass andere eingeschränkt wurden. Mit Micro konnten wir das aus der Welt schaffen und einfach mehr RAM auf den Service geben, der. Hunger hatte.

Hallo,
ich würde den MainService so schlank wie nur möglich machen. Alle Aufgaben die nicht zwingend vom MainService selbst gemacht werden müssen, werden an andere Services delegiert. Der MainService dient dann nur noch als Vermittler. Immer wenn man dann später noch mal am MainService was ändern muss, ist das vermutlich ein Zeichen dafür, dass man noch nicht stark genug ausgeräumt hat. Im besten Fall muss man dann dort nie mehr ran und die Bugs sind in den anderen Services.
Sicher wird es auch dann Abhängigkeiten geben, dass bei einem Bug vieles nicht mehr läuft, aber eben nicht mehr alles, da der MainServices selbst stabil ist.