Die Entwicklung der Zerlegung: von Linux-Servern zu Kubernetes

Was reizt Entwickler so sehr an Microservices? Dahinter steckt keine revolutionäre Technologie, die Vorteile gegenüber dem Monolithen sind umstritten. Nur die Leichtigkeit, mit der Sie mit modernen Entwicklungs- und Bereitstellungstools Systeme erstellen können, die auf Tausenden von Servern ausgeführt werden können. Wir schlagen vor, den Weg bis zum gegenwärtigen Zeitpunkt zu verfolgen, an dem die Entwicklung und Bereitstellung eines solchen verteilten Systems von einem Entwickler möglich ist. Über die Entwicklung von Linux-Containern, Docker und Kubernetes, die Rolle, die Linux-Container, Docker und Kubernetes gespielt haben, entwickelt Alexander Trekhlebov holonavt , Unternehmensarchitekt der Promsvyazbank , seit mehr als 15 Jahren Software. Begann mit C ++ und wechselte dann zu Java. Kürzlich entwickelte er ein Banking-Backend auf der Spring Cloud-Plattform.




Wenn wir uns an die ersten Implementierungen der Skriptausführung (Java Script, VB Script) als Teil der Anzeige von Seiten in einem Browser erinnern, waren dies Anweisungen mit einem Thread. Das gleiche JavaScript - es ist Single-Tasking. Wenn JS im Rahmen einer Webseite ausgeführt wird und eine der ausführbaren Anweisungen fehlschlägt oder verzögert, wird der gesamte Code eingefroren, wenn alles auf der Seite geschieht. Und Sie können nichts tun, nur die Seite und manchmal den Browser oder das gesamte Betriebssystem schließen oder neu laden.


Offensichtlich war es nicht sehr praktisch. Besonders wenn man bedenkt, dass Multitasking / Multithreading bereits überall vorhanden war: Prozessoren, Betriebssysteme, Anwendungen (es sei denn, das erste Betriebssystem für mobile Geräte war Single-Tasking) und JS war immer noch Single-Threaded. Was ist dann passiert? Verschiedene Frameworks tauchten nacheinander auf, auf die eine oder andere Weise, um dieses Problem zu lösen. Facebook machte React, Google veröffentlichte Angular.


Multitasking Storm Frontend und Backend


Wie macht man Multitasking aus einem Single-Tasking-System? Nehmen Sie Anweisungen entgegen und verteilen Sie sie auf verschiedene Streams. Überwachen Sie diese Streams natürlich. Sicher erinnern Sie sich noch daran, wie in einer der FB-Versionen plötzlich die Möglichkeit auftauchte, gleichzeitig eine Nachricht zu schreiben und Änderungen auf dem Band zu überwachen. Und wenn plötzlich das Band fiel, funktionierten die Nachrichten weiter. Zu diesem Zeitpunkt erschien die erste Benutzeroberfläche auf der modularen Oberfläche von React. Mit Hilfe des Frameworks begann Multitasking sofort zu funktionieren.


Was hat das alles mit Microservices zu tun? Als die Benutzeroberfläche von Internetbanken begann, eine ziemlich breite Funktionalität bereitzustellen, wurde das Einfrieren und vor allem der Fall der Anwendung für die Benutzer zu einem schockierenden Ereignis. Immerhin ist es eine Sache, als Facebook festgefahren ist, und eine andere Sache - als Sie gerade eine Hypothekenzahlung getätigt haben und das Guthaben auf Ihrem Konto nicht angezeigt wurde, weil ein Fehler bei der Form des Kontostands aufgetreten ist.


Eine einfache Idee kam auf - unabhängige Benutzeroberflächenelemente, mit denen Angular und React an gleichermaßen unabhängige Backend-Elemente angehängt werden können. Jedes unabhängige Backend-Element ist ein Microservice, der skaliert, nach einem Fehler ansteigen usw. kann.



Es ist wichtig, die Benutzeroberfläche korrekt zu erstellen, damit sie abhängig von den verfügbaren Backend-Komponenten geändert wird. Wenn im Backend etwas für Sie nicht funktioniert, wird die entsprechende Funktionalität auf der Benutzeroberfläche nicht oder standardmäßig angezeigt. Sie können die Schriftfarbe in Grau ändern oder ein leeres Schild mit der Aufschrift "Kontostandinformationen sind nicht verfügbar" anzeigen. Rufen Sie morgen zurück ". Tatsächlich trägt eine solche Kombination von UI-Elementen mit Microservices dazu bei, die allgemeine Zuverlässigkeit und Skalierbarkeit einer Bankanwendung zu erhöhen.


Von der Titanic zum Docker


Meiner Meinung nach ist der Hauptgrund, warum Microservices trotz des erheblichen Speicherverbrauchs und des Overheads an Rechenleistung so populär geworden sind, die Zerlegung. Der Rest der Mikrodienste hat im Großen und Ganzen keine großen Vorteile gegenüber einem Monolithen. Nach meinem Verständnis erfolgt die Zerlegung, wenn die Funktion zum Starten und Bereitstellen in bestimmte unabhängige Blöcke unterteilt wird. Dies bedeutet, dass während der Rest der Blöcke funktioniert, einer aktualisiert werden kann, häufig ohne seine Arbeit zu stoppen (blau, grün - Bereitstellung), und eine zusätzliche Instanz auslösen kann.


Alle diese Technologen erschienen nicht gestern und nicht vorgestern. Verteilte Computerlösungen wurden in den Tagen der Mainframes entwickelt, da der Mangel an Computerressourcen fast sofort auftrat, sobald diese Ressourcen auftauchten.


Sie begannen herauszufinden, wie man all dies rational verteilt, zum Beispiel grafische Berechnungen an Silicon Graphix-Stationen. Es war alles teuer, und solche Lösungen standen nur großen Unternehmen zur Verfügung, ganz zu schweigen von einzelnen Entwicklern. Die Stationen selbst und die Serversoftware für sie waren sehr teuer, daher wurden die entsprechenden Funktionen für den Linux-Kernel entwickelt. Zum Beispiel wurde die Berechnung von Computergrafiken für die Szenen des Films "Titanic", der 1997 veröffentlicht wurde, auf Servern mit Alpha-Prozessoren unter Linux ausgeführt. Die meisten für den Betrieb verteilter Systeme erforderlichen Lösungen wurden zu diesem Zeitpunkt bereits entwickelt und getestet. Für einen Spezialisten war es jedoch immer noch schwierig, all diese Technologien einzusetzen. Die Montage, Lieferung und Unterstützung eines solchen Systems erforderte erhebliche Arbeitskosten.


Zuerst gab es nur physische Server, die irgendwie geroutet werden mussten, dann begann die Ära der Virtualisierung, virtuelle Maschinen erschienen, die Arbeit machte mehr Spaß, aber das Starten und Stoppen der virtuellen Maschine blieb eine ziemlich ressourcenintensive Aktion. Und ich wollte, dass es so schnell geht wie das Starten eines Prozesses innerhalb des Betriebssystems. Ein großer Schritt in Richtung der Veröffentlichung von Technologie "in the people" war mit dem Aufkommen von Linux-Containern verbunden.


Ein Linux-Container ist fast ein Systemprozess, hat aber eine eigene Netzwerkschnittstelle und vieles mehr, was ihn fast wie eine virtuelle Maschine gemacht hat. Warum fast? Weil die virtuelle Maschine in einer ziemlich isolierten Umgebung aufsteigt. Der Linux-Container verwendet das übergeordnete Betriebssystem. Jeder Container verfügt über eine eigene Version des Linux-Betriebssystems. Systemaufrufe werden jedoch an den Kernel des übergeordneten Betriebssystems gesendet.



Dies hat seine Vorteile: Wenn Sie einen LXC-Container erstellen, müssen Sie den Kernel nicht erneut starten. Die Arbeit mit LXC-Containern in ihrer ursprünglichen Form war jedoch sehr zeitaufwändig und unpraktisch. Eigentlich tauchte irgendwann Docker auf. Diese Entscheidung erforderte die Bereitstellung und Verwaltung von Linux-Containern und bot eine bequemere Benutzeroberfläche.


Das Aufkommen von Docker war der Anstoß für die weit verbreitete Verbreitung der Microservice-Architektur. Ja, die Technologien wurden für eine lange Zeit erfunden, aber die Möglichkeit ihrer bequemen Verwendung erschien erst in diesem Moment. Mit Docker kann ein Entwickler jetzt buchstäblich mehrere virtuelle Maschinen koppeln und ein verteiltes Computersystem organisieren und es dann mithilfe einiger Befehle dynamisch aktualisieren und skalieren.



Die Zerlegungsmöglichkeiten ermöglichten es einem großen Kreis von Entwicklern, einen Monolithen in eine Reihe von Mikrodiensten in Containern umzuwandeln. Hier traten jedoch neue Schwierigkeiten auf. Wenn mehrere Dutzend Container auf mehrere Server verteilt sind, müssen Sie sie irgendwie verwalten, begleiten und ihre Orchestrierung durchführen. Lösungen wie Docker Swarm und Kubernetes sind hier bereits erschienen. Der einzelne Entwickler erhielt ein neues leistungsstarkes Tool.


Microservices in Banken


Wie ist die Situation mit Microservices in der Bankenbranche? Wie viele sind beispielsweise erforderlich, um das Online-Banking zu unterstützen? Es gibt ein gutes Beispiel: In Großbritannien gibt es eine vollständig digitale Bank - Monzo, es gibt kein Backoffice, keine Filialen, keine Website, es ist im Wesentlichen alles in einer mobilen Anwendung. Alles begann mit 40 Microservices, dann stieg ihre Zahl auf 300, jetzt mehr.


Wenn Sie sich die Implementierung in der Promsvyazbank ansehen, dann haben wir Systeme mit bis zu 40 Microservices bereitgestellt.


Parallel dazu werden Entwicklungssysteme entwickelt, mit denen mithilfe der wenigen Codezeilen die Hauptkomponenten des Microservice-Systems entwickelt werden können, die ganz einfach skaliert und aktualisiert werden können. All diese Funktionen sind beim Aufbau maschineller Lernsysteme und bei der Analyse großer Datenmengen in Echtzeit (Cloud-Streaming usw.) sehr beliebt.


Alexander Trekhlebov wird im Bericht „Microservices - Fehlertoleranz basierend auf End-to-End-Modularität“ auf dem 404 Internet Workers Festival , das vom 6. bis 7. Oktober 2018 in Samara stattfinden wird, über seine Entwicklungserfahrung auf der Grundlage der Microservice-Architektur berichten.

Source: https://habr.com/ru/post/de425301/


All Articles