Microservices Architektur
Microservices haben sich als der beste Weg erwiesen, um eine skalierbare, belastbare und verteilte serviceorientierte Architektur zu implementieren. Es gibt eine Reihe von Gestaltungsprinzipien, die uns bei der Dimensionierung der Dienste helfen, damit wir nicht am Ende einen umfangreichen (monolithischen) Service erstellen. Es gibt jedoch verschiedene Möglichkeiten und Herausforderungen, dieses Design zu implementieren, und es liegt im Ermessen des Architekten, den richtigen Ansatz zu wählen, der zum Geschäftsprozess passt.
Die Tools und Technologien entwickeln sich sehr schnell weiter, um den Herausforderungen und Anforderungen gerecht zu werden, so dass man davon ausgehen kann, dass sehr häufig erhebliche Änderungen vorgenommen werden. Dank des Charakters von Microservices können häufige Änderungen mit deutlich weniger Aufwand und Auswirkungen vorgenommen werden und passen gut zum agilen Entwicklungsprozess.
Wenn Sie sich für die Einführung von Microservices entscheiden, sind viele wichtige Entscheidungen zu treffen. Im Folgenden werden wir uns die grundlegenden Prinzipien, Tools und Technologien ansehen, die für den Aufbau einer Microservices Architektur erforderlich sind.
Gestaltungsprinzipien
- Autonome
- Hohe Kohäsion
- Widerstandsfähigkeit
- Datenkonsistenz
- Automatisierung
Anzuwendende Technologien
- Kommunikation (synchrone und asynchrone)
- Containerisierung
- Dienstregistrierung und -suche
- Sicherheit
- Anwendungsskalierung und Management
- Zentralisierte Überwachung und Protokollierung
- Konfigurationsmanagement
- Container-Orchestrierung
- Infrastruktur als Code
- Kontinuierliche Integration und Bereitstellungspipeline
Der „Domain Driven“ Ansatz
Das „Domain Driven“ Design geht Hand in Hand mit der Microservices Architektur. Der allererste Schritt zur Microservices Architektur ist die Festlegung der Grenzen für jeden Dienst, und bei DDD geht es um die Definition der Grenzen.
Die Architekten benötigen die Hilfe von Fachexperten, um die Bereiche und ihre interne Dynamik zu verstehen, damit sie die Grenzen erkennen können. Es muss eine Bereichsanalyse durchgeführt werden, vorzugsweise eine „Event Storming“-Sitzung, in der die Experten und das technische Team gemeinsam iterativ diskutieren und den Bereich erkunden, um Folgendes zu ermitteln
- Domain Events: Ereignisse, die wichtig sind und den Geschäftsprozess vorantreiben.
- Befehle: Die Ereignisquellen, d. h. die Aktionen, die die „Domain Events“ auslösen. Es kann sich um eine Benutzeraktion oder eine vom System generierte Aktion handeln.
- Allgegenwärtige Sprache: Gemeinsame Geschäftsterminologien, die die Semantik des Bereichs darstellen und überall verwendet werden müssen.
- Aggregat: Repräsentiert den Zustand und das Verhalten. Führt die Operation aus, um die der Befehl bittet, und gibt die entsprechenden Ereignisse aus.
- Richtlinien: Geschäftsregeln, die angeben, was als Folge eines durch einen Befehl ausgelösten Ereignisses geschehen soll. Eine Reihe von Richtlinien bilden zusammen einen Geschäftsprozess.
- Begrenzter Kontext: Eine Gruppe von verwandten Aggregaten und Konzepten aus einem begrenzten Kontext. Ein Bounded Context zieht die Grenze und korreliert mit einem Microservice.
Aus dem in der Event Storming-Sitzung gewonnenen Fachwissen kann ein Geschäftsprozessmodell abgeleitet werden. Domain Driven Design in Kombination mit der Modellierung von Geschäftsprozessen unter Verwendung von Business Process Model and Notations (BPMN) kann uns helfen, komplexe Probleme der realen Welt zu lösen und hochgradig kohärente verteilte Systeme zu entwerfen.
DDD sollte nur für Microservices mit komplexen Geschäftsregeln angewendet werden. Einfachere Microservices können mit einfachen Ansätzen verwaltet werden. Die technische Implementierung der einzelnen Microservices kann sich je nach Anforderung und Funktionalität unterscheiden. Ein Microservice kann zum Beispiel so einfach sein wie eine serverlose Funktions-App in Azure, ein Service mit mehr Geschäftsregeln und zur Vermeidung von Duplizierung kann das Specification-Muster implementieren, ein Service mit verteilten Transaktionen kann das SAGA-Muster implementieren oder auf BPMN-Automatisierung wie Camunda zurückgreifen, ein Service, der hohe Leistung und Skalierbarkeit erfordert, kann das CQRS-Muster implementieren, ein Audit-bezogener Service könnte sich für Event-Sourcing entscheiden usw.