Einführung in Microservices

Die Registrierung für Microservices März 2023 ist jetzt geöffnet. Sehen Sie sich die Tagesordnung an und melden Sie sich hier an .

Redaktion – Die siebenteilige Artikelserie ist nun komplett:

1. Einführung in Microservices (dieser Artikel)
2. Erstellen von Microservices: Verwenden eines API-Gateways
3. Erstellen von Microservices: Interprozesskommunikation in einer Microservices-Architektur
4. Service Discovery in einer Microservices-Architektur
5. Ereignisgesteuertes Datenmanagement für Microservices
6. Auswählen einer Bereitstellungsstrategie für Microservices
7. Refactoring eines Monolithen in Microservices

Sie können den kompletten Artikelsatz sowie Informationen zur Implementierung von Microservices mit NGINX Plus auch als E-Book herunterladen – Microservices: Vom Entwurf bis zur Bereitstellung .

Schauen Sie sich auch unsere Seite mit Microservices- Lösungen an.

Microservices erregen derzeit viel Aufmerksamkeit: in Artikeln, Blogs, Diskussionen in sozialen Medien und Konferenzpräsentationen. Sie steuern rasch auf den Höhepunkt der überzogenen Erwartungen im Gartner-Hype-Zyklus zu. Gleichzeitig gibt es in der Software-Community Skeptiker, die Microservices als nichts Neues abtun. Kritiker behaupten, dass es sich bei der Idee lediglich um eine Umbenennung von SOA handele. Trotz des Hypes und der Skepsis bietet das Microservices-Architekturmuster jedoch erhebliche Vorteile – insbesondere, wenn es um die agile Entwicklung und Bereitstellung komplexer Unternehmensanwendungen geht.

Dieser Blogbeitrag ist der erste einer siebenteiligen Serie über das Entwerfen, Erstellen und Bereitstellen von Microservices . Sie erfahren mehr über diesen Ansatz und erfahren, wie er sich im Vergleich zum traditionelleren Muster der monolithischen Architektur schlägt. In dieser Reihe werden die verschiedenen Elemente einer Microservices-Architektur beschrieben. Sie erfahren, welche Vor- und Nachteile das Microservices-Architekturmuster bietet, ob es für Ihr Projekt sinnvoll ist und wie Sie es anwenden.

Sehen wir uns zunächst an, warum Sie den Einsatz von Microservices in Betracht ziehen sollten.

Erstellen monolithischer Anwendungen

Stellen wir uns vor, Sie würden mit der Entwicklung einer brandneuen Taxi-App beginnen, die als Konkurrenz zu Uber und Hailo dienen soll. Nach einigen Vorbesprechungen und der Erfassung der Anforderungen erstellen Sie entweder manuell oder mithilfe eines Generators, der mit Rails, Spring Boot, Play oder Maven geliefert wird, ein neues Projekt. Diese neue Anwendung hätte eine modulare hexagonale Architektur , wie im folgenden Diagramm:

Den Kern der Anwendung bildet die Geschäftslogik, die durch Module implementiert wird, die Dienste, Domänenobjekte und Ereignisse definieren. Um den Kern herum befinden sich Adapter, die die Schnittstelle zur Außenwelt bilden. Beispiele für Adapter sind Datenbankzugriffskomponenten, Messagingkomponenten, die Nachrichten erstellen und verarbeiten, und Webkomponenten, die entweder APIs bereitstellen oder eine Benutzeroberfläche implementieren.

Obwohl die Anwendung über eine logisch modulare Architektur verfügt, wird sie als Monolith verpackt und bereitgestellt. Das tatsächliche Format hängt von der Sprache und dem Framework der Anwendung ab. Beispielsweise werden viele Java-Anwendungen als WAR-Dateien gepackt und auf Anwendungsservern wie Tomcat oder Jetty bereitgestellt. Andere Java-Anwendungen werden als eigenständige ausführbare JARs gepackt. In ähnlicher Weise werden Rails- und Node.js-Anwendungen als Verzeichnishierarchie gepackt.

In diesem Stil geschriebene Anwendungen sind äußerst verbreitet. Sie sind einfach zu entwickeln, da unsere IDEs und anderen Tools auf die Erstellung einer einzelnen Anwendung ausgerichtet sind. Solche Anwendungen lassen sich auch einfach testen. Sie können End-to-End-Tests implementieren, indem Sie einfach die Anwendung starten und die Benutzeroberfläche mit Selenium testen. Darüber hinaus lassen sich monolithische Anwendungen einfach bereitstellen. Sie müssen lediglich die gepackte Anwendung auf einen Server kopieren. Sie können die Anwendung auch skalieren, indem Sie mehrere Kopien hinter einem Load Balancer ausführen. In den frühen Phasen des Projekts funktioniert es gut.

Auf dem Weg zur monolithischen Hölle

Leider weist dieser einfache Ansatz eine große Einschränkung auf. Erfolgreiche Anwendungen haben die Angewohnheit, mit der Zeit zu wachsen und schließlich riesig zu werden. Während jedes Sprints implementiert Ihr Entwicklungsteam einige weitere Stories, was natürlich das Hinzufügen vieler Codezeilen bedeutet. Nach einigen Jahren ist Ihre kleine, einfache Anwendung zu einem monströsen Monolithen angewachsen. Um ein extremes Beispiel zu nennen: Ich habe kürzlich mit einem Entwickler gesprochen, der ein Tool zum Analysieren der Abhängigkeiten zwischen den Tausenden von JARs in seiner mehrere Millionen Codezeilen umfassenden Anwendung (LOC) schrieb. Ich bin überzeugt, dass die Erschaffung eines solchen Monsters der konzertierten Anstrengungen einer großen Zahl von Entwicklern über viele Jahre hinweg bedurfte.

Wenn Ihre Anwendung erst einmal zu einem großen, komplexen Monolithen geworden ist, steckt Ihre Entwicklungsorganisation wahrscheinlich in großen Schwierigkeiten. Alle Versuche einer agilen Entwicklung und Bereitstellung werden scheitern. Ein großes Problem besteht darin, dass die Anwendung übermäßig komplex ist. Es ist einfach zu umfangreich, als dass ein einzelner Entwickler es vollständig verstehen könnte. Dies führt dazu, dass das Beheben von Fehlern und die korrekte Implementierung neuer Funktionen schwierig und zeitaufwändig wird. Darüber hinaus besteht die Tendenz, dass sich die Situation nach unten verschiebt. Wenn die Codebasis schwer zu verstehen ist, werden Änderungen nicht korrekt vorgenommen. Am Ende bleibt ein monströser, unfassbarer Schlammball übrig.

Auch die schiere Größe der Anwendung wird die Entwicklung verlangsamen. Je größer die Anwendung, desto länger ist die Startzeit. In einer kürzlich durchgeführten Umfrage berichteten einige Entwickler beispielsweise von Startzeiten von bis zu 12 Minuten. Ich habe auch Anekdoten von Anwendungen gehört, deren Start bis zu 40 Minuten dauerte. Wenn Entwickler den Anwendungsserver regelmäßig neu starten müssen, verbringen sie einen großen Teil ihres Arbeitstages mit Warten und ihre Produktivität leidet darunter.

Ein weiteres Problem bei großen, komplexen monolithischen Anwendungen besteht darin, dass sie einer kontinuierlichen Bereitstellung im Wege stehen. Heutzutage besteht der Stand der Technik bei SaaS-Anwendungen darin, Änderungen mehrmals täglich in die Produktion zu bringen. Dies ist bei einem komplexen Monolithen äußerst schwierig, da Sie die gesamte Anwendung erneut bereitstellen müssen, um einen beliebigen Teil davon zu aktualisieren. Auch die zuvor erwähnten langen Startzeiten helfen dabei nicht weiter. Da außerdem die Auswirkungen einer Änderung im Allgemeinen nicht gut verstanden werden, ist es wahrscheinlich, dass Sie umfangreiche manuelle Tests durchführen müssen. Folglich ist eine kontinuierliche Bereitstellung nahezu unmöglich.

Außerdem kann die Skalierung monolithischer Anwendungen schwierig sein, wenn verschiedene Module widersprüchliche Ressourcenanforderungen haben. Beispielsweise könnte ein Modul eine CPU-intensive Bildverarbeitungslogik implementieren und würde idealerweise in Amazon EC2 Compute Optimized-Instanzen bereitgestellt. Ein anderes Modul könnte eine In-Memory-Datenbank sein und sich am besten für speicheroptimierte EC2-Instanzen eignen. Da diese Module jedoch zusammen eingesetzt werden, müssen Sie bei der Auswahl der Hardware Kompromisse eingehen.

Ein weiteres Problem bei monolithischen Anwendungen ist die Zuverlässigkeit. Da alle Module innerhalb desselben Prozesses ausgeführt werden, kann ein Fehler in einem beliebigen Modul, beispielsweise ein Speicherverlust, möglicherweise den gesamten Prozess zum Absturz bringen. Da alle Instanzen der Anwendung identisch sind, wirkt sich dieser Fehler zudem auf die Verfügbarkeit der gesamten Anwendung aus.

Und nicht zuletzt erschweren monolithische Anwendungen die Einführung neuer Frameworks und Sprachen enorm. Stellen wir uns beispielsweise vor, Sie haben 2 Millionen Zeilen Code mit dem XYZ-Framework geschrieben. Es wäre extrem teuer (sowohl hinsichtlich des Zeit- als auch Kostenaufwands), die gesamte Anwendung für die Verwendung des neueren ABC-Frameworks neu zu schreiben, selbst wenn dieses Framework wesentlich besser wäre. Dies führt dazu, dass die Einführung neuer Technologien mit enormen Hindernissen verbunden ist. Sie bleiben bei der Technologieauswahl, die Sie zu Beginn des Projekts getroffen haben.

Um es zusammenzufassen: Sie haben eine erfolgreiche, geschäftskritische Anwendung, die zu einem monströsen Monolithen herangewachsen ist, den nur sehr wenige, wenn überhaupt, Entwickler verstehen. Es wurde mit veralteter, unproduktiver Technologie geschrieben, was die Einstellung talentierter Entwickler erschwert. Die Anwendung ist schwer skalierbar und unzuverlässig. Daher ist eine agile Entwicklung und Bereitstellung von Anwendungen unmöglich.

Was können Sie also dagegen tun?

Microservices – Die Komplexität bewältigen

Viele Organisationen, wie z. B. Amazon, eBay und Netflix , haben dieses Problem gelöst, indem sie das übernommen haben, was heute als Microservices-Architekturmuster bekannt ist. Anstatt eine einzige monströse, monolithische Anwendung zu erstellen, besteht die Idee darin, Ihre Anwendung in eine Reihe kleinerer, miteinander verbundener Dienste aufzuteilen.

Ein Dienst implementiert typischerweise eine Reihe unterschiedlicher Features oder Funktionen, wie etwa Auftragsverwaltung, Kundenverwaltung usw. Jeder Microservice ist eine Minianwendung mit einer eigenen hexagonalen Architektur, die aus Geschäftslogik und verschiedenen Adaptern besteht. Einige Microservices würden eine API bereitstellen, die von anderen Microservices oder den Clients der Anwendung genutzt wird. Andere Microservices implementieren möglicherweise eine Web-Benutzeroberfläche. Zur Laufzeit ist jede Instanz häufig eine Cloud-VM oder ein Docker-Container.

Eine mögliche Zerlegung des zuvor beschriebenen Systems ist beispielsweise im folgenden Diagramm dargestellt:

Jeder Funktionsbereich der Anwendung wird mittlerweile durch einen eigenen Microservice realisiert. Darüber hinaus wird die Webanwendung in mehrere einfachere Webanwendungen aufgeteilt (wie etwa eine für Fahrgäste und eine für Fahrer in unserem Taxiruf-Beispiel). Dies erleichtert die Bereitstellung individueller Erlebnisse für bestimmte Benutzer, Geräte oder spezielle Anwendungsfälle.

Jeder Backend-Dienst stellt eine REST-API bereit und die meisten Dienste nutzen APIs, die von anderen Diensten bereitgestellt werden. Beispielsweise verwendet das Fahrermanagement den Benachrichtigungsserver, um einen verfügbaren Fahrer über eine mögliche Fahrt zu informieren. Die UI-Dienste rufen die anderen Dienste auf, um Webseiten darzustellen. Dienste verwenden möglicherweise auch asynchrone, nachrichtenbasierte Kommunikation. Auf die Kommunikation zwischen den Diensten wird später in dieser Reihe noch ausführlicher eingegangen.

Einige REST-APIs stehen auch den mobilen Apps der Fahrer und Passagiere zur Verfügung. Die Apps haben jedoch keinen direkten Zugriff auf die Backend-Dienste. Stattdessen wird die Kommunikation über einen Vermittler vermittelt, der als API-Gateway bezeichnet wird. Das API-Gateway ist für Aufgaben wie Lastausgleich, Zwischenspeicherung, Zugriffskontrolle, API-Messung und Überwachung verantwortlich und kann mit NGINX effektiv implementiert werden . Spätere Artikel der Reihe behandeln das API-Gateway .

Das Muster der Microservices-Architektur entspricht der Skalierung der Y-Achse des Scale Cube , einem 3D-Modell der Skalierbarkeit aus dem hervorragenden Buch The Art of Scalability . Die anderen beiden Skalierungsachsen sind die X-Achsen-Skalierung, bei der mehrere identische Kopien der Anwendung hinter einem Load Balancer ausgeführt werden, und die Z-Achsen-Skalierung (oder Datenpartitionierung), bei der ein Attribut der Anforderung (z. B. der Primärschlüssel einer Zeile oder die Identität eines Kunden) verwendet wird, um die Anforderung an einen bestimmten Server weiterzuleiten.

Normalerweise verwenden Anwendungen die drei Skalierungsarten zusammen. Die Skalierung der Y-Achse zerlegt die Anwendung in Mikroservices, wie oben in der ersten Abbildung dieses Abschnitts dargestellt. Zur Laufzeit führt die X-Achsen-Skalierung mehrere Instanzen jedes Dienstes hinter einem Load Balancer aus, um Durchsatz und Verfügbarkeit zu gewährleisten. Einige Anwendungen nutzen möglicherweise auch die Z-Achsen-Skalierung, um die Dienste zu partitionieren. Das folgende Diagramm zeigt, wie der Trip Management-Dienst mit Docker auf Amazon EC2 bereitgestellt werden kann.

Zur Laufzeit besteht der Dienst „Reisemanagement“ aus mehreren Dienstinstanzen. Jede Serviceinstanz ist ein Docker-Container. Um eine hohe Verfügbarkeit zu gewährleisten, laufen die Container auf mehreren Cloud-VMs. Vor den Service-Instanzen steht ein Load Balancer wie NGINX , der die Anfragen auf die Instanzen verteilt. Der Load Balancer kann auch andere Aufgaben übernehmen, wie etwa Caching , Zugriffskontrolle , API-Messung und Überwachung .

Das Microservices-Architekturmuster hat erhebliche Auswirkungen auf die Beziehung zwischen der Anwendung und der Datenbank. Anstatt ein einzelnes Datenbankschema mit anderen Diensten zu teilen, verfügt jeder Dienst über sein eigenes Datenbankschema. Einerseits steht dieser Ansatz im Widerspruch zur Idee eines unternehmensweiten Datenmodells. Außerdem kommt es dadurch oft zu einer Duplizierung einiger Daten. Wenn Sie jedoch von Microservices profitieren möchten, ist ein Datenbankschema pro Dienst unbedingt erforderlich, da dadurch eine lose Kopplung gewährleistet wird. Das folgende Diagramm zeigt die Datenbankarchitektur für die Beispielanwendung.

Jeder der Dienste verfügt über eine eigene Datenbank. Darüber hinaus kann ein Dienst einen Datenbanktyp verwenden, der seinen Anforderungen am besten entspricht (die sogenannte polyglotte Persistenzarchitektur). Beispielsweise muss das Fahrermanagement, das Fahrer in der Nähe eines potenziellen Fahrgastes findet, eine Datenbank verwenden, die effiziente Geoabfragen unterstützt.

Oberflächlich betrachtet ähnelt das Muster der Microservices-Architektur SOA. Bei beiden Ansätzen besteht die Architektur aus einer Reihe von Diensten. Man kann sich das Muster der Microservices-Architektur jedoch auch so vorstellen, dass es sich um eine SOA ohne die Kommerzialisierung und den wahrgenommenen Ballast von Webservice-Spezifikationen (WS-*) und einem Enterprise Service Bus (ESB) handelt. Auf Microservices basierende Anwendungen bevorzugen einfachere, leichtgewichtige Protokolle wie REST gegenüber WS-*. Sie vermeiden außerdem weitgehend die Verwendung von ESBs und implementieren stattdessen ESB-ähnliche Funktionen in den Microservices selbst. Das Microservices-Architekturmuster lehnt auch andere Teile von SOA ab, etwa das Konzept eines kanonischen Schemas.

Die Vorteile von Microservices

Das Microservices-Architekturmuster bietet eine Reihe wichtiger Vorteile. Erstens befasst es sich mit dem Problem der Komplexität. Es zerlegt eine ansonsten monströse monolithische Anwendung in eine Reihe von Diensten. Während der Gesamtumfang der Funktionalität unverändert bleibt, wurde die Anwendung in überschaubare Teile oder Dienste aufgeteilt. Jeder Dienst verfügt über eine klar definierte Grenze in Form einer RPC- oder nachrichtengesteuerten API. Das Microservices-Architekturmuster erzwingt ein Maß an Modularität, das mit einer monolithischen Codebasis in der Praxis nur äußerst schwer zu erreichen ist. Folglich lassen sich einzelne Dienste viel schneller entwickeln und sind wesentlich einfacher zu verstehen und zu warten.

Zweitens ermöglicht diese Architektur die unabhängige Entwicklung jedes Dienstes durch ein Team, das sich auf diesen Dienst konzentriert. Die Entwickler können frei jede sinnvolle Technologie wählen, vorausgesetzt, der Dienst hält sich an den API-Vertrag. Natürlich möchten die meisten Organisationen völlige Anarchie vermeiden und die Technologieoptionen einschränken. Diese Freiheit bedeutet jedoch, dass Entwickler nicht mehr verpflichtet sind, die möglicherweise veralteten Technologien zu verwenden, die zu Beginn eines neuen Projekts vorhanden waren. Beim Schreiben eines neuen Dienstes haben sie die Möglichkeit, aktuelle Technologien zu verwenden. Da die Dienste zudem relativ klein sind, ist es möglich, einen alten Dienst mit der aktuellen Technologie neu zu schreiben.

Drittens ermöglicht das Microservices-Architekturmuster die unabhängige Bereitstellung jedes Microservices. Entwickler müssen die Bereitstellung von Änderungen, die lokal für ihren Dienst erfolgen, nie koordinieren. Änderungen dieser Art können bereitgestellt werden, sobald sie getestet wurden. Das UI-Team kann beispielsweise A/B-Tests durchführen und UI-Änderungen schnell iterieren. Das Microservices-Architekturmuster ermöglicht eine kontinuierliche Bereitstellung.

Schließlich ermöglicht das Microservices-Architekturmuster die unabhängige Skalierung jedes Dienstes. Sie können von jedem Dienst nur die Anzahl an Instanzen bereitstellen, die seinen Kapazitäts- und Verfügbarkeitsbeschränkungen entspricht. Darüber hinaus können Sie die Hardware verwenden, die dem Ressourcenbedarf eines Dienstes am besten entspricht. Sie können beispielsweise einen CPU-intensiven Bildverarbeitungsdienst auf EC2 Compute Optimized-Instanzen und einen In-Memory-Datenbankdienst auf EC2 Memory-optimierten Instanzen bereitstellen.

Die Nachteile von Microservices

Wie Fred Brooks vor fast 30 Jahren schrieb: Es gibt keine Wunderwaffe. Wie jede andere Technologie hat auch die Microservices-Architektur Nachteile. Ein Nachteil ist der Name selbst. Der Begriff Microservice legt zu viel Wert auf die Servicegröße. Tatsächlich gibt es einige Entwickler, die den Aufbau extrem feinkörniger 10–100 LOC-Dienste befürworten. Zwar sind kleine Dienstleistungen vorzuziehen, man darf jedoch nicht vergessen, dass sie ein Mittel zum Zweck und nicht das Hauptziel sind. Das Ziel von Microservices besteht darin, die Anwendung ausreichend zu zerlegen, um eine agile Anwendungsentwicklung und -bereitstellung zu ermöglichen.

Ein weiterer großer Nachteil von Microservices ist die Komplexität, die sich aus der Tatsache ergibt, dass eine Microservices-Anwendung ein verteiltes System ist. Entwickler müssen einen Mechanismus für die Interprozesskommunikation auswählen und implementieren, der entweder auf Messaging oder RPC basiert. Darüber hinaus müssen sie Code schreiben, um Teilfehler zu behandeln, da das Ziel einer Anfrage langsam oder nicht verfügbar sein kann. Dies ist zwar kein Hexenwerk, aber es ist viel komplexer als bei einer monolithischen Anwendung, bei der Module sich gegenseitig über Methoden-/Prozeduraufrufe auf Sprachebene aufrufen.

Eine weitere Herausforderung bei Microservices ist die partitionierte Datenbankarchitektur. Geschäftstransaktionen, bei denen mehrere Geschäftseinheiten aktualisiert werden, kommen relativ häufig vor. Diese Art von Transaktionen sind in einer monolithischen Anwendung einfach zu implementieren, da nur eine einzige Datenbank vorhanden ist. In einer auf Microservices basierenden Anwendung müssen Sie jedoch mehrere Datenbanken aktualisieren, die zu verschiedenen Diensten gehören. Die Verwendung verteilter Transaktionen ist normalerweise keine Option, und das nicht nur aufgrund des CAP-Theorems . Sie werden von vielen der heutigen hoch skalierbaren NoSQL-Datenbanken und Messaging-Brokern einfach nicht unterstützt. Sie müssen letztendlich einen auf eventueller Konsistenz basierenden Ansatz verwenden, der für Entwickler eine größere Herausforderung darstellt.

Auch das Testen einer Microservices-Anwendung ist deutlich komplexer. Mit einem modernen Framework wie Spring Boot ist es beispielsweise trivial, eine Testklasse zu schreiben, die eine monolithische Webanwendung startet und ihre REST-API testet. Im Gegensatz dazu müsste eine ähnliche Testklasse für einen Dienst diesen Dienst und alle Dienste starten, von denen er abhängt (oder zumindest Stubs für diese Dienste konfigurieren). Auch hier gilt, dass es sich hierbei nicht um Raketenwissenschaft handelt, man darf die damit verbundene Komplexität jedoch nicht unterschätzen.

Eine weitere große Herausforderung beim Microservices-Architekturmuster besteht darin, Änderungen zu implementieren, die sich über mehrere Dienste erstrecken. Stellen Sie sich beispielsweise vor, Sie implementieren eine Story, die Änderungen an den Diensten A, B und C erfordert, wobei A von B und B von C abhängt. In einer monolithischen Anwendung könnten Sie einfach die entsprechenden Module ändern, die Änderungen integrieren und sie in einem Rutsch bereitstellen. Im Gegensatz dazu müssen Sie bei einem Microservices-Architekturmuster die Einführung von Änderungen an jedem einzelnen Dienst sorgfältig planen und koordinieren. Beispielsweise müssten Sie erst Dienst C, dann Dienst B und schließlich Dienst A aktualisieren. Glücklicherweise wirken sich die meisten Änderungen normalerweise nur auf einen Dienst aus und Änderungen an mehreren Diensten, die eine Koordination erfordern, sind relativ selten.

Zudem ist die Bereitstellung einer auf Microservices basierenden Anwendung wesentlich komplexer. Eine monolithische Anwendung wird einfach auf einer Reihe identischer Server hinter einem herkömmlichen Lastenausgleich bereitgestellt. Jede Anwendungsinstanz ist mit den Standorten (Host und Ports) von Infrastrukturdiensten wie der Datenbank und einem Nachrichtenbroker konfiguriert. Im Gegensatz dazu besteht eine Microservice-Anwendung typischerweise aus einer großen Anzahl von Diensten. Laut Adrian Cockcroft [Anm. d. Red.: Hailo wurde von MyTaxi übernommen.] verfügt Hailo beispielsweise über 160 verschiedene Dienste und Netflix über 600. Jeder Dienst verfügt über mehrere Laufzeitinstanzen. Das sind viele weitere bewegliche Teile, die konfiguriert, bereitgestellt, skaliert und überwacht werden müssen. Darüber hinaus müssen Sie einen Diensterkennungsmechanismus (wird in einem späteren Beitrag besprochen) implementieren, der es einem Dienst ermöglicht, die Standorte (Hosts und Ports) aller anderen Dienste zu erkennen, mit denen er kommunizieren muss. Herkömmliche, auf Trouble-Tickets basierende und manuelle Betriebsansätze können dieses Komplexitätsniveau nicht erreichen. Folglich erfordert die erfolgreiche Bereitstellung einer Microservices-Anwendung eine stärkere Kontrolle der Bereitstellungsmethoden durch die Entwickler und einen hohen Grad an Automatisierung.

Ein Ansatz zur Automatisierung besteht darin, eine handelsübliche PaaS wie Cloud Foundry zu verwenden. Eine PaaS bietet Entwicklern eine einfache Möglichkeit, ihre Microservices bereitzustellen und zu verwalten. Es befreit sie von Sorgen wie der Beschaffung und Konfiguration von IT-Ressourcen. Gleichzeitig können die System- und Netzwerkexperten, die das PaaS konfigurieren, die Einhaltung der Best Practices und der Unternehmensrichtlinien sicherstellen. Eine weitere Möglichkeit, die Bereitstellung von Microservices zu automatisieren, besteht darin, praktisch Ihr eigenes PaaS zu entwickeln. Ein typischer Ausgangspunkt ist die Verwendung einer Clusterlösung wie Kubernetes in Verbindung mit einer Technologie wie Docker. Später in dieser Reihe werden wir uns ansehen, wie softwarebasierte Ansätze zur Anwendungsbereitstellung wie NGINX Plus, das Caching, Zugriffskontrolle, API-Messung und Überwachung auf Mikroservice-Ebene problemlos handhabt, zur Lösung dieses Problems beitragen können.

Zusammenfassung

Das Erstellen komplexer Anwendungen ist von Natur aus schwierig. Eine monolithische Architektur ist nur für einfache, leichte Anwendungen sinnvoll. Wenn Sie es für komplexe Anwendungen verwenden, wird es Ihnen schwerfallen. Trotz seiner Nachteile und Implementierungsherausforderungen ist das Microservices-Architekturmuster die bessere Wahl für komplexe, sich entwickelnde Anwendungen.

In späteren Blogbeiträgen werde ich näher auf die Details verschiedener Aspekte des Microservices-Architekturmusters eingehen und Themen wie Diensterkennung, Optionen zur Dienstbereitstellung und Strategien zum Refactoring einer monolithischen Anwendung in Dienste diskutieren.

Bleiben Sie dran…

Redaktion – Die siebenteilige Artikelserie ist nun komplett:

1. Einführung in Microservices (dieser Artikel)
2. Erstellen von Microservices: Verwenden eines API-Gateways
3. Erstellen von Microservices: Interprozesskommunikation in einer Microservices-Architektur
4. Service Discovery in einer Microservices-Architektur
5. Ereignisgesteuertes Datenmanagement für Microservices
6. Auswählen einer Bereitstellungsstrategie für Microservices
7. Refactoring eines Monolithen in Microservices

Sie können den kompletten Artikelsatz sowie Informationen zur Implementierung von Microservices mit NGINX Plus auch als E-Book herunterladen – Microservices: Vom Entwurf bis zur Bereitstellung .

Gastblogger Chris Richardson ist der Gründer des ursprünglichen CloudFoundry.com , einer frühen Java PaaS (Platform as a Service) für Amazon EC2. Heute berät er Organisationen bei der Verbesserung der Entwicklung und Bereitstellung von Anwendungen.