In einem früheren Beitrag haben wir darüber gesprochen, wie Cloud-Services zu einem ungeschriebenen Standard für die Bereitstellung von IT-Services geworden sind. Es ist leicht zu erraten, dass Unternehmen, die noch Geld mit Benutzeranwendungen verdienen möchten, neue Produkte anpassen und entwickeln müssen, die den Cloud-Native-Ansatz berücksichtigen. Für Entwickler ist dies jedoch definitiv eine positive Nachricht, da der Einsatz von Cloud-Technologien ihnen enorme neue Möglichkeiten eröffnet. Die Hauptsache ist, sie richtig entsorgen zu können.
Wenn eine Anwendung eine Umgebung bestellt
Wenn Sie den Cloud-Technologie-
Leitfaden bereits gelesen haben, werden Sie sich wahrscheinlich daran erinnern, dass die Virtualisierungstechnologie eine der „magischen Quellen“ für Clouds ist. Dank dessen muss der Entwickler praktisch nicht über die Parameter der Server nachdenken, auf denen seine Anwendung arbeiten wird. Warum Zeit damit verbringen, wenn ein ordnungsgemäß konfigurierter Hypervisor oder Container einen Computer mit nahezu allen Eigenschaften konfigurieren kann, die die Anwendung zum Arbeiten benötigt?
Die Entwicklung dieser Idee ist der IAC-Ansatz (Infrastructure as Code). Das Wesentliche besteht darin, Entwicklern oder Betriebsdiensten die gleichen Ansätze zu ermöglichen, die während der Entwicklungsphase zur Wartung der Infrastruktur verwendet werden. Sie können damit im Voraus gängige Software-Steuergeräte vorbereiten und diese Komponenten problemlos in neue Projekte integrieren.
Die Fähigkeiten moderner Rechenzentren ermöglichen es uns bereits, zur deklarativen Sprache des Infrastrukturmanagements überzugehen. Im Idealfall sollte die Anwendung den Ressourcenpool verwalten, den sie im Rechenzentrum belegt. Auf diese Weise kann der Entwickler nicht an die Einschränkungen gebunden sein, die mit dem Arbeiten mit der Infrastruktur verbunden sind, wenn eine vorherige Bestellung und ein Design erforderlich sind oder wenn dieselben Infrastrukturkomponenten in verschiedenen Projekten wiederholt werden.
Tatsächlich erstellt der Entwickler oder Techniker eine Pull-Anforderung, die die Konfiguration der virtuellen Maschine (Kernel, Speicher, Netzwerk, Vorlage usw.) enthält. Anschließend erstellt der Manager der virtuellen Umgebung die Maschine unabhängig oder erstellt eine neue Datenbankinstanz oder startet den vorinstallierten Dienst gemäß den Einstellungen in Datei. Dieser Ansatz ist eine echte Rettung bei der Arbeit mit Big Data und neuronalen Netzen. Anwendungen, die mit diesen Technologien verbunden sind, erfordern in einigen Fällen dynamisch wechselnde Speicher- und Prozessorleistungen.
Um beispielsweise ein Netzwerk zu trainieren, müssen Hunderte von Gigabyte an Informationen durch das Netzwerk „geleitet“ werden. In den Clouds können Sie auf Anfrage die erforderliche Kapazität dafür abrufen. Nach Abschluss der Schulung werden die Ressourcen an den Anbieterpool zurückgegeben, und der Entwickler muss nicht darüber nachdenken, wie er sie verwenden oder die Anwendung auf andere Weise konfigurieren soll, damit sie weiterhin mit einer geringeren Kapazität funktioniert.
Monolith vs. bestelltes Chaos
Aufgrund der Tatsache, dass sich die Clouds flexibel an die Anforderungen des Entwicklers anpassen können, vereinfacht dies theoretisch eine weitere Aufgabe - das Problem der Skalierung von Anwendungen. Warum theoretisch?
Leider ist die Aufgabe der Skalierung von Anwendungen nicht linear. Damit die Anwendung in Zeiten hoher Anwesenheit (oder Rechenleistung) mit enormen Belastungen fertig wird, reicht es nicht aus, nur zusätzlichen Speicher und zusätzliche Prozessorleistung bereitzustellen. Absolut jede herkömmliche Anwendung hat einen Schwellenwert, nach dem sie keine neuen Ressourcen mehr „verdauen“ und eine Leistungssteigerung nachweisen kann. Das Problem in diesem Fall sind nicht die Ressourcen, sondern die Architektur der meisten Programme.
Dieses Problem ist besonders akut für Anwendungen mit einer monolithischen Architektur, bei denen es sich tatsächlich um einzelne Binärdateien handelt. Die Vorteile dieses Ansatzes liegen auf der Hand: Monolithische Anwendungen sind recht einfach und linear. Alle Benutzerverhaltensszenarien können vorhergesagt, verfolgt und bei Bedarf debuggt werden.
Eine solche Einfachheit hat jedoch einen Preis. Erstens sind dies die oben erwähnten Probleme mit der Skalierung. Irgendwann funktioniert selbst die durchdachteste monolithische Anwendung nach einem Upgrade auf die Serverkonfiguration, auf der sie ausgeführt wird, nicht mehr effizienter.
Zweitens ist eine monolithische Anwendung nicht so einfach auf neue Server zu übertragen, und dies erfordert möglicherweise eine vollständige Neukompilierung des Programms.
Drittens ist eine solche Anwendung schwer zu warten und zu entwickeln. Jede Aktualisierung erfordert die vollständige Montage des gesamten Programms, und ein Fehler in einem der Codeblöcke kann zum Ausfall des gesamten Systems führen.
Auf der Suche nach Ideen zur Lösung dieser Probleme wurde ein anderes Konzept entwickelt - Service-Oriented Architecture (SOA). Dies bedeutet, dass die Anwendung in mehrere Module unterteilt ist, von denen jedes den anderen eine Art von Funktionalität bietet. Die Module interagieren über eine Reihe von Webdiensten miteinander und können unabhängig voneinander auf eine oder ihre eigenen Datenbanken zugreifen.
Dieser Ansatz vereinfacht die Unterstützung des Programms wirklich und macht sein Update nicht „zur Arbeit eines Pioniers“, in dem es keinen Raum für Fehler gibt. aber er hat auch seine Mängel. Das Hauptproblem sind Probleme bei der Skalierung der Entwicklung solcher Anwendungen. Mit dem Wachstum des Programms wird es immer schwieriger, neue Funktionen in die ursprünglich vom Architekten genehmigten 5-10 Pakete zu „pushen“. Ihre Zahl wächst, was zu Problemen mit der Unterstützung führt.
Microservice als Element der Anwendungsentwicklung
Das Ergebnis der Entwicklung von SOA ist die Idee einer Mikroservice-Architektur, die beim Entwurf von Cloud-Anwendungen verwendet wird. Konzeptionell sind die Ideen beider Ansätze äußerst ähnlich, und einige Architekten heben die Microservice-Architektur nicht einmal als separates Paradigma hervor, da sie einen Sonderfall der SOA darstellt.
Die Microservice-Architektur impliziert, dass die Anwendung nicht aus einer kleinen Anzahl großer Module besteht, sondern aus vielen unabhängigen Teilen. Im Gegensatz zu einem Monolithen können Sie in einer Microservice-Anwendung verschiedene Methoden für die Interaktion von Komponenten miteinander verwenden. Das System hat keinen einzigen vorbestimmten Zustand. Stattdessen arbeitet jede Komponente „je nach Situation“: Sobald sie ein Ereignis empfängt, beginnt sie zu arbeiten. Dies ermöglicht eine sehr flexible und unabhängige Architektur.
Gleichzeitig ändert sich die Anzahl der Dienste in der Microservice-Anwendung ständig - einige werden hinzugefügt, andere werden gelöscht. Bei dem neuen Ansatz kann jeder Mikrodienst ersetzt und stattdessen eine Kette von Mikrodiensten eingebettet werden. Andere Dienste arbeiten weiterhin stabil, da sie nicht direkt miteinander verbunden sind. Dies ist die natürliche Entwicklung des Programms. Dank dessen haben Entwickler und Architekten die Möglichkeit, schnell etwas zu ändern, um auf Änderungen der Geschäftsanforderungen zu reagieren und die Konkurrenz zu übertreffen.
Die Verwendung der Microservice-Architektur erhöht nicht nur die Aktualisierungsgeschwindigkeit von Updates, sondern ermöglicht auch eine dezentrale Verwaltung. Das Team, das für die Entwicklung eines Dienstes verantwortlich ist, ist berechtigt, seine interne Architektur und seine Funktionen zu bestimmen. Ein solcher Ansatz wird übrigens jetzt vom Sberbank Architectural Council im Technologieblock umgesetzt.
Wenn Sie sich hinsetzen, um Ihre Cloud-Anwendung zu entwickeln, sollten Sie sich nicht beeilen, sie schnell in ihre Bestandteile zu zerquetschen. Der Hauptgegner eines solchen gedankenlosen Ansatzes ist Martin Fowler; Er ist einer der Autoren der Idee der Microservice-Architektur. Es ist einfacher, zunächst einen monolithischen Ansatz zu verwenden und dann die Entwicklung der Anwendung auf "natürliche Weise" anzuregen, wobei Engpässe beseitigt und zusätzliche Funktionen hinzugefügt werden.
Infolgedessen können wir die folgende Regel formulieren: Die Aufgabe des Programmierers bei der Arbeit mit der Microservice-Architektur besteht nicht nur darin, die Anwendung in die maximale Anzahl von Komponenten aufzuteilen, sondern bewusst zwischen ihrer Verantwortung für den Empfang und die Verarbeitung von Daten zu unterscheiden.
Vier Details
Zusätzlich zu den vielen offensichtlichen Vorteilen weist die Microservice-Architektur ihre eigenen Merkmale auf, die bei der Entwicklung Ihrer Cloud-Anwendung berücksichtigt werden müssen. Um den Betrieb einer solchen Anwendung zu unterstützen, müssen insbesondere die Anforderungen an die Qualität der Verwaltung interner APIs ständig erhöht werden.
Wenn eine der Komponenten ihre Schnittstelle ändert, muss sie die Abwärtskompatibilität unterstützen, um die vorherige Version ihrer eigenen API zu unterstützen. Wenn diese Regel eingehalten wird, können Sie ohne Fehler dynamisch von der alten zur neuen Version wechseln. Wenn die Unterstützung für die vorherige Version der API nicht funktioniert, droht dies bestenfalls mit einem Verlust eines Teils der Funktionalität der Anwendung und im schlimmsten Fall mit dauerhaften Abstürzen im Betrieb.
Das zweite wichtige Merkmal von Microservice-Anwendungen ist die Schwierigkeit, Fehler in ihnen zu finden. Wenn eine in monolithischer Logik oder SOA geschriebene Anwendung abstürzt, ist es nicht schwierig, die Ursache des Problems zu finden. In einer Anwendung, die aus vielen Diensten besteht, kann die Suche nach der Ursache des Fehlers lange dauern, da die Daten des Benutzers häufig mehrere Mikrodienste durchlaufen und es schwierig ist, festzustellen, welcher von ihnen abstürzt. Gleichzeitig muss die Fehlersuche sehr sorgfältig durchgeführt werden: Jedes erfolglose Refactoring kann zu einem Ausfall des Arbeitsmoduls führen, und zusätzlich zum anfänglichen Problem erhält der Entwickler ein zweites.
Das dritte wichtige Detail, das bei der Entwicklung einer Cloud-Anwendung berücksichtigt werden muss, ist die Art und Weise, wie ihre Komponenten miteinander interagieren. Wie bei SOA verwenden Dienste Webdienste zum Datenaustausch, in der Microservice-Architektur sind jedoch Interaktionsmuster aufgetreten, z. B. Streaming, CQRS und Event-Sourcing. In der Regel erwarten Entwickler, dass die Antwortzeit zwischen der Anforderung und der Antwort in der Anwendung recht gering ist. In einem verteilten System kann man sich nicht einmal darauf verlassen, dass die Antwort überhaupt kommt.
In der Architektur von Cloud-Anwendungen verwenden Microservices verschiedene Datenbanken, die für die Lösung ihrer spezifischen Probleme am besten geeignet sind. Zum Beispiel können Gitter schnell lesen, aber eine große Anzahl von Datenänderungsvorgängen kaum bewältigen. Eine solche Basis eignet sich gut für die Führung von Einlagenkonten - sie ändern sich selten. Eine andere Art von Operation ist die Verarbeitung; Es kann jeden Tag Dutzende von Änderungen auf jeder Karte geben, und im Gegenteil, es gibt nur wenige Datenlesungen.
Die vierte Tatsache, die Sie bei der Entwicklung einer Cloud-Anwendung berücksichtigen müssen, ist, dass sich die Microservice-Architektur in erster Linie auf die Verwendung zustandsloser Dienste konzentriert. Gehen Sie in diesem Fall nicht bis zum Äußersten. Einige Dienste können bei Bedarf weiterhin staatliche Unterstützung bieten, wenn die Geschäftslogik dies erfordert, und sie müssen mit besonderer Sorgfalt entworfen werden.
Beispiel: Wenn der Benutzer einen Kredit beantragt, muss das System, das den Antrag erhalten hat, diesen Status speichern, um ihn auf andere Dienste zu übertragen. Der Dienst, der für das Auffinden von Informationen in der internen Datei der Bonitätshistorie verantwortlich ist, speichert möglicherweise nicht seinen Status und vergisst die Daten, nach denen der Name des Benutzers vor einigen Minuten gesucht hat - jedenfalls wird nach einem Moment eine neue Anfrage bei ihm eingehen (obwohl dies in diesem Prozess der Fall sein kann) anderes Serviceverhalten sein).
Alle oben beschriebenen Beispiele und Praktiken werden bereits von den Führungskräften der globalen IT-Branche aktiv genutzt. Zum Beispiel ist Netflix ein Pionier bei der Entwicklung der Microservice-Architektur. Das Unternehmen hat viele Open-Source-Anwendungen, Bibliotheken und ein Framework zum Überwachen, Ausgleichen und Protokollieren laufender Microservice-Anwendungen veröffentlicht.