Frage an die Entwickler unter euch


Milchbroetchen

Milchbroetchen

Hello :-)
Hallo Zusammen,
folgendes vorhaben, es soll ein System entstehen mit folgenden Sachen: API, Frontend, Backend, User Verwaltung. Nun möchte ich jedes der einzelne aufgelisteten als Microservice umsetzen und dann als Container in Kubernetes laufen lassen. Das Vorhaben ist dieses, dass alle einzelnen Services auf einen weiteren Services zugreifen sollen nennen wir es einfach Datastore. Als Beispiel User1: greift über die RestAPI auf Funktionen zurück und erstellt z.B. einen Server.

Nun muss der User ja zunächst Authentifiziert werden d.H. wenn er sich registriert hat über das Frontend soll der User natürlich gespeichert werden z.B. nun soll die API natürlich ermitteln ob es den Seer gibt und er die nötigen Rechte hat, sprich er soll mit dem Microservices "User Verwaltung" kommunizieren. Danach soll dies dann zurück gegeben werden und der User kann seine Server anlegen, den neuen Datensatz soll die API natürlich dann anlegen und z.B. im Datastore speichern woraus sich das Backend dann diese Daten zieht und dem User seine Ressourcen zuordnet. Greift der User nun über das ControlPanel auf die Serververwaltung zu soll das Frontend sich die Daten aus dem Datastore ziehen und daraus halt die Website generieren und Ihm seine Ressourcen anzeigen etc. Das gleiche gilt natürlich auch wenn der Enduser Sachen über das Control Panel realisiert. Nun die Frage, wie kann man so etwas vernünftig und vor allem Modular realisieren, mir wurde mal nahegelegt nicht mittels RabbitMQ auseinander zu setzen, kennt das jemand und kann dazu was sagen? Wie kümmere ich mich um die Kommunikation zwischen den einzelnen Bereichen? Soll jeder Services eine eigene API bekommen, über welche dieser mit den anderen Services agiert? Hoffe Ihr versteht ein wenig mein vorhaben.

Beste grüße
 
Klingt für mich erst mal danach, dass Du ein SSO-System umsetzen willst gegen das die einzelnen Microservices prüfen können, ob der jeweilige User aktuell die notwendigen Rechte hat (bzw. welcher Benutzergruppe der zugehörig ist und anhand eigener Daten weiß das System dann, was der User darf oder kann).

'ne MQ sehe ich da an der Stelle eigentlich weniger - die ist eher für eigentliche Prozesskommunikation ($user will $xy) zuständig, nicht dafür, dass die Prozesse sich Berechtigungen austauschen (darf $user $xy?) - das weiß eigentlich ggf. nach Rückfrage über das AuthToken gegen den SSO jedes System selbst...

gibt aber jede Menge Ansätze sowas umzusetzen...
 
In der Annahme dass wir hier über HTTP-Verkehr reden würde ich JWT-Header empfehlen um die Session zu authentifizieren, validieren, Zeitrahmen setzen... und das ganze ohne bei jeder einzelnen Anfrage viel Ressourcenleistung in DB-Lookups zu stecken. Ein reverse-proxy welcher alle Microservices regroupiert kann zB die notwendige JWT-Validierung bereits durchführen.

Für granulare Rechteverwaltung ist natürlich JWT etwas ungeeignet, deine Services müssen dazu noch immer intern bei einem zentralen Authorisierungsdienst oder der Datenbank nachfragen.

Wie @marce bereits anmerkte sind alle MQ-Formen eher für Status- und Nachrichtenaustausch gedacht und werden zumal gerne für asynchrone Verarbeitungen im Publisher-Consumer Konstrukt verwendet. Du kannst den direkten Datenfluss zwischen API und Authorisierungsserver über eine MQ entkoppeln aber es erhöht nur Komplexität und Latenzen ohne direkt ersichtlichen Vorteil.

Rein strukturell ist die mir geläufigste Form:

Client -->[reverse-proxy]-->[loadbalancer]-->apiserver-->[loadbalancer]-->authserver
 
Ich danke sehr für eure Antworten und werde mir dazu mal einiges ansehen und ein Konzept zusammen mit Team Kollegen erarbeiten. Welches hoffentlich auch hinterher auf dem Kubernetes Cluster läuft, danke nochmals an @d4f :)
 
You must log in or register to reply here.
Back
Top