🥇 Mikrodienste: Größe ist entscheidend, selbst wenn Sie Kubernetes verwenden

19. September in Moskau statt das erste thematische Meetup HUG (Highload++ User Group), das den Microservices gewidmet war. Darin wurde der Vortrag „Betrieb von Microservices: Größe spielt eine Rolle, auch wenn Sie Kubernetes nutzen“ gehalten, in dem wir umfangreiche Erfahrungen des Unternehmens „Flant“ im Betrieb von Projekten mit mikroservice-basierter Architektur teilten. Er ist in erster Linie für alle Entwickler von Interesse, die über den Einsatz dieses Ansatzes in ihrem aktuellen oder zukünftigen Projekt nachdenken.

Wir präsentieren das Video mit dem Vortrag (50 Minuten, deutlich informativer als der Artikel), sowie eine umfassende schriftliche Zusammenfassung.

NB: Video und Präsentation sind auch am Ende dieses Beitrags verfügbar.

Einführung

Gewöhnlich hat eine gute Geschichte einen Anfang, einen Hauptplot und ein Ende. Dieser Vortrag ähnelt eher einem Anfang, und zwar einem tragischen. Außerdem ist es wichtig zu erwähnen, dass darin eine Perspektive auf Microservices aus der Sicht der Betriebsführung.

Ich beginne mit einem solchen Diagramm, dessen Autor (im Jahr 2015) wurde Martin Fowler ist:

Hier sieht man, dass bei einer monolithischen Anwendung, die eine bestimmte Größe erreicht, die Produktivität zu sinken beginnt. Mikrodienste hingegen haben von Anfang an eine niedrigere Produktivität, jedoch ist die Effizienzdegradation bei zunehmender Komplexität weniger auffällig.

Ich ergänze dieses Diagramm für den Fall der Verwendung von Kubernetes:

Warum hat die Anwendung mit Mikrodiensten profitiert? Weil eine solche Architektur strenge Anforderungen an das Design stellt, die durch die Möglichkeiten von Kubernetes hervorragend erfüllt werden. Andererseits wird ein Teil dieser Funktionalität auch für Monolithen nützlich sein, besonders weil ein typischer Monolith heutzutage nicht wirklich ein Monolith ist (Details folgen später im Bericht).

Wie zu sehen ist, unterscheidet sich das endgültige Diagramm (sowohl für monolithische als auch für mikrodienstbasierte Anwendungen in einer Kubernetes-Infrastruktur) nicht wesentlich von dem ursprünglichen. Im Folgenden werden wir über Anwendungen sprechen, die unter Verwendung von Kubernetes betrieben werden.

Nützliche und schädliche Mikrodienste

Und hier ist der Hauptgedanke:

Was ist also normal? Mikroservice-Architektur? Sie sollte Ihnen echten Nutzen bieten und die Effizienz steigern. Hier ist der entsprechende Verlauf:

Wenn man sie nützlich nennt,gibt es auf der anderen Seite des Verlaufs schädliche Mikroservice-Zusammensetzung (beeinträchtigt die Arbeit):

Zurück zur 'Hauptfrage': Sollte ich meinem Erlebnis überhaupt Vertrauen schenken? Seit Anfang dieses Jahres habe ich 85 Projekte. Nicht alle davon hatten eine mikroservicebasierte Architektur (etwa ein Drittel bis die Hälfte), aber es ist trotzdem eine große Anzahl. Wir bei Flandt als Outsourcing-Partner haben die Möglichkeit, eine breite Palette an Anwendungen zu beobachten, die sowohl in kleinen Unternehmen (mit 5 Entwicklern) als auch in großen (~500 Entwicklern) entwickelt werden. Ein weiterer Vorteil ist, dass wir sehen, wie sich diese Anwendungen über viele Jahre entwickeln und leben.

Warum Mikroservices?

Die Frage nach dem Nutzen von Mikroservices hat eine sehr konkrete Antwort von dem bereits erwähnten Martin Fowler:

klare Modulegrenzen;
unabhängiges Deployment;
Freiheit in der Technologienwahl.

Ich habe viel mit Architekten und Softwareentwicklern gesprochen und gefragt, warum sie Mikrodienste benötigen. Dabei habe ich eine Liste ihrer Erwartungen erstellt. Hier ist das Ergebnis:

Wenn ich einige dieser Punkte „gefühlsmäßig“ beschreiben würde, dann:

klare Grenzen der Module: wir haben hier ein unübersichtliches Monolith, und jetzt wird alles ordentlich in Git-Repositories aufgeteilt, in denen alles „geordnet“ ist, und nichts wird mit anderem vermischt;
Unabhängigkeit beim Deployment: Wir können die Dienste unabhängig ausrollen, sodass die Entwicklung schneller vorangeht (parallel neue Funktionen veröffentlichen);
Unabhängigkeit der Entwicklung: Wir können diesen Mikrodienst einem Team/Entwickler zuweisen, und das andere Team kann an einem anderen arbeiten, was uns ermöglicht, schneller zu entwickeln;
bgrößtengrößere Zuverlässigkeit: Wenn eine partielle Degradierung auftritt (ein Mikrodienst von 20 fällt aus), funktioniert nur ein Knopf nicht mehr, während das System insgesamt weiterhin operabel bleibt.

Typische (schädliche) Mikrodienstarchitektur

Um zu erklären, warum die Realität nicht so ist, wie wir es erwarten, präsentiere ich ein aggregiertes Bild der Mikrodienstarchitektur, basierend auf Erfahrungen aus zahlreichen verschiedenen Projekten.

Ein Beispiel wäre ein abstrakter Online-Shop, der plant, mit Amazon oder zumindest mit OZON zu konkurrieren. Seine mikroservicebasierte Architektur sieht folgendermaßen aus:

Aus verschiedenen Gründen sind diese Mikroservices auf unterschiedlichen Plattformen geschrieben:

Da jeder Mikroservice Autonomie haben sollte, benötigen viele von ihnen ihre eigene Datenbank und ihren eigenen Cache. Die finale Architektur sieht dann so aus:

Was sind die Konsequenzen?

Fowler hat dazu einen Artikel über die 'Kosten' der Verwendung von Mikroservices geschrieben:

Und wir werden sehen, ob unsere Erwartungen erfüllt wurden.

Klare Grenzen der Module...

Aber wie viele Mikroservices wir tatsächlich anpassen müssen, um eine Änderung zu implementieren? Können wir überhaupt verstehen, wie alles funktioniert, ohne einen verteilten Tracer (denn jede Anfrage wird von der Hälfte der Mikroservices bearbeitet)?

Es gibt das Muster eines 'großen Klumpens Schmutz', und hier haben wir sogar einen verteilten Klumpen Schmutz. Hier ist eine beispielhafte Illustration, wie die Anfragen verlaufen:

Unabhängigkeit bei der Bereitstellung...

Technisch gesehen ist dies erreicht: Wir können jeden Microservice einzeln bereitstellen. Praktisch müssen wir jedoch berücksichtigen, dass immer mehrere Microservices, wobei wir auch die Reihenfolge ihrer Bereitstellungberücksichtigen müssen. Im Idealfall sollten wir in einem separaten Umfeld testen, ob wir die Version in der richtigen Reihenfolge bereitstellen.

Die Freiheit der Technologieauswahl…

Die haben wir. Es ist jedoch wichtig, daran zu denken, dass diese Freiheit oft an Grenzen stößt. Es ist entscheidend, Technologien nicht nur auszuwählen, um "damit zu spielen".

Unabhängigkeit der Entwicklung…

Wie erstellt man eine Testumgebung für die gesamte Anwendung (aus so vielen Komponenten)? Und wir müssen sie auch aktuell halten. All dies führt dazu, dass die reale Anzahl der Testumgebungen, die wir grundsätzlich unterhalten können, minimal.

ist. Und alles lokal bereitzustellen? Es stellt sich heraus, dass der Entwickler oft unabhängig arbeitet, aber "ins Blaue hinein", weil er warten muss, bis ein Testumfeld verfügbar wird.

Getrennte Skalierung…

Ja, aber es ist in Bezug auf die verwendeten Datenbanksysteme begrenzt. Im gegebenen Architekturbeispiel gibt es mit Cassandra keine Probleme, aber mit MySQL und PostgreSQL werden diese bestehen.

Bgrößtenessere Zuverlässigkeit…

Nicht nur, dass der Ausfall eines Mikrodienstes in der Regel die korrekte Funktion des gesamten Systems beeinträchtigt, sondern es gibt auch ein neues Problem: Es ist sehr schwierig, jeden Mikrodienst ausfallsicher zu machen.Denn in Mikrodiensten kommen unterschiedliche Technologien (Memcache, Redis usw.) zum Einsatz, für jede muss alles durchdacht und umgesetzt werden, was zwar möglich ist, aber enorme Ressourcen erfordert.

Messbarkeit der Last…

Damit ist wirklich alles in Ordnung.

Die „Leichtigkeit“ von Mikrodiensten…

Wir haben nicht nur enorme Netzwerkoverheadkosten (die DNS-Anfragen usw. erhöhen), sondern aufgrund der vielen Unteranfragen haben wir begonnen, Daten zu replizieren (Caches zu speichern), was zu erheblichen Speicheranforderungen führte.

Und hier ist das Ergebnis, das unseren Erwartungen entspricht:

Aber das ist noch nicht alles!

Denn:

Wahrscheinlich benötigen wir eine Nachrichtenbus.
Wie erstellt man ein konsistentes Backup zu einem bestimmten Zeitpunkt? Die einzige reale Eine Möglichkeit besteht darin, den Datenverkehr dafür auszuschalten. Aber wie macht man das in einer Produktionsumgebung?
Wenn es um die Unterstützung mehrerer Regionen geht, ist es eine äußerst mühsame Aufgabe, in jeder von ihnen Stabilität zu gewährleisten.
Es entsteht das Problem zentralisierter Änderungen. Wenn wir beispielsweise die PHP-Version aktualisieren müssen, ist es erforderlich, in jedes der Dutzend Repositories einen Commit vorzunehmen.
Das Wachstum der betrieblichen Komplexität erscheint auf den ersten Blick exponentiell.

Was soll man mit all dem machen?

Beginnen Sie mit einer monolithischen Anwendung.Fowler’s Erfahrung sagen zeigt, dass praktisch alle erfolgreichen Mikrosysteme mit einem Monolithen begonnen haben, der zu groß wurde und dann aufgeteilt wurde. Gleichzeitig hatten fast alle Systeme, die von Anfang an als Mikrosysteme konzipiert wurden, früher oder später ernsthafte Probleme.

Ein weiterer wertvoller Punkt ist, dass Sie, um ein Projekt mit einer Mikrosystemarchitektur erfolgreich zu machen, sowohl das Fachgebiet als auch die Erstellung von Mikrosystemen sehr gut verstehen müssen. Der beste Weg, um das Fachgebiet zu lernen, ist, einen Monolithen zu erstellen.Was tun, wenn wir uns bereits in einer solchen Situation befinden?

Was tun, wenn wir uns bereits in dieser Situation befinden?

Der erste Schritt zur Lösung eines Problems besteht darin, es anzuerkennen und zu verstehen, dass es ein Problem ist und dass wir nicht länger leiden wollen.

Wenn wir bei einem aufgeblähten Monolithen (wenn wir nicht mehr in der Lage sind, Ressourcen dafür zu kaufen) ihn aufteilen, ergibt sich hier eine gegenteilige Situation: wenn übermäßige Mikroservices nicht mehr helfen, sondern hinderlich sind — schneiden Sie das Überflüssige ab und fassen Sie zusammen.!

Beispielsweise für das oben genannte Sammelbild...

Befreien Sie sich von den fragwürdigsten Mikroservices:

Kombinieren Sie alle Mikroservices, die für die Generierung des Frontends verantwortlich sind:

... in einen einzigen Mikroservice, der in einer (modernen und akzeptablen, wie Sie es selbst sehen) Sprache/Framework geschrieben ist:

Er wird ein ORM (eine DBMS) und zunächst ein paar Anwendungen haben:

... und tatsächlich kann dort viel mehr übertragen werden, was zu folgendem Ergebnis führt:

Dabei starten wir in Kubernetes all dies als separate Instanzen, was bedeutet, dass wir immer noch die Last messen und sie separat skalieren können.

Zusammenfassend

Betrachten Sie das Bild umfassender. Sehr oft treten all diese Mikroservice-Probleme auf, weil jemand seine Aufgabe übernommen hat, aber 'mit Mikroservices spielen' wollte.

Im Wort „Mikrodienste“ ist der Teil „mikro“ überflüssig.Sie sind „mikro“ nur, weil sie kleiner sind als ein riesiges Monolith. Aber man sollte sie nicht als etwas Kleines betrachten.

Und um zum ursprünglichen Diagramm zurückzukehren:

Die Anmerkung dazu (rechts oben) führt zu der Erkenntnis, dass die Fähigkeiten des Teams, das Ihr Projekt umsetzt, immer an erster Stelle stehen. Genau sie werden eine entscheidende Rolle in Ihrer Wahl zwischen Mikrodiensten und Monolithen spielen. Wenn das Team nicht die nötigen Fähigkeiten hat, aber anfängt, Mikrodienste zu entwickeln, wird die Geschichte sicher fatal enden.

Videos und Folien

Das Video von dem Vortrag (~50 Minuten; leider vermittelt es nicht die zahlreichen Emotionen der Besucher, die stark die Stimmung des Vortrags prägten, aber so ist es):