Microservices-Architektur

Aus dev.kaibel.net
Zur Navigation springen Zur Suche springen

Microservices-Architektur

Die Microservices-Architektur ist ein moderner Architekturstil in der Softwareentwicklung, bei dem eine Anwendung aus einer Sammlung **kleiner, unabhängiger und lose gekoppelter Dienste** besteht. Jeder Microservice erfüllt eine **spezifische Geschäftsaufgabe**, kommuniziert über klar definierte Schnittstellen (z. B. REST oder Messaging) und kann **unabhängig entwickelt, bereitgestellt und skaliert** werden.

Grundidee

Anstatt eine monolithische Anwendung zu entwickeln, wird das System in viele **kleine, eigenständige Dienste (Microservices)** zerlegt. Jeder Service ist für eine klar umrissene Funktion zuständig (z. B. Benutzerverwaltung, Bestellungen, Zahlungsabwicklung). 

+-------------+   +---------------+   +---------------+
|  User-Service  |   | Order-Service  |   | Payment-Service |
+-------------+   +---------------+   +---------------+
        \               |               /
         \              |              /
          +--------------------------------+
          |       API Gateway / Frontend   |
          +--------------------------------+

Eigenschaften

  • **Lose Kopplung:** Jeder Dienst funktioniert unabhängig.
  • **Hohe Kohäsion:** Jeder Dienst erfüllt genau eine Aufgabe.
  • **Eigenständige Entwicklung und Bereitstellung:** Teams können Services separat erstellen und deployen.
  • **Unabhängige Skalierbarkeit:** Nur benötigte Services werden skaliert.
  • **Technologische Freiheit:** Jeder Dienst kann in einer eigenen Sprache oder mit einem anderen Framework implementiert sein.
  • **Kommunikation über APIs oder Messaging-Systeme:** Meist via HTTP/REST, gRPC oder Message-Broker (z. B. Kafka, RabbitMQ).

Architekturprinzip

Microservices folgen dem Prinzip **„Do one thing and do it well“**. Sie kommunizieren typischerweise über leichtgewichtige Protokolle und nutzen eine zentrale Schnittstelle (z. B. API Gateway) für externe Zugriffe.

Aufbau einer Microservices-Anwendung

Komponente Beschreibung
API Gateway Zentrale Schnittstelle zwischen Clients und internen Services. Führt Routing, Authentifizierung und Aggregation durch.
Microservices Kleine, eigenständige Dienste mit eigener Datenhaltung und Logik.
Service Discovery Findet verfügbare Dienste dynamisch im Netzwerk.
Message Broker Vermittelt asynchrone Kommunikation zwischen Services.
Database per Service Jeder Dienst verwaltet seine eigene Datenbank (Isolation und Autonomie).
Monitoring & Logging Überwachung (z. B. Prometheus, Grafana) und zentrales Logging (z. B. ELK-Stack).

Kommunikation

1. Synchronous (z. B. REST, gRPC)

  • Direkte Kommunikation über HTTP oder RPC.
  • Einfach, aber potenziell blockierend.

2. Asynchronous (z. B. Message Queue, Event-Driven)

  • Nutzung von Nachrichten- oder Event-Systemen (z. B. Kafka, RabbitMQ).
  • Erhöht die Entkopplung und Fehlertoleranz.
Service A → Message Broker → Service B

Beispielhafte Dienste

  • **User-Service:** Verwaltung von Benutzerdaten
  • **Auth-Service:** Anmeldung, Tokens, Zugriffskontrolle
  • **Order-Service:** Bestellvorgänge
  • **Payment-Service:** Zahlungsabwicklung
  • **Notification-Service:** E-Mail- oder SMS-Benachrichtigungen

Vorteile

  • **Modularität:** Leicht verständliche und wartbare Komponenten
  • **Skalierbarkeit:** Nur stark belastete Services müssen skaliert werden
  • **Unabhängige Deployments:** Einzelne Dienste können ohne Downtime aktualisiert werden
  • **Technologische Vielfalt:** Verschiedene Sprachen oder Frameworks möglich
  • **Fehlertoleranz:** Fehler eines Services beeinträchtigen nicht zwingend das Gesamtsystem
  • **Einfache Continuous Delivery / DevOps-Integration**

Nachteile

  • **Komplexe Infrastruktur:** Hoher Aufwand für Orchestrierung, Kommunikation und Deployment
  • **Verteilte Datenhaltung:** Keine zentralisierte Datenbank, daher komplexe Transaktionen
  • **Monitoring und Debugging:** Schwieriger, da viele unabhängige Komponenten beteiligt sind
  • **Netzwerklatenzen:** Kommunikation über Netzwerke statt lokale Aufrufe
  • **Testaufwand:** Integrationstests über viele Services sind aufwendig

Vergleich: Monolith vs. Microservices

Merkmal Monolithische Architektur Microservices-Architektur
Aufbau Eine große Anwendung mit gemeinsamer Codebasis Viele kleine, unabhängige Dienste
Deployment Gesamtes System auf einmal Einzelne Services unabhängig
Skalierung Gesamte Anwendung Nur benötigte Services
Technologievielfalt Einheitlich Frei wählbar pro Service
Fehlertoleranz Ein Fehler kann alles stoppen Lokalisierte Fehler, System bleibt funktionsfähig
Entwicklungsaufwand Einfacher Start, schwer erweiterbar Komplexer Start, aber flexibel skalierbar

Beispielhafte Technologien

Kategorie Technologien / Tools
Kommunikation REST, gRPC, GraphQL, AMQP, Kafka
Containerisierung Docker, Podman
Orchestrierung Kubernetes, Docker Swarm, OpenShift
API Gateway Kong, NGINX, Traefik, AWS API Gateway
Service Discovery Consul, Eureka, Kubernetes DNS
Monitoring Prometheus, Grafana, Jaeger, ELK Stack
CI/CD Jenkins, GitLab CI, GitHub Actions, ArgoCD

Beispiel einer Microservices-Architektur

[Client / Frontend]
        ↓
[API Gateway]
   ↓          ↓
[User-Service]   [Order-Service]
       ↓               ↓
 [Auth-Service]     [Payment-Service]
        ↓               ↓
      [DB User]       [DB Orders]

Beste Praktiken

  • **Domain-Driven Design (DDD):** Fachliche Abgrenzung der Services nach Domänen.
  • **Database per Service:** Keine geteilten Datenbanken.
  • **Asynchrone Kommunikation:** Für bessere Entkopplung.
  • **Zentrales Logging & Tracing:** z. B. ELK oder Jaeger.
  • **API-Versionierung & Dokumentation:** z. B. mit OpenAPI/Swagger.
  • **Automatisiertes Deployment (CI/CD):** Für schnelle Updates ohne Ausfallzeiten.

Verbindung zu anderen Architekturen

Architektur Beziehung
Client-Server-Architektur Microservices erweitern das Client-Server-Prinzip durch viele kleine Serverinstanzen.
Event-Driven Architecture Häufige Basis für asynchrone Microservice-Kommunikation.
Service-Oriented Architecture (SOA) Microservices sind eine modernisierte, leichtere Form von SOA.
Reactor-Entwurfsmuster Wird oft intern in asynchronen Microservices zur Event-Verarbeitung genutzt.

Fazit

Die Microservices-Architektur ermöglicht **hochgradig modulare, skalierbare und flexible Anwendungen**, ist aber mit **komplexer Infrastruktur und höherem Managementaufwand** verbunden. Sie eignet sich besonders für **große, dynamische Systeme** mit mehreren Entwicklerteams und hohen Anforderungen an **Skalierbarkeit und Agilität**.

Siehe auch

Quellen

Abgerufen von „http://dev.kaibel.net/index.php?title=Microservices-Architektur&oldid=99“