Microservices sind eine Möglichkeit, eine große Anwendung in lose gekoppelte Module zu unterteilen, die über eine einfache API miteinander kommunizieren.
In letzter Zeit reden nur dumme Leute nicht mehr über Microservices. Dies erfreut sich immer größerer Beliebtheit. Der modulare Architekturstil scheint besonders gut für Cloud-basierte Umgebungen geeignet zu sein und erfreut sich wachsender Beliebtheit. Bevor wir ins Detail gehen, werfen wir einen Blick auf alles aus der Vogelperspektive . Deshalb: Microservices sind eine Möglichkeit, ein großes Projekt in kleine, unabhängige und lose gekoppelte Module zu zerlegen. Unabhängige Module sind für klar definierte und diskrete Aufgaben verantwortlich und kommunizieren über eine einfache und zugängliche API miteinander. Mit anderen Worten: Microservices sind einfach ein anderer Architekturstil zum Entwerfen komplexer, meist Webanwendungen. Aber was ist so schlimm an bestehenden Architekturlösungen wie SOA (Service Oriented Architecture)? Die meisten modernen, mit SOA geschriebenen Unternehmenslösungen scheinen recht gut zu funktionieren. Dies könnte ein guter Zeitpunkt sein, über einige der Herausforderungen zu sprechen, mit denen die Branche heutzutage konfrontiert ist ... Beginnen wir mit einem einfachen Beispiel. Nehmen wir an, ich muss eine klassische, in Java geschriebene Anwendung ausführen. Zuerst werde ich die Benutzeroberfläche entwickeln, dann die Geschäftslogikschicht mit mehreren Komponenten, die mit der Benutzeroberfläche interagieren, und schließlich die Datenbankschicht, auf die die persistente Datenbank zugreifen kann. Da ich nun die Anwendung ausführen möchte, erstelle ich ein WAR/EAR/JAR und mounte es auf einem Server (z. B. JBoss, Tomcat oder WebLogic). Da dies alles in einem geschieht, erhalte ich eine monolithische Anwendung, was bedeutet, dass alle Komponenten an einem Ort sind... Beispiel im Bild:
Höchstwahrscheinlich sind Sie mit diesem Ansatz bereits vertraut und haben ihn bereits verwendet. Die Idee besteht jedoch darin, anhand dieses Beispiels zu zeigen, welchen Herausforderungen sich Entwickler bei der Verwendung dieser Architekturlösung stellen müssen. Monolithische Anwendung: Herausforderungen Herausforderungen
Wenn die Anwendung wächst, wächst auch die Menge des geschriebenen Codes, wodurch die Entwicklungsumgebung möglicherweise jedes Mal überlastet wird, wenn Sie sie öffnen müssen. Dies verringert definitiv die Effizienz des Entwicklers.
Da alles an einem Ort montiert werden muss, führt dies dazu, dass der Umstieg auf eine andere Programmiersprache oder auf andere Technologien ein großes Problem darstellt. Sie haben beispielsweise eine Anwendung in Java geschrieben, und nach einer Weile kam Kotlin heraus und Sie wollten es unbedingt umschreiben, weil es als cooler, besser und schneller beworben wurde. Bei einer monolithischen Anwendung wird schon der Gedanke an Refactoring echte Schmerzen bereiten, ganz zu schweigen vom Prozess selbst. Es gibt derzeit viele Anwendungen, die auf diese Weise erstellt werden, und die Anzahl der Codezeilen ist einfach unglaublich.
Wenn eine der Komponenten aus irgendeinem Grund nicht mehr funktioniert , stürzt auch die gesamte Anwendung ab. Stellen Sie sich vor, dass es eine Webanwendung gibt, die über Module wie Autorisierung, Zahlung, Verlauf usw. verfügt. Und aus irgendeinem Grund geht einer von ihnen kaputt. Das ist einfach ein Schock für das Unternehmen und damit auch für die Entwickler.
Die Skalierung einer monolithischen Anwendung kann nur durch die Erstellung einer anderen Anwendung desselben Typs erreicht werden. Was aber, wenn Sie nur eine Komponente skalieren müssen und nicht die gesamte Anwendung? Wie viele Ressourcen werden verschwendet?...
Dies kann große Auswirkungen auf den Entwicklungsprozess und den Installationsprozess der Anwendung haben. Je größer die Anwendung, desto wichtiger ist es, dass Entwickler die Anwendung in kleinere Arbeitsteile aufteilen können. Da alle Module in einer monolithischen Anwendung miteinander verbunden sind, können Entwickler diese Module nicht unabhängig voneinander bearbeiten/mounten. Da Entwickler voneinander abhängig sind, erhöht sich die Entwicklungszeit.
Gleichzeitig sind wir bereit, die Bedeutung von Microservices zu bedenken und zu verstehen, nämlich wie sie genutzt werden können, um die Flexibilität wiederherzustellen, die mit dem SOA-Stil verloren gegangen ist. Gute Microservices zur Rettung Eines der wichtigsten Merkmale jeder Architekturlösung ist die Skalierbarkeit. Als ich zum ersten Mal Microservices lernte, sah ich, dass alles den Zitaten aus dem Buch „The Art of Scalability“ so ähnlich war. Dies ist ein guter Anfang und Ort für Diskussionen. Dieses Buch definiert das sogenannte „Scalability Cube“-Modell, das ein dreidimensionales Skalierbarkeitssystem beschreibt:
Wie Sie sehen , beschreibt die Die Idee der Z-Achse wird verstanden, wenn die Daten aufgeteilt werden und die Anwendung Anfragen genau dorthin sendet, wo sich die Daten befinden. Das heißt, sie befinden sich nicht alle an einem Ort. Auf die Idee der Y-Achse werden wir uns näher konzentrieren. Diese Achse stellt eine funktionale Zerlegung dar . In dieser Strategie können verschiedene Funktionen als unabhängige Dienste betrachtet werden. Indem die gesamte Anwendung erst dann bereitgestellt wird, wenn alles erledigt ist, können Entwickler einzelne Dienste unabhängig voneinander bereitstellen und müssen nicht darauf warten, dass andere mit der Arbeit an ihren Modulen fertig sind. Dies verkürzt nicht nur die Entwicklungszeit, sondern bietet auch die Flexibilität, Änderungen und Neuverdrahtungen vorzunehmen, ohne sich um die restlichen Anwendungskomponenten kümmern zu müssen. Vergleichen wir dieses Diagramm mit dem vorherigen monolithischen:
Microservices: Vorteile Die Vorteile von Microservices scheinen völlig ausreichend zu sein, um Unternehmensentwickler wie Amazon, Netflix, Ebay davon zu überzeugen, diesen Ansatz zu nutzen. Im Gegensatz zu monolithischen Architekturanwendungen bieten Microservices Folgendes:
Verbessert die Isolierung von Komponentenfehlern: Große Anwendungen können auch dann weiterhin effizient ausgeführt werden, wenn ein einzelnes Modul ausfällt.
Eliminiert die Bindung der Anwendung an einen Technologie-Stack: Wenn Sie einen neuen Technologie-Stack für einen Dienst ausprobieren möchten, fahren Sie fort. Die Abhängigkeiten werden viel geringer sein als bei einer monolithischen Abhängigkeit, und es wird auch viel einfacher sein, alles zurückzusetzen. Je weniger Code in einer Anwendung enthalten ist, desto einfacher ist die Arbeit.
Erleichtert es neuen Mitarbeitern erheblich, die Funktionalität des Dienstes zu verstehen.
Microservices: Funktionen der Bereitstellung und Virtualisierung Jetzt verstehen wir, was Microservices sind. Und der größte Vorteil besteht darin, dass es von mehr als einem WAR/EAR/JAR-Archiv gemountet wird. Aber wie wird es installiert? Der beste Weg, Microservices in Containern zu montieren. Ein Container ist ein vollständig konfiguriertes virtuelles Betriebssystem mit der erforderlichen Umgebung, die dazu beiträgt, den Zugriff auf die Ressourcen des Hardwaresystems, auf dem der Container installiert ist, zu isolieren. Die bekannteste Lösung auf dem Markt ist natürlich Docker . Virtuelle Maschinen von IaaS (Infrastructure as a Service) wie AWS können ebenfalls gut für die Bereitstellung von Microservices geeignet sein, aber relativ schlanke Microservices nutzen möglicherweise nicht alle Ressourcen, die in der virtuellen Maschine vorhanden sind, was die Rentabilität der Nutzung verringern kann. Sie können Ihre Microservices auch mit dem OSGI- Paket (Open Service Gateway Initiative) bereitstellen. In diesem Fall werden alle Microservices in einer einzigen JVM ausgeführt, dies bringt jedoch Kompromissprobleme zwischen Kontrolle und Isolation mit sich. Microservices: Nachteile Nur weil „das alles cool ist“ und „das haben wir noch nie gesehen“ heißt das nicht, dass es keine Nachteile gibt. Nachfolgend finden Sie eine Liste möglicher Problembereiche, die die Microservice-Architektur mit sich bringt:
Die Entwicklung verteilter Systeme kann schwierig sein. Damit meine ich, dass alle Komponenten jetzt unabhängige Dienste sind – Sie müssen die Anfragen, die zwischen Modulen übertragen werden, sehr sorgfältig behandeln. Es kann vorkommen, dass ein Modul nicht reagiert und Sie gezwungen sind, zusätzlichen Code zu schreiben, um einen Systemabsturz zu vermeiden. Dies kann schwieriger sein, wenn die Remote-Aufrufe latenzempfindlich sind .
Mehrere Datenbanken und die Verwaltung von Transaktionen können eine echte Belastung sein.
Das Testen von Microservice-Anwendungen kann mühsam sein. Bei einer monolithischen Anwendung müssen wir lediglich das WAR/EAR/JAR-Archiv auf dem Server ausführen und sicherstellen, dass es mit der Datenbank verbunden ist. Und bei Microservices muss jeder einzelne Dienst gestartet werden, bevor mit dem Testen begonnen werden kann.
Montageanwendungen können schwierig sein. Sie erfordern möglicherweise die Koordination mehrerer Dienste, die möglicherweise nicht so einfach bereitzustellen sind wie ein WAR-Container.
.... Natürlich können diese Nachteile mit den richtigen Werkzeugen und Vorgehensweisen vermieden werden. Sie selbst benötigen jedoch Unterstützung und lösen nicht alle Probleme vollständig. Der Artikel wurde von der CloudAcademy -Website übersetzt . Freie Übersetzung. Es steht jedem frei, alle seine Gedanken in den Kommentaren zu äußern. Sie werden auf jeden Fall gelesen. Originalartikel Mein Github-Konto
GO TO FULL VERSION