Microservices in der Praxis

Question

Ich habe das Konzept der Microservices schon eine ganze Weile studiert und verstehe, was sie sind und warum sie notwendig sind.

kurze Auffrischung

Auf den Punkt gebracht, Monolith Anwendung in unabhängige einsetzbare Einheiten zerlegt wird, von denen jeder typischerweise macht es eigene Web-API ist und verfügt über eine eigene Datenbank ist. Jeder Dienst erfüllt eine einzige Verantwortung und macht es gut. Diese Dienste kommunizieren über synchrone Webdienste wie REST oder SOAP oder verwenden asynchrones Messaging wie JMS, um eine Anforderung in Synergie zu erfüllen. Unsere Monolith-Anwendung ist zu einem verteilten System geworden. In der Regel werden alle diese feinkörnigen APIs über ein API-Gateway oder einen Proxy zur Verfügung gestellt, der als eine Single-Point-of-Entry-Fassade fungiert, die Sicherheits- und Überwachungsaufgaben ausführt.

Hauptgründe für die Anpassung von Microservices sind eine hohe Verfügbarkeit, ein Update ohne Ausfallzeiten und eine hohe Leistung durch horizontale Skalierung eines bestimmten Service und eine lose Kopplung im System, was die Wartung vereinfacht. Außerdem werden die IDE-Funktionalität, der Build- und Bereitstellungsprozess wesentlich schneller und es ist einfacher, das Framework oder sogar die Sprache zu ändern.

Microservices geht Hand in Hand mit Clustering- und Containerisierungstechnologien wie Docker. Jeder Microservice kann als Docker-Container gepackt werden, um ihn auf jeder Plattform zu betreiben. Hauptbegriffe Clustering sind Service Discovery, Replikation, Lastausgleich und Fehlertoleranz. Docker Swarm ist ein Clustering-Tool, das diese containerisierten Dienste orchestriert, sie zusammenfügt und alle diese Tasks unter der Haube deklarativ verarbeitet und den gewünschten Status des Clusters beibehält.

Klingt einfach und einfach in der Theorie, aber ich verstehe immer noch nicht, wie dies in der Praxis zu implementieren, auch ich kenne Docker Swarm ziemlich gut. Sehen wir uns ein konkretes Beispiel an.

Hier ist die Frage

Ich baue eine stark vereinfachte Java-Anwendung mit Frühlings-Boot, unterstützt von MySQL Datenbank. Ich möchte ein System aufbauen, wo Benutzer eine Webseite von Service A bekommt und ein Formular abschickt. Service A wird einige Manipulation an Daten tun und sendet es an Service B, die Daten weiter manipulieren, in die Datenbank schreiben, etwas zurückgeben und am Ende einige Antwort zurück zum Benutzer gesendet wird.

Das Problem ist jetzt, Service A nicht weiß, wo finden Service B noch Service B wissen, wo Datenbank finden (weil sie an einem beliebigen Knoten im Cluster eingesetzt werden könnten) Ich weiß nicht, wie ich die Spring-Boot-Anwendung konfigurieren soll. Das erste, was mir in den Sinn kommt, ist DNS zu verwenden, aber ich finde keine Tutorials, wie man ein solches System im Docker-Schwarm einrichtet. Wie können Verbindungsparameter im Frühjahr für die Bereitstellung verteilter Clouds richtig konfiguriert werden? Ich habe über das Projekt Spring Cloud recherchiert, verstehe aber nicht, ob es der Schlüssel für dieses Dilemma ist.

Ich bin auch verwirrt, wie Datenbanken bereitgestellt werden sollten.Sollten sie im Cluster leben, zusammen mit dem Service eingesetzt werden (möglicherweise mit Hilfe von Docker Compose), oder ist es besser, sie auf herkömmliche Weise mit festen IPs zu verwalten?

Die letzte Frage betrifft den Lastenausgleich. Ich bin verwirrt, wenn es für jeden Dienst mehrere Load Balancer oder nur einen einzigen Master Load Balancer geben sollte. Sollte dem Lastenausgleich eine statische IP-Adresse zugewiesen sein, die auf einen Domänennamen verweist, und alle Benutzeranforderungen auf diesen Lastenausgleich abzielen? Was ist, wenn Load Balancer fehlschlägt, macht es nicht alle Anstrengungen, die Dienste sinnlos zu skalieren? Ist es sogar notwendig, einen Load Balancer mit Docker Swarm einzurichten, da dieser über ein eigenes Routing-Mesh verfügt? Welcher Knoten Endbenutzer sollte dann zielen?

Answer 1

Wenn Sie einen Docker Swarm verwenden, müssen Sie sich keine Gedanken über die DNS-Konfigurationen machen, da diese bereits vom Overlay-Netzwerk verarbeitet werden. Angenommen, Sie haben drei Dienste:

A B C

A ist Ihre DB, B könnte der erste Dienst, Daten zu sammeln, und C, dass die Daten zu empfangen und aktualisieren die Datenbank (A)

docker network create \ 
    --driver overlay \ 
    --subnet 10.9.9.0/24 \ 
    youroverlaynetwork 

docker service create --network youroverlaynetwork --name A 
docker service create --network youroverlaynetwork --name B 
docker service create --network youroverlaynetwork --name C 

Sobald alle Dienste erstellt werden, können sie sich aufeinander beziehen direkt beim Namen

Diese Anforderungen sind Lastenausgleich gegen alle Repliken der Container in diesem Overlay-Netzwerk. So kann A immer eine IP für B erhalten durch Bezugnahme auf „http://b“ oder einfach nur durch den Hostnamen B. Aufruf

Wenn Sie mit Last zu tun haben in Docker ausgleichend, ein Schwarm Service ist bereits Last intern ausgeglichen. Sobald Sie einen Dienst zum Abhören von Port 8018 definiert haben, hören alle Schwarm-Hosts den Port 8018 ab und leiten diese Route im Round-Robin-Modus an einen Container weiter.

Es ist jedoch immer noch die beste Vorgehensweise, einen Anwendungs-Load-Balancer vor den Hosts im Falle eines Hostfehlers zu installieren.