19. September in Moskau das erste thematische Treffen HUG (Highload++ User Group), das sich den Microservices widmete. Es gab eine Präsentation „Operating Microservices: Size Matters, Even If You Have Kubernetes“, in der wir Flants umfangreiche Erfahrung im Betrieb von Projekten mit Microservice-Architektur teilten. Erstens wird es für alle Entwickler nützlich sein, die darüber nachdenken, diesen Ansatz in ihrem aktuellen oder zukünftigen Projekt zu verwenden.
Vorstellen (50 Minuten, viel informativer als der Artikel) sowie der Hauptauszug daraus in Textform.
Hinweis: Video und Präsentation sind auch am Ende dieses Beitrags verfügbar.
Einführung
Normalerweise hat eine gute Geschichte einen Anfang, eine Haupthandlung und einen Schluss. Dieser Bericht ist eher ein Vorspiel, und zwar ein tragisches. Es ist auch wichtig zu beachten, dass es einen Außenblick auf Microservices bietet. Betriebs.
Ich beginne mit dieser Grafik, deren Autor (im Jahr 2015) Martin Fowler:
Es zeigt, wie bei einer monolithischen Anwendung, die einen bestimmten Wert erreicht, die Produktivität zu sinken beginnt. Der Unterschied zu Microservices besteht darin, dass die anfängliche Produktivität bei ihnen geringer ist, mit zunehmender Komplexität jedoch die Verschlechterung der Effizienz bei ihnen nicht so stark spürbar ist.
Ich werde dieses Diagramm für den Fall der Verwendung von Kubernetes ergänzen:
Warum ist eine Anwendung mit Microservices besser? Denn eine solche Architektur stellt hohe Anforderungen an die Architektur, die wiederum durch die Fähigkeiten von Kubernetes perfekt abgedeckt werden. Andererseits werden einige dieser Funktionen für einen Monolithen nützlich sein, insbesondere weil der typische Monolith heute nicht gerade ein Monolith ist (Einzelheiten folgen später im Bericht).
Wie Sie sehen können, unterscheidet sich das endgültige Diagramm (wenn sich sowohl monolithische als auch Microservice-Anwendungen in der Infrastruktur mit Kubernetes befinden) nicht sehr vom Original. Als nächstes werden wir über Anwendungen sprechen, die mit Kubernetes betrieben werden.
Nützliche und schädliche Microservices
Und hier ist die Hauptidee:
Was ist normal Microservice-Architektur? Es sollte Ihnen echte Vorteile bringen und Ihre Arbeitseffizienz steigern. Wenn wir zur Grafik zurückkehren, ist sie hier:
Wenn du sie anrufst nützlich, dann wird es auf der anderen Seite des Diagramms sein schädlich Microservices (beeinträchtigt die Arbeit):
Zurück zur „Hauptidee“: Soll ich meiner Erfahrung überhaupt vertrauen? Seit Anfang dieses Jahres habe ich gesucht 85 Projekte. Nicht alle davon waren Microservices (etwa ein Drittel bis die Hälfte davon verfügten über eine solche Architektur), aber das ist immer noch eine große Zahl. Wir (Firma Flant) als Outsourcer schaffen es, eine große Vielfalt an Anwendungen sowohl in kleinen Unternehmen (mit 5 Entwicklern) als auch in großen Unternehmen (~500 Entwickler) entwickeln zu sehen. Ein zusätzlicher Vorteil besteht darin, dass wir diese Anwendungen im Laufe der Jahre live erleben und weiterentwickeln können.
Warum Microservices?
Auf die Frage nach den Vorteilen von Microservices gibt es eine vom bereits erwähnten Martin Fowler:
- klare Grenzen der Modularität;
- unabhängiger Einsatz;
- Freiheit, Technologien zu wählen.
Ich habe viel mit Softwarearchitekten und -entwicklern gesprochen und gefragt, warum sie Microservices brauchen. Und ich habe meine Liste ihrer Erwartungen erstellt. Folgendes ist passiert:
Wenn wir einige der Punkte „in Empfindungen“ beschreiben, dann:
- klare Grenzen der Module: Hier haben wir einen schrecklichen Monolithen, und jetzt wird alles ordentlich in Git-Repositorys angeordnet, in denen alles „in den Regalen“ liegt, das Warme und das Weiche nicht vermischt werden;
- Bereitstellungsunabhängigkeit: Wir werden in der Lage sein, Dienste unabhängig einzuführen, sodass die Entwicklung schneller voranschreitet (neue Funktionen parallel veröffentlichen);
- Entwicklungsunabhängigkeit: Wir können diesen Microservice einem Team/Entwickler und diesen anderen einem anderen zur Verfügung stellen, wodurch wir uns schneller entwickeln können;
- боHöhere Zuverlässigkeit: Wenn eine teilweise Verschlechterung auftritt (ein Mikrodienst von 20 fällt aus), funktioniert nur eine Taste nicht mehr und das System als Ganzes funktioniert weiterhin.
Typische (schädliche) Microservice-Architektur
Um zu erklären, warum die Realität nicht unseren Erwartungen entspricht, werde ich Folgendes vorstellen kollektiv ein Abbild einer Microservice-Architektur basierend auf Erfahrungen aus vielen verschiedenen Projekten.
Ein Beispiel wäre ein abstrakter Online-Shop, der mit Amazon oder zumindest OZON konkurrieren soll. Seine Microservice-Architektur sieht folgendermaßen aus:
Aus mehreren Gründen werden diese Microservices auf verschiedenen Plattformen geschrieben:
Da jeder Microservice autonom sein muss, benötigen viele von ihnen eine eigene Datenbank und einen eigenen Cache. Die endgültige Architektur ist wie folgt:
Welche Konsequenzen hat es?
Fowler hat das auch — über die „Bezahlung“ für die Nutzung von Microservices:
Und wir werden sehen, ob unsere Erwartungen erfüllt wurden.
Klare Grenzen der Module...
Aber Wie viele Microservices müssen wir tatsächlich reparieren?die Änderung einführen? Können wir überhaupt herausfinden, wie alles ohne einen verteilten Tracer funktioniert (schließlich wird jede Anfrage von der Hälfte der Microservices verarbeitet)?
Es gibt ein Muster“„, und hier stellte sich heraus, dass es sich um einen verteilten Schmutzklumpen handelte. Um dies zu bestätigen, finden Sie hier eine ungefähre Darstellung des Ablaufs von Anfragen:
Unabhängigkeit bei der Bereitstellung...
Technisch ist es gelungen: Wir können jeden Microservice separat ausrollen. In der Praxis muss jedoch berücksichtigt werden, dass es immer ausgerollt wird viele Microservices, und das müssen wir berücksichtigen die Reihenfolge ihres Rollouts. Im Allgemeinen müssen wir in einem separaten Schaltkreis testen, ob wir das Release in der richtigen Reihenfolge ausrollen.
Freiheit bei der Wahl der Technologie...
Sie ist. Denken Sie daran, dass Freiheit oft an Gesetzlosigkeit grenzt. Dabei ist es sehr wichtig, Technologien nicht nur zum „Spielen“ auszuwählen.
Unabhängigkeit der Entwicklung...
Wie erstellt man eine Testschleife für die gesamte Anwendung (mit so vielen Komponenten)? Aber Sie müssen es trotzdem auf dem neuesten Stand halten. All dies führt dazu, dass tatsächliche Anzahl der Testkreise, was wir grundsätzlich enthalten können, fällt minimal aus.
Wie wäre es, wenn man das alles lokal bereitstellen würde? Es stellt sich heraus, dass der Entwickler seine Arbeit oft unabhängig, aber „nach dem Zufallsprinzip“ erledigt, weil er warten muss, bis die Schaltung zum Testen frei ist.
Separate Skalierung...
Ja, aber es ist im Bereich des verwendeten DBMS begrenzt. Im gegebenen Architekturbeispiel wird Cassandra keine Probleme haben, MySQL und PostgreSQL jedoch schon.
Боgrößere Zuverlässigkeit...
Nicht nur, dass der Ausfall eines Microservices in der Realität oft die korrekte Funktion des gesamten Systems beeinträchtigt, sondern es gibt auch ein neues Problem: Es ist sehr schwierig, jeden Microservice fehlertolerant zu machen. Da Microservices unterschiedliche Technologien verwenden (Memcache, Redis usw.), muss man für jede Technologie alles durchdenken und implementieren, was natürlich möglich ist, aber enorme Ressourcen erfordert.
Messbarkeit laden...
Das ist sehr gut.
Die „Leichtigkeit“ von Microservices...
Wir haben nicht nur riesige Netzwerk-Overhead (DNS-Anfragen nehmen zu usw.), aber auch aufgrund der vielen Unterabfragen, die wir gestartet haben Daten replizieren (Store-Caches), was zu einer erheblichen Speichermenge führte.
Und hier ist das Ergebnis der Erfüllung unserer Erwartungen:
Aber das ist noch nicht alles!
Denn:
- Höchstwahrscheinlich benötigen wir einen Nachrichtenbus.
- Wie erstellt man zum richtigen Zeitpunkt ein konsistentes Backup? Der Einzige wirklich Die Option besteht darin, den Verkehr hierfür zu deaktivieren. Aber wie geht das in der Produktion?
- Wenn es um die Unterstützung mehrerer Regionen geht, ist die Organisation der Nachhaltigkeit in jeder einzelnen Region eine sehr arbeitsintensive Aufgabe.
- Es stellt sich das Problem, zentralisierte Änderungen vorzunehmen. Wenn wir beispielsweise die PHP-Version aktualisieren müssen, müssen wir uns auf jedes Repository festlegen (und davon gibt es Dutzende).
- Das Wachstum der betrieblichen Komplexität ist ohne weiteres exponentiell.
Was tun mit all dem?
Beginnen Sie mit einer monolithischen Anwendung. Fowlers Erfahrung dass fast alle erfolgreichen Microservice-Anwendungen als Monolith begannen, der zu groß wurde und dann kaputt ging. Gleichzeitig kam es bei fast allen von Anfang an als Microservices aufgebauten Systemen früher oder später zu ernsthaften Problemen.
Ein weiterer wertvoller Gedanke ist, dass man sich sehr gut auskennen muss, damit ein Projekt mit einer Microservice-Architektur erfolgreich ist und Themenbereich und wie man Microservices erstellt. Und der beste Weg, ein Fachgebiet zu erlernen, besteht darin, einen Monolithen zu erstellen.
Was aber, wenn wir uns bereits in dieser Situation befinden?
Der erste Schritt zur Lösung eines Problems besteht darin, ihm zuzustimmen und zu verstehen, dass es sich um ein Problem handelt, unter dem wir nicht mehr leiden wollen.
Wenn wir im Falle eines überwucherten Monolithen (wenn wir keine Möglichkeit mehr haben, zusätzliche Ressourcen dafür zu kaufen) ihn abschneiden, dann ergibt sich in diesem Fall die gegenteilige Geschichte: Wenn übermäßige Microservices nicht mehr helfen, sondern behindern – Überschuss abschneiden und vergrößern!
Zum Beispiel für das oben besprochene kollektive Bild ...
Befreien Sie sich von den fragwürdigsten Microservices:
Kombinieren Sie alle für die Frontend-Generierung verantwortlichen Microservices:
... in einen Microservice, geschrieben in einer (modernen und normalen, wie Sie selbst denken) Sprache/Framework:
Es wird ein ORM (ein DBMS) und zunächst ein paar Anwendungen haben:
... aber im Allgemeinen kann man dort noch viel mehr übertragen und erhält folgendes Ergebnis:
Darüber hinaus führen wir in Kubernetes all dies in separaten Instanzen aus, was bedeutet, dass wir die Auslastung weiterhin messen und separat skalieren können.
zusammenfassend
Schauen Sie sich das Gesamtbild an. Sehr oft entstehen all diese Probleme mit Microservices, weil jemand ihre Aufgabe übernommen hat, aber „mit Microservices spielen“ wollte.
Im Wort „Microservices“ ist der „Mikro“-Teil überflüssig.. Sie sind nur deshalb „Mikro“, weil sie kleiner sind als ein riesiger Monolith. Aber betrachten Sie sie nicht als etwas Kleines.
Und als letzter Gedanke kehren wir zum ursprünglichen Diagramm zurück:
Eine Notiz darauf geschrieben (oben rechts) läuft darauf hinaus, dass Die Fähigkeiten des Teams, das Ihr Projekt realisiert, stehen immer im Vordergrund – Sie werden eine Schlüsselrolle bei Ihrer Wahl zwischen Microservices und einem Monolithen spielen. Wenn das Team nicht über genügend Fähigkeiten verfügt, aber mit der Entwicklung von Microservices beginnt, wird die Geschichte definitiv fatal sein.
Videos und Folien
Video aus der Rede (~50 Minuten; leider werden die zahlreichen Emotionen der Besucher, die die Stimmung des Berichts maßgeblich bestimmt haben, leider nicht vermittelt, aber so ist es):
Präsentation des Berichts:
PS
Weitere Berichte auf unserem Blog:
- «» (Dmitry Stolyarov; 28. Mai 2018 auf der RootConf);
- «» (Dmitry Stolyarov; 7. November 2017 auf HighLoad++);
- «» (Dmitry Stolyarov; 6. Juni 2017 bei RootConf);
- «» (Dmitry Stolyarov; 8. November 2016 auf HighLoad++);
- «» (Dmitry Stolyarov; 31. Mai 2016 auf der RootConf).
Folgende Publikationen könnten Sie auch interessieren:
- «";
- «";
- «".
Source: habr.com