it-swarm.com.de

Architektur einer Microservice-basierten Web-App

Ich bin verwirrt über den Punkt, an dem eine Webanwendung in Mikrodienste abweicht - ist dies auf URL- oder Modellebene? Angenommen, ich habe eine monolithische App, die 3 Seiten bedient. Angenommen, jede Seite dient einer separaten Anwendung und ich möchte sie mit ihren eigenen Microservices unterstützen. Welche von diesen ist der richtige Weg, um eine Microservice-basierte Architektur zu implementieren:

  • Ich erstelle drei verschiedene Apps (Microservices), die jeweils die (Route, Controller, Modelle, Vorlagen) für eine der Seiten enthalten. Und dann, je nachdem, welche Seite angefordert wird, leite ich die Anfrage zu dieser bestimmten App. Dies bedeutet, dass die gesamte Seite von der Datenbank bis zum HTML-Code von einer separaten App bereitgestellt wird. Grundsätzlich werden verschiedene Seiten auf derselben Website vollständig von verschiedenen Apps im Backend bedient.
  • Die 3 Microservices behandeln nicht das UI-Zeug, sondern nur die Daten für ihre Verwendungszwecke (Modelle, Controller, keine Vorlagen) und legen sie über eine REST-API offen. Ich habe eine öffentliche App. Diese App fragt die drei verschiedenen Apps (Microservices) nur nach den Daten ab und erstellt dann die HTML-Seiten, die an den Browser zurückgegeben werden. Alle Seiten einer Web-App werden in diesem Fall von einer einzigen App bedient, die intern drei verschiedene Microservices verwendet.

enter image description here

26
shreyj

Sie haben Schwierigkeiten, wie Sie Ihre Microservices modellieren.

In Bezug auf Mikrodienste ist der zweite Ansatz am besten geeignet, der seine Logik über die API verfügbar macht.

Denken Sie immer daran, wenn Sie Ihre Mikrodienste modellieren, die folgenden Fakten.

  • Loose Coupling : Wenn Dienste lose gekoppelt sind, sollte eine Änderung an einem Dienst keine Änderung an einem anderen erfordern. Der Kernpunkt dieses Microservice-Dings besteht darin, eine Änderung an einem Dienst vornehmen und bereitstellen zu können, unabhängig davon, ob ein anderer Teil des Systems geändert werden muss. Das ist wirklich sehr wichtig.

  • Starker Zusammenhalt : Wir möchten, dass verwandtes Verhalten zusammen sitzt, und nicht verwandtes Verhalten, das anderswo sitzt. Warum? Wenn wir das Verhalten ändern wollen, möchten wir es an einer Stelle ändern und diese Änderung so schnell wie möglich freigeben. 

8
DeivinsonTejeda

Wie im Software Engineering üblich, ist die Antwort, es kommt darauf an. Ich kann mir im Moment keinen Grund vorstellen, aber Option 1 könnte in bestimmten Szenarien nützlich sein.

In Anbetracht der formalen Definition von Microservices wird dies bei Option 2 jedoch besser veranschaulicht. Ein Hauptvorteil von Microservices besteht darin, sie wieder verwenden zu können. Unterschiedliche Anwendungen haben unterschiedliche Anforderungen und Anforderungen an die Darstellung der Informationen. Wenn Ihre Microservices eine JSON-Darstellung Ihrer Daten erhalten, erhalten Sie mehr Flexibilität beim Formatieren dieser Informationen.

4
Trein

Das API-Gateway-Muster von Microservice apigateway ist der erste Punkt, von dem aus Sie die Anrufe an verschiedene Dienste verteilen oder weiterleiten können 

2
sapan

Wir implementieren derzeit eine Architektur ähnlich Ihrer zweiten Option. Wir sind dabei auf folgende Komplikationen gestoßen: (Fühlen Sie sich frei, dass sich jeder daran beteiligen kann, da es immer noch ein work in progress ist)

  • Es gibt technisch immer noch eine monolithische App in Ihrem System (die dem Benutzer zugewandte App). Jedes Mal, wenn eine Änderung in der REST -API vorgenommen wird, müssten Sie die nach vorne gerichtete App ändern, um diese neuen Änderungen zu verarbeiten. Lassen Sie mich nicht einmal anfangen, wie Sie dahinter einen neuen Microservice einführen. Grundsätzlich gilt: Je mehr Mikrodienste Sie hinter sich lassen, desto größer wird das API-Gateway. ( https://www.nginx.com/blog/building-microservices-using-an-api-gateway/ )

Das API-Gateway hat auch einige Nachteile. Es ist eine weitere hochverfügbare Komponente, die entwickelt, bereitgestellt und verwaltet werden muss. Es besteht auch das Risiko, dass das API-Gateway zu einem Engpass bei der Entwicklung wird. Entwickler müssen das API-Gateway aktualisieren, um die Endpunkte der einzelnen Microservices verfügbar zu machen. Es ist wichtig, dass der Prozess zur Aktualisierung des API-Gateways so gering wie möglich ist. Andernfalls müssen Entwickler in der Warteschlange warten, um das Gateway zu aktualisieren. Trotz dieser Nachteile ist es für die meisten realen Anwendungen sinnvoll, ein API-Gateway zu verwenden.

  • Zur Wiederverwendbarkeit habe ich eine Abstraktionsebene entworfen, die ein eindeutiges Verhalten für die Kommunikation mit jedem Microservice definiert. Eine konkrete Implementierung für jeden Microservice. Dies führte zu einer weiteren Komplexitätsebene, da wir jetzt die so genannten "RPC-Connectors" zusammen mit dem entsprechenden Microservice beibehalten mussten. Persönlich kostete dies viel Zeit für Entwickler, da sie neben dem jeweiligen Microservice auch den Connector warten mussten. Wenn einer davon nicht mehr aktuell ist, schlägt die öffentliche App fehl. Für Änderungen am Connector muss außerdem eine öffentliche App neu erstellt werden (derzeit haben wir die Connectors als Jar-Abhängigkeiten definiert). 
  • Während dies in einem anderen Beitrag und in einem Blog erwähnt wird, wird die Fremdschlüsselbeziehung zum Chaos, wenn mehrere Mikrodienste mit der eigenen Datenbank arbeiten. (Datenbank pro Servicemuster) Ihre Front-App steht jetzt vor dem Problem, dass sie zusammengefügt werden müssen. ("Ich brauche diese Daten, aber ich muss diese Schlüssel in jedem Mikroservice nachschlagen, um zu sehen, wer was hat.") Ich sage nicht, dass dies der richtige Weg ist, aber wenn wir es mit mehreren zurückgegebenen Zeilen zu tun haben Jede der IDs muss von einem Microservice individuell aufgelöst werden. Ich bin nicht sicher, wie effizient dies ist. Ich würde mich über Vorschläge freuen.
1
Chad