Erfahren Sie mehr über die Microservices-Architektur

Moderne Anwendungen werden erstellt, indem einige Services erstellt werden, die unabhängig voneinander erstellt werden. Dies bietet Agilität und Markteinführungsgeschwindigkeit für die Behebung von Problemen und die Einführung neuer Funktionen.

Dieses Paradigma wird als Microservices-Architektur bezeichnet, obwohl die Anzahl der Services, die für eine vollständige Anwendung zusammenkommen, in den Hunderten (Microservices) oder in den Zehn (Makroservices) liegen kann. Es gibt auch neue Begriffe für modulare Monolithen, die Modulithen genannt werden, und Spring Modulith ist ein solches Beispiel.

Obwohl viele Unternehmen bereits über eine Microservices-Architektur verfügen, sind Microservice-Bereitstellungen komplex, und erfolgreiche Bereitstellungen sind in den meisten Unternehmen noch in Arbeit. Dieses Lösungs-Playbook versucht, das Erstellen und Deployment moderner Microservices mit der beliebten Spring Boot-Plattform zusammen mit Cloud-Infrastruktur, Containern, Kubernetes und Backend-as-a-Service-Plattform mit Oracle Database zu vereinfachen.

Wenn Sie eine Anwendung entwerfen möchten, die mehrsprachig, einfach skalierbar, einfach zu warten und bereitzustellen, hochverfügbar ist und Fehler minimiert, verwenden Sie die Microservices-Architektur, um eine Cloud-Anwendung zu entwerfen und bereitzustellen. In einer Microservices-Architektur besitzt jeder Microservice eine einfache Aufgabe und kommuniziert mit den Clients oder mit anderen Microservices über leichte Kommunikationsmechanismen wie REST-API-Anforderungen.

Das folgende Diagramm zeigt die Architektur einer Anwendung, die aus mehreren Microservices besteht.

Beschreibung der Abbildung microservice_architecture.png

Mit Microservices können Sie Ihre Anwendung als eine Sammlung lose gekoppelter Services entwerfen. Microservices folgen dem Share-Nothing-Modell und werden als zustandslose Prozesse ausgeführt. Dieser Ansatz macht es einfacher, die Anwendung zu skalieren und zu verwalten.

• Die API-Schicht ist der Einstiegspunkt für alle Clientanforderungen an einen Microservice. Über die API-Schicht können die Microservices auch über HTTP, gRPC und TCP/UDP miteinander kommunizieren.
• Die Logikschicht konzentriert sich auf eine einzelne Geschäftsaufgabe und minimiert die Abhängigkeiten von den anderen Microservices. Diese Schicht kann für jeden Microservice in einer anderen Sprache geschrieben werden.
• Die Datenspeicherschicht stellt einen Persistenzmechanismus bereit, z. B. eine Datenbankspeicher-Engine, Logdateien usw. Sie sollten für jeden Microservice einen separaten persistenten Datenspeicher verwenden. Oracle bietet Datenbankcontainer mit mehreren integrierbaren Datenbanken, mit denen Microservices Daten aus Sicherheits-, HA- und Skalierungsgründen ganz einfach isolieren können. Darüber hinaus können SaaS-Anwendungen Multi-Tenancy auf sichere Weise nutzen. Darüber hinaus bringt eine konvergierte Datenbank die Vielfalt der Daten unter einem Dach für umfassendere Einblicke aus den Daten.

In der Regel wird jeder Microservice in einem Container ausgeführt, der eine schlanke Laufzeitumgebung bereitstellt.

Unterschiede zwischen Microservices und monolithischen Architekturen

Bevor Sie mit dem Entwerfen von Anwendungen mit der Microservices-Architektur beginnen, müssen Sie verstehen, wie sich diese Architektur von der traditionellen monolithischen Architektur unterscheidet.

Das Anwendungsdesign konzentriert sich auf die Lösung von Geschäftsanforderungen und die Implementierung von Geschäftslogik. In einer monolithischen Architektur wird die gesamte Anwendung als eine Einheit erstellt, die alle Geschäftslogik enthält. In der Microservices-Architektur ist die Geschäftslogik als mehrere lose gekoppelte Services organisiert.

Die folgende Abbildung zeigt die monolithischen und Microservices-Architekturen.

Beschreibung der Abbildung monolithic_vs_microservice.png

In der folgenden Tabelle werden die Unterschiede zwischen den Microservices und monolithischen Architekturen zusammengefasst.

Eigenschaft	Microservices-Architektur	Monolithische Architektur
Einheitendesign	Die Anwendung besteht aus lose gekoppelten Services. Jeder Service unterstützt eine einzelne Geschäftsaufgabe.	Die gesamte Anwendung wird als eine Einheit konzipiert, entwickelt und bereitgestellt.
Wiederverwendung von Funktionen	Microservices definieren APIs, die ihre Funktionalität jedem Client zur Verfügung stellen. Die Kunden könnten sogar andere Anwendungen sein.	Die Möglichkeit der anwendungsübergreifenden Wiederverwendung von Funktionen ist begrenzt.
Kommunikation innerhalb der Anwendung	Um miteinander zu kommunizieren, verwenden die Microservices einer Anwendung das Anforderungs-Antwort-Kommunikationsmodell. Bei der typischen Implementierung werden REST-API-Aufrufe basierend auf dem HTTP-Protokoll verwendet.	Interne Verfahren (Funktionsaufrufe) erleichtern die Kommunikation zwischen den Komponenten der Anwendung. Die Anzahl der internen Prozeduraufrufe muss nicht begrenzt werden.
Technologische Flexibilität	Jeder Microservice kann mit einer Programmiersprache und einem Framework entwickelt werden, das am besten zu dem Problem passt, für das der Microservice entwickelt wurde.	Normalerweise wird die gesamte Anwendung in einer einzigen Programmiersprache geschrieben.
Datenmanagement	Dezentralisiert: Jeder Microservice kann eine eigene Datenbank verwenden.	Zentralisiert: Die gesamte Anwendung verwendet eine oder mehrere Datenbanken.
Deployment	Jeder Microservice wird unabhängig bereitgestellt, ohne dass sich dies auf die anderen Microservices in der Anwendung auswirkt.	Jede Änderung, auch wenn sie klein ist, erfordert ein erneutes Deployment und einen Neustart der gesamten Anwendung.
Verwaltbarkeit	Microservices sind einfach, fokussiert und unabhängig. So ist die Anwendung einfacher zu warten.	Mit zunehmendem Anwendungsbereich wird die Verwaltung des Codes komplexer.
Resilienz	Die Anwendungsfunktionalität ist auf mehrere Services verteilt. Wenn ein Microservice ausfällt, ist die Funktionalität der anderen Microservices weiterhin verfügbar.	Ein Ausfall einer Komponente kann sich auf die Verfügbarkeit der gesamten Anwendung auswirken.
Skalierbarkeit	Jeder Microservice kann unabhängig von den anderen Services skaliert werden.	Die gesamte Anwendung muss skaliert werden, auch wenn die geschäftliche Anforderung darin besteht, nur bestimmte Teile der Anwendung zu skalieren.

Überlegungen zur Einführung der Microservices-Architektur

Berücksichtigen Sie beim Entwerfen einer neuen Anwendung die Microservices-Architektur für Anwendungen, die ein hohes Maß an Skalierbarkeit, Flexibilität und Zuverlässigkeit erfordern. Sie können für die Entwicklung jeder Komponente eine andere Programmiersprache und ein anderes Framework verwenden.

Ziehen Sie die Migration einer monolithischen Anwendung zu Microservices in Betracht, wenn Sie die Funktionalität der Anwendung in fokussierte Services mit jeweils begrenztem Umfang aufteilen können. Bei komplexen monolithischen Anwendungen, die nicht in die Microservices-Architektur migriert werden können, sollten Sie nur die neue Funktionalität als Microservices entwickeln.

Abhängigkeiten zwischen Services können sich darauf auswirken, wie viel der Anwendung bei einem erneuten Service-Deployment nicht verfügbar ist. Beheben Sie solche Abhängigkeitsprobleme während des Anwendungsdesigns.

Die Refactoring einer monolithischen Anwendung ist schwierig. Wenn Sie die Microservices-Architektur verwenden möchten, planen Sie sie ab Projektbeginn.

Berücksichtigen Sie die Komplexität verteilter Systeme bei der Entwicklung von Microservices, und denken Sie daran, dass Remote-Aufrufe langsam sind und ausfallen können. Je nach Anwendungsfall müssen Sie Konsistenz, Verfügbarkeit und Partitionstoleranz in Einklang bringen.

Bereiten Sie sich auf die betriebliche Komplexität vor, die mit der Microservices-Architektur verbunden ist. Bevor Sie eine monolithische Anwendung in die Microservice-Architektur verschieben, sollten Sie die folgenden Voraussetzungen erfüllen:

• Schnelles Provisioning: Schnelle Bereitstellung von Servern
• Basisüberwachung: Fähigkeit, Serviceprobleme und Geschäftsprobleme zu erkennen. Zu den Serviceproblemen gehören Serviceverfügbarkeit, Funktionsfehler und Performanceprobleme
• Schnelle Anwendungsbereitstellung: Möglichkeit, jeden Service schnell in Test- und Produktionsumgebungen bereitzustellen

Stellen Sie sicher, dass die Vorteile der Microservices-Architektur die Kosten überwiegen.

Informationen zum Kommunikationsmechanismus in einer Microservices-Architektur

In einer Microservices-Architektur werden die Services auf mehreren Servern ausgeführt. Die Kommunikation zwischen diesen Services erfolgt über Protokolle wie HTTP, AMQP und TCP. HTTP/REST und asynchrones Messaging sind die am häufigsten verwendeten Protokolle.

Eine REST-API für Webservices verwendet in der Regel das HTTP-Protokoll. Mit HTTP-Methoden (wie GET, POST, PUT und DELETE) können Clients mit einem URL (Uniform Resource Locator) auf die Anwendungsressourcen zugreifen und diese bearbeiten.

Clients senden eine Anforderung über eine REST-API an einen Service, die einen Einstiegspunkt für die Anwendungsfunktionalität darstellt. Clients können direkt oder über ein API-Gateway mit Microservices kommunizieren.

Ein API-Gatewaymuster definiert einen einzelnen Einstiegspunkt für alle Anforderungen an die Services. Wenn eine Clientanforderung eingeht, leitet das API-Gateway die Anforderung an den entsprechenden Service weiter.

Eine Variante des API-Gatewaymusters ist das Backend für Frontend-Muster, das ein separates API-Gateway für jede Art von Client definiert (z.B. ein Gateway für mobile Clients und ein anderes für Webanwendungen).

Die Minimierung der Kommunikation zwischen den Services wird empfohlen. Wenn Kommunikation wichtig ist, ist asynchrone Kommunikation vorzuziehen. Der Service, der die Anforderung sendet, kann weiterarbeiten, ohne auf eine Antwort zu warten.

Messaging-Queues und Streaming-Systeme sind ideale Methoden für die asynchrone Kommunikation. Wenn sie in die Datenbank integriert sind, bieten sie transaktionale Semantik für einen Datenvorgang und das Senden einer Nachricht. Dadurch werden Microservices einfacher und skalierbarer für die Bereitstellung. Die Verwendung von REST-APIs macht die Kommunikation zwischen Microservices exklusiv synchron und begrenzt in der Regel die Skalierung.

Erforderliche Services und Rollen

Diese Lösung erfordert die folgenden Services:

• Oracle Cloud Infrastructure Database (eine Vielzahl von Optionen, einschließlich Oracle Autonomous Database)
• Oracle Cloud Infrastructure Container Engine for Kubernetes
• Oracle Backend for Spring Boot and Microservices

Diese Rollen sind für jeden Service erforderlich.

Servicename: Rolle	Erforderlich für...
Oracle Cloud Infrastructure Database: SYSTEM oder ADMIN	Erstellen Sie bei der Konfiguration von Oracle Backend for Spring Boot and Microservices einen Benutzer für den Proxy-Datenbankzugriff. SYSTEM oder ADMIN funktionieren zwar, sind aber überprivilegiert und sollten nicht in Produktionsumgebungen verwendet werden.
Oracle Cloud Infrastructure Container Engine for Kubernetes: CLUSTER_MANAGE	Erstellen Sie ein Oracle Cloud Infrastructure Container Engine for Kubernetes-Cluster und einen Knotenpool mit drei Worker-Knoten.
Oracle Backend for Spring Boot and Microservices: ROLE_ADMIN	Installieren Sie Oracle Backend for Spring Boot and Microservices.

Unter Oracle-Produkte, -Lösungen und -Services erfahren Sie, was Sie benötigen.