it-swarm.com.de

Skalierung von Monolithen im Vergleich zur Skalierung von Mikrodiensten

Eines der häufigsten Argumente für die Verwendung von Microservices ist eine bessere Skalierbarkeit. Aber ich frage mich, ob dieses Argument wirklich gültig ist.

Nehmen wir an, wir hatten eine Anwendung, die aus 10 Mikrodiensten bestand, von denen 9 jeweils zwei Instanzen (aus Redundanzgründen) und eine von ihnen 4 Instanzen hatten, um die Last zu bewältigen (Skalierbarkeit). Das Argument für den Mikroservice lautet dann, dass Sie diesen Miroservice unabhängig von den anderen Diensten skalieren können.

Nehmen wir jedoch an, dass alle 10 Mikrodienste Module in einem einzelnen Monolithen waren und dass mehrere (z. B. 22 wie die Summe von oben) Instanzen dieses Monolithen bereitgestellt wurden. Das System sollte in der Lage sein, die Last für den einen kritischen Teil zu bewältigen, da dafür genügend Instanzen vorhanden sind. Wenn Instanzen Programmlogik enthalten, die nicht benötigt wird, wäre der einzige Nachteil, dass die Binärdatei und die Menge der benötigten RAM] etwas größer wären. Andererseits sollte der Unterschied nicht zu groß sein In den meisten Fällen - zumindest nicht im Vergleich zum Rest des Stacks (denken Sie an Spring Boot). Die Oberseite eines skalierten Monlith wäre ein einfacheres System ohne (die meisten) Irrtümer eines verteilten Systems.

Vermisse ich etwas

15
deamon

Bei Microservices geht es nicht darum, die Prozessorlast zu reduzieren. Aufgrund des Kommunikationsaufwands und der Wiederholung von Funktionen, die früher globaler Dienstprogrammcode waren, erhöht sich die Prozessorlast normalerweise etwas etwas.

Der Zweck der Abschaffung eines Monolithen besteht viel mehr darin, ein komplexes Funktionssystem überhaupt warten, bereitstellen und ausführen zu können. Sobald Ihr System eine bestimmte Größe erreicht hat, wird das Kompilieren, Testen, Bereitstellen usw. eines Monolithen einfach zu teuer, um realisierbar zu sein und gleichzeitig eine angemessene Betriebszeit aufrechtzuerhalten. Mit Microservices können Sie ein System stückweise aktualisieren, neu starten oder zurücksetzen.

Machen Sie keinen Fehler, wir schreiben keine Microservices, weil es von Natur aus eine bessere Lösung ist, Dinge lose über Remote-Schnittstellen zu koppeln. Tatsächlich ist der Verlust einer starken Typ- und Konsistenzprüfung, die ein Monolith liefern könnte, oft ein Hauptnachteil. Wir tun es, weil wir müssen, weil die Komplexität uns überwunden hat und das Beste aus einer suboptimalen Situation macht.

21
Kilian Foth

Sie sind meistens richtig. Wenn Sie schnelle Dienste haben, die gleichermaßen geladen sind, können Sie sie auch alle auf allen Boxen installieren. Es ist nicht so schön wie eine Box pro Service, aber es spart Geld.

Jedoch. Sobald Sie ein Ungleichgewicht haben, sagen wir, dass Dienst 5 2 Minuten lang 100% der CPU beansprucht, möchten Sie diesen Dienst auf eine eigene Box verschieben, damit er nicht alle anderen Dienste blockiert, wenn er ausgeführt wird.

Wenn aufgrund des Ladevorgangs eine Zeitüberschreitung bei Serviceanrufen 5 auftritt, schlagen nur einige Funktionen Ihrer App statt aller fehl.

Jetzt können Sie dasselbe mit einem gut modularisierten Monolithen tun. Installieren Sie alle Dienste, leiten Sie jedoch nur den Datenverkehr von Dienst 5 zu einem von ihnen weiter. Während Sie den Dienstverkehr nicht an die anderen Boxen weiterleiten.

Aber normalerweise sind Monolithen von Natur aus keine lose Sammlung von Diensten, die zufällig auf derselben Box installiert sind. Zwischen den Modulen werden Speicheraufrufe ausgeführt, die zum Ausfall der App führen.

3
Ewan

Der Punkt von Mikrodiensten ist 1) Trennung von Bedenken und 2) Lastverteilung. Dies gibt uns im Wesentlichen die Freiheit, mit Technologien, die für diese Aufgabe spezifisch sind, den bestmöglichen Black-Box-Service zu bieten. Unsere Dienstleistungen können mehrsprachig sein - das ist in verschiedenen Programmiersprachen auf verschiedenen Stapeln geschrieben. Verschiedene Teams können an jedem Service arbeiten, ohne zu wissen, wie die anderen über den Vertrag ihrer API hinaus arbeiten. Dies ermöglicht insgesamt eine viel einfachere Codebasis für jeden Dienst, die einfacher zu debuggen, zu verstehen und für die Leistung zu optimieren ist.

1
Lewis A Sellers