hanakaz1991 - stock.adobe.com
Was sind die wichtigsten Designprinzipien für Microservices?
Bei der Gestaltung eines Microservices sollten Entwickler speziell auf fünf Prinzipien achten, damit dieser zusammen mit anderen Services und Komponenten richtig funktioniert.
Eine Microservices-Architektur erfordert eine sorgfältig zusammengestellte Gruppe einzelner Komponenten, die effizient zusammenarbeiten. Modulare Komponenten hängen voneinander ab, wenn sie zusammen eine größere Anwendung bilden.
Wenn Entwickler Microservices auf ihre einzigartigen Bestandteile reduzieren, muss ein Microservice so aufgebaut werden, dass er in der für den Gesamtnutzen der Anwendung wesentlichen Weise funktioniert.
Die fünf wesentlichen Gestaltungsgrundsätze für einen Microservice sind:
- Er hat nur einen Zweck.
- Er ist diskret.
- Er enthält seine eigenen Daten.
- Er ist transportabel.
- Es ist vergänglich.
Es hat nur einen Zweck
Weisen Sie die Einstiegspunkte in einen Microservices einem einzigen Zweck zu. Nehmen wir zum Beispiel an, ein Autohändler möchte eine Anwendung erstellen, die potenzielle Händler untereinander und mit der Organisation selbst verbindet. Eine Microservices-Komponente befasst sich ausschließlich mit dem Handel von Autos, zum Beispiel Kauf und Verkauf. Sie hat keinen anderen Zweck.
Der Zahlungsverkehr wird wiederum über einen anderen Microservice gehandhabt. Die beiden Microservices können zwar in Verbindung miteinander genutzt werden, aber die Services werden nicht vermischt. Jeder Service verarbeitet etwas anderes und kann für sich alleine stehen.
Er ist diskret
Eine andere Bezeichnung für dieses Designprinzip ist: Er ist gut gekapselt. Die Logik und Daten, die ein Microservice für seine Arbeit benötigt, sind intern und von anderen Komponenten des Microservice isoliert.
Während ein Microservice seine eigene Konfiguration benötigt, damit er richtig funktioniert, sollte diese Konfiguration die Konfiguration eines anderen Microservice nicht stören. Dieses Konstruktionsprinzip des Microservice ist besonders wichtig, wenn Entwickler auf- oder abwärts skalieren müssen, um Lastanforderungen zu erfüllen.
Er enthält seine eigenen Daten
Ein Microservice sollte nicht nur seine eigenen Daten enthalten, sondern seine Daten sollten auch unabhängig von allen anderen Microservice-Komponenten bleiben. In einigen Fällen verfügt ein Microservice idealerweise über eine eigene Datenbank. In anderen Fällen wird der Microservice eine Datenbank mit anderen teilen, aber jeder Microservice wird seine eigenen Tabellen innerhalb der Datenbank haben.
In der Regel verwenden Entwickler gemeinsam genutzte Datenbanken, um Kosten zu sparen. Dies verstößt jedoch gegen die Designprinzipien der Microservices.
Entwickler müssen beim Design sowohl Datenunabhängigkeit als auch Redundanz berücksichtigen. Auch wenn Entwickler oft den Grundsatz unterstützen, dass jeder Microservice seine eigenen Daten enthält, was zu Datenduplizierung auf der Anwendungsebene führen kann, müssen sie sich erst dazu durchringen, Datenredundanz als Teil ihres Microservice-Designs zu akzeptieren.
Eine einfache Möglichkeit, Datenduplizierung zwischen verschiedenen Microservices unterzubringen, ist die Betrachtung von Kundendaten, die bei verschiedenen Online-Händlern gespeichert sind. Zum Beispiel kann ein bestimmter Benutzer bei Amazon und eBay registriert sein. Beide Websites haben ein Duplikat der Daten dieses Benutzers, aber jede Website ist diskret und gut gekapselt. Daher weiß keine der beiden Websites von der Existenz des Benutzers auf der jeweils anderen Website, es sei denn, sie hat eine Genehmigung für die Daten dieser Website erhalten.
Er ist transportabel
Wenn ein Microservice transportabel ist, bedeutet dies, dass er zum Beispiel in ein Container-Image oder eine serverlose Funktion „verpackt“ und jederzeit über einen CI/CD-Prozess für ein bestimmtes Ziel bereitgestellt werden kann.
Beispielsweise kann ein Entwickler einen transportablen Microservice zu einem Cloud-Provider wie Google Cloud in einem Moment bereitstellen. Wenn jedoch eine Situation eintritt, in der der Microservice bei AWS bereitgestellt werden muss, sollte es für einen Entwickler nur wenig Aufwand erfordern, den Microservice dorthin zu übertragen.
Er ist vergänglich (ephemer)
Ein vergänglicher (ephemerer) Microservice bedeutet, dass er jederzeit zerstört und sofort wieder in seinen letzten bekannten Zustand zurückversetzt werden kann.
Die kurzlebige Natur eines Containers hat nicht nur Auswirkungen darauf, wie der Anwendungsstatus verwaltet wird, wenn ein bestimmter Container jederzeit offline gehen könnte, sondern auch darauf, wie aktive Threads verwaltet werden und sichergestellt wird, dass keine thread-basierten Abhängigkeiten im Code existieren.
Diese fünf Microservices-Designprinzipien sollten im Mittelpunkt jeder Architekturdiskussion stehen. Betrachten Sie jedes Element sorgfältig, um eine Architektur zu erstellen, die für Ihre Anwendung effizient funktioniert.
