Skalierung von Monolithen im Vergleich zur Skalierung von Mikrodiensten

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

Nehmen wir an, wir hatten eine Anwendung bestehend aus 10 Mikrodiensten, von denen 9 jeweils zwei Instanzen (aus Redundanzgründen) und eine mit 4 Instanzen für die Lastverwaltung (Skalierbarkeit) hatten. Das Argument pro-microservice 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 eingesetzt wurden. Das System sollte in der Lage sein, die Last für den einen kritischen Teil zu bewältigen, da genügend Instanzen dafür vorhanden sind. Wenn Instanzen Programmlogik enthalten, die nicht benötigt wird, ist der einzige Nachteil, dass die Binärdatei und die Menge des benötigten RAM etwas größer sind. Andererseits sollte der Unterschied in den meisten Fällen nicht zu groß sein - zumindest nicht im Vergleich zum Rest des Stapels (denken Sie an Spring Boot). Die Oberseite eines skalierten Monoliths wäre ein einfacheres System ohne (die meisten) Irrtümer eines verteilten Systems.

Vermisse ich etwas?

microservices

— deamon
quelle

Wie groß von einem Monolithen redest du? Weil ich denke, dass es mehr als eine "etwas größere" Menge an RAM sein könnte. Ganz zu schweigen von der Bereitstellungszeit. Das Beheben eines Fehlers kann 22 statt 4 Bereitstellungen erfordern. Möglicherweise ist Ihr Monolith jedoch klein, und Bereitstellungen nehmen nicht viel Zeit in Anspruch, Datenbankmigrationen nehmen nicht viel Zeit in Anspruch usw.

— Thomas Owens

Ich habe keine Codezeilen gezählt, aber der Monolith hätte mehrere tausend Codezeilen (kein riesiges System). Der Ausgangspunkt meiner Überlegung war, dass die Größe des eigentlichen Anwendungscodes im Vergleich zu großen Frameworks wie Spring und Hibernate winzig ist. Die Anzahl der Bereitstellungen könnte tatsächlich geringer sein als bei Microservices, da bei 2 Instanzen bereits eine grundlegende Redundanz vorhanden wäre und mehr Instanzen der Skalierbarkeit dienen.

— Deamon

@deamon Beachten Sie, dass es beim Monolith-Ansatz keine Teile des Codes gibt, die in jeder Instanz völlig tot sind, sondern nur selten verwendeten Code. Jetzt verbraucht der Code selbst möglicherweise nur wenig Speicher, aber wenn er viele Objekte verwendet, die im Speicher zwischengespeichert sind, kann diese Menge erheblich anwachsen.

— Frank Hopkins

Beachten Sie, dass der Aufwand für das Ausführen von Code nicht unbedingt so hoch ist, wie Sie es aus Ihren Java-Anwendungen kennen, in denen häufig die gesamte JVM Teil des Service-Images ist.

— Frank Hopkins

Antworten:

Bei Microservices geht es nicht darum, die Prozessorlast zu reduzieren. Aufgrund des Kommunikationsaufwands und der Wiederholung von Funktionen, bei denen es sich früher um globalen Dienstprogrammcode handelte, wird die Prozessorlast in der Regel etwas erhöht .

Die Aufgabe der Abschaffung eines Monolithen besteht vielmehr 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 zu teuer, um durchführbar 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 entfernte Schnittstellen zu koppeln. In der Tat 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 wir das Beste aus einer suboptimalen Situation machen.

— Kilian Foth
quelle

Einverstanden. Der Grund für die Umstellung auf eine Microservice-Architektur ist größtenteils politischer Natur. Verteilte Last, Entkopplung sind Konsequenzen, keine Ursachen. Der eigentliche Nutzen der Microservices liegt beim SDLC und der Governance. Darüber hinaus ist die Architektur die logische Antwort auf einen Bedarf, der in den meisten Fällen aus der Marktstrategie des Unternehmens resultiert. Die Markteinführungszeit ist kürzer als bei Monolith-Architekturen, sodass das Unternehmen neue Strategien

— anwenden

Aus diesem Grund sollte sich jemand auch bei mittleren und kleinen Anwendungen nicht direkt an Microservices wenden. Der Mehraufwand und die zusätzliche Komplexität des Systems können in solchen Maßstäben sehr wohl mehr Zeit, Geld und Qualität kosten als ein monolithisches System.

— T. Sar - Reinstate Monica

»Wir tun es, weil wir müssen, weil die Komplexität uns überwunden hat und wir aus einer suboptimalen Situation das Beste machen.« Ja. Für mich nagelt das!

— Thomas Junk

Ich muss mit dem letzten Teil der Antwort nicht einverstanden sein. Micro-Services sind von Natur aus besser als ein Monolith, weil sie mehr als einen Computer verwenden

— Ewan

@ewan Sie können auch mehr als einen Computer mit Monolithen verwenden.

— Dämon

Sie haben größtenteils recht. Wenn Sie schnelle Dienste haben, die gleichmäßig geladen sind, können Sie sie auch 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 Service 5 2 Minuten lang 100% der CPU benötigt, möchten Sie diesen Service auf eine eigene Box verschieben, damit er nicht alle anderen Services blockiert, wenn er ausgeführt wird.

Wenn aufgrund des Ladevorgangs das Zeitlimit für Anrufe an den Service 5 überschritten wird, fallen nur einige Funktionen Ihrer App aus.

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

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

— Ewan
quelle

Der Punkt von Mikrodiensten ist 1) Trennung von Bedenken und 2) Verteilung der Last. Dies gibt uns im Wesentlichen die Freiheit, den bestmöglichen Black-Boxed-Service mit Technologien zu erbringen, die für diese Aufgabe spezifisch sind. Unsere Dienstleistungen können mehrsprachig sein - das heißt, 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. Insgesamt gesehen ermöglicht dies eine viel einfachere Codebasis für jeden Dienst, die leichter zu debuggen, zu verstehen und hinsichtlich der Leistung zu optimieren ist.

— Lewis A Sellers
quelle

Ich stimme teilweise zu. Dabei ging es mir nicht um Argumente für Microservices im Allgemeinen, sondern um Skalierbarkeit. In meinem speziellen Fall sind die Mikrodienste beispielsweise alle in derselben Technologie geschrieben. Während es möglich wäre, für jede Technologie eine andere zu verwenden, ist dies hier einfach nicht der Fall. Ich wollte sicherstellen, dass mir kein wichtiger Punkt zur Skalierbarkeit entgeht.

— Deamon