Mittendrin.

Zurück

Flurfunk der eXperts.

Hier erfahren Sie mehr über eXperts, Technologien und das wahre Leben in der SDX.

Till Rebenich

Geschäftsprozesse mit Microservices abbilden

28.08.201708:00 Uhr , Till Rebenich

Microservices orientieren sich an der Realität: Die meisten fachlichen Prozesse laufen nicht isoliert im luftleeren Raum ab, sondern leben durch die Interaktion von Menschen oder Gruppen mit einem gemeinsamen Verständnis der Fachlichkeit (Bounded Contexts). Jeder Microservice implementiert die Logik, die den Prozess innerhalb des jeweiligen Kontexts optimal unterstützt. Die beteiligten Microservices werden in ein Gesamtsystem integriert.

Dieser Beitrag ist der 3. Teil einer Artikelserie zum Thema „Microservices“:

  1. Microservices als Teil der Digitalisierungsstrategie
  2. Microservices fachlich adäquat schneiden
  3. Geschäftsprozesse mit Microservices abbilden
  4. Time to Market mit Microservices DevOps reduzieren

Microservice Integration Patterns

Bei der Abbildung von fachlichen, serviceübergreifenden Prozessen innerhalb eines Microservices-Systems können zwei gegensätzliche Patterns angewendet werden [1].

Orchestration

Beim Orchestration-Pattern erfolgt die Abwicklung des Prozesses über ein steuerndes Organ; das ist in der Regel ein Microservice. Der steuernde Service kapselt das Wissen über den Gesamtprozess, insbesondere über die Abfolge der einzelnen Prozessschritte sowie die jeweils beteiligten Microservices. Er triggert diese direkt an, um den jeweiligen Prozessschritt auszuführen. Dieses Prinzip ist mit dem eines Orchesters vergleichbar, bei dem der Dirigent den Takt vorgibt.

Microservices Orchestration

Orchestration hat den Vorteil der einfachen Umsetzbarkeit; der Koordinator (= Dirigent) redet direkt mit der API der ausführenden Services. Allerdings zahlt man dafür einen Preis:

  • Der Koordinator muss die ausführenden Services „kennen“. Hierdurch entstehen direkte Abhängigkeiten und damit eine enge Kopplung.
  • Die Logik des Gesamtprozesses ist im Koordinator implementiert. Ändert sich der Gesamtprozess, müssen häufig sowohl der Koordinator als auch die ausführenden Services angepasst werden.
  • Der Ansatz verleitet zur Verlagerung von mehr und mehr Logik in den Koordinator, wodurch dieser aufgebläht und seine Wartung erschwert wird. Der Koordinator muss sich auch um etwaige Fehler im Gesamtprozess kümmern, wenn z. B. einer der aufgerufenen Services nicht verfügbar ist.
  • Ist eine größere Anzahl an Microservices involviert, können sogenannte „Chatty Services“ entstehen, bei denen zu viel direkte Kommunikation über das Netzwerk stattfindet – mit entsprechender Zunahme der Latenzzeiten.

Choreography

Anders als beim Orchestration-Pattern gibt es beim Choreography-Pattern in der Regel keine zentrale Steuerungsinstanz. Stattdessen reagieren die am Geschäftsprozess beteiligten Services jeweils auf bestimmte Ereignisse im Prozess. Tritt ein Ereignis ein, wird dies über ein zentrales Nachrichtensystem an alle beteiligten Services kommuniziert. Das ist vergleichbar mit einem Ballett: die Tänzer orientieren sich an den Bewegungen der anderen und passen sich so an, dass ein synchroner Gesamteindruck entsteht.

Disclaimer:
Gemeint sind nicht Nachrichtensysteme à la Enterprise Service Bus (ESB), sondern Message-Broker-Systeme, die sich ausschließlich auf die Verteilung von Nachrichten konzentrieren. Das bedeutet: keine Businesslogik, keine Validierung und keine Transformationslogik auf dem Bus!

Microservices Choreography

Choreography hat den Vorteil, dass die beteiligten Microservices maximal entkoppelt werden. Es gibt keinen zentralen Koordinator, sondern die Koordination erfolgt ausschließlich über Nachrichten. Einzelne Services bekunden ihr Interesse an bestimmten Typen von Nachrichten durch eine Subscription auf dem Nachrichtensystem.

Auch Choreography hat ihren Preis:

  • Das Nachrichtensystem ist das Rückgrat und muss entsprechend robust ausgelegt sein. Besonderes Augenmerk liegt auf der zuverlässigen Zustellung von Nachrichten und einem konsistenten Verhalten im Fehlerfall. Moderne Nachrichtensysteme garantieren, dass Nachrichten Systemausfälle „überleben“.
  • Das Wissen über den Gesamtprozess ist auf die am Prozess beteiligten Microservices verteilt. Es gibt keine zentrale Instanz, die dieses Wissen vorhält. Entsprechend aufwändiger gestalten sich Integrationstests und Fehlersuche.

Welches Pattern ist „besser“?

Die Antwort auf diese Frage ist „It Depends!“. Beide Patterns haben ihren Platz. Am Ende hängt die Wahl von verschiedenen Faktoren ab:

  1. Anzahl der beteiligten Microservices: Je höher die Zahl der beteiligten Services, desto höher die Gefahr, dass bei Orchestration zu viel Logik beim Koordinator implementiert ist und „Chatty Services“ entstehen. In diesem Fall ist Choreography als Pattern zu bevorzugen.
  2. Komplexität des fachlichen Prozesses: Je komplexer der fachliche Prozess, desto mehr sollte der Fokus auf Entkopplung, d. h. Choreography, liegen.
  3. Verfügbarkeit von Messaging-Infrastrukturen: Choreography setzt eine Messaging-Infrastruktur (Message Broker) voraus. Ist eine solche nicht vorhanden, ist das Pattern schwer umsetzbar.
  4. Entwicklerhintergrund und -erfahrung: Choreography erfordert ein Umdenken bei Entwicklern, da die Kommunikation komplett über asynchrones Messaging stattfindet. Dies muss bei der Implementierung berücksichtigt werden.
  5. Nichtfunktionale Anforderungen: Bei hohen Anforderungen hinsichtlich Verfügbarkeit und Antwortverhalten ist Choreography besser geeignet.

Ich persönlich bevorzuge das Choreography-Pattern, da es mir bestmögliche Entkopplung und Serviceautonomie ermöglicht. Die gemischte Verwendung von Orchestration und Choreography ist grundsätzlich möglich, allerdings rate ich aus Konsistenzgründen davon ab! Je größer das Gesamtsystem, desto schwieriger wird es, den Überblick darüber zu behalten, wo welches Pattern eingesetzt wurde. Das erschwert die Wartbarkeit.

Datenintegration

Microservices folgen dem „Share Nothing“-Prinzip. Das bedeutet unter anderem, dass Microservices jeweils auf ihrer eigenen Datenbank arbeiten und diese nicht mit anderen Microservices teilen. Eigene Datenbank bedeutet hierbei nicht, dass man eine separate DBMS-Instanz pro Service hosten muss. Eine logische Trennung ist ausreichend. Alternativ können auch Datenbanken unterschiedliche Arten von DBMS je Microservice eingesetzt werden.

Wie werden nun aber „gemeinsame“ Daten zwischen Services ausgetauscht?

Hier gibt es je nach Integrations-Pattern zwei Möglichkeiten:

  1. Kommt Orchestration als Integrations-Pattern zum Einsatz, so muss eine Datenänderung, die potentiell andere Microservices betrifft, mittels direkter Aufrufe kommuniziert werden.
  2. Bei Choreography wird eine Datenänderung als Event im zentralen Messaging-System publiziert. Interessierte Microservices subscriben sich auf die Änderung und können ihrerseits darauf reagieren.

Jeder Service übernimmt nur die Daten, die er für die Abbildung der Fachlichkeit innerhalb seines Bounded Contexts tatsächlich benötigt. Bezogen auf das Beispiel aus meinem letzten Beitrag: Time Recording übernimmt den Namen des Kunden (Customer), während Billing nur dessen Rechnungsadresse und Zahlungsmodalitäten abgreift.

Generell gilt: Microservice-Systeme sind verteilte Syteme! Diese sind in aller Regel nicht konsistent im Sinne von ACID, sondern folgen dem BASE-Prinzip. Das Stichwort lautet „Eventual Consistency„. Eine Änderung wird an alle Teilnehmer des Systems propagiert. Nach einer gewissen Zeit sind alle Teilnehmer in Bezug auf die Änderung konsistent. Die Dauer richtet sich nach den Anforderungen des Gesamtprozesses. Verteilte ACID-Transaktionen sind aufgrund ihrer Nachteile keine Option!

Eventual Consistency orientiert sich an der Realität. Die meisten Prozesse im richtigen Leben (auch Banküberweisungen (!)) laufen nach diesem Prinzip ab.

Fazit

Für die Abbildung von Geschäftsprozessen müssen in der Regel mehrere Microservices in einem integrierten Gesamtsystem zusammenarbeiten. Hierfür stehen zwei Patterns zur Verfügung: Orchestration mit zentraler Prozesssteuerung und Choreography mit nachrichtenbasierter Kommunikation. Da Microservice-Systeme verteilte Systeme sind, kommt bei beiden Patterns Eventual Consistency zum Einsatz.

[1] Sam Newman, Building Microservices – Designing Fine-Grained Services, O’Reilly, 2015<

2 Kommentare

28.08.201714:01 Uhr
Sebastian

Als Alternative zu einer Messaging Infrastruktur wäre auch denkbar einem Microservice einen zusätzlichen Endpunkt (mit zugehörigem „EventStore“) zur Abfrage aufgelaufener Events zu spendieren („Gib mir alle Events zwischen #startIndex und #endIndex“). Subscriber könnten dann „wann immer Zeit ist“ einen Schwung Events abfragen und verarbeiten. Damit weckt nicht jedes anfallende Event einen Subscriber sondern erlaubt eine Batch-Behandlung. Fallen Publisher oder Subscriber zeitweise aus ist das auch kein großes Problem, weil die Events nach wie vor verfügbar sind.

06.09.201712:05 Uhr
Till Rebenich

Hallo und vielen Dank für Ihre Beteiligung! Ja, das ist möglich. Ich persönlich schreibe mir in der Regel einen Adapter, der vor die dahinterliegende „Infrastruktur“ gestellt wird und mir unterschiedliche Methoden für den Zugriff auf Nachrichten bereitstellt. Innerhalb des Adapters ist der Zugriff auf das darunterliegende Messaging System (Message Broker, Messaging Service mit Event Store, etc.) implementiert. Je nach Anwendungsfall werden über den Adapter per Observer-Pattern Nachrichten gepusht (auch das kann übrigens batchweise erfolgen) oder der Abnehmer holt aktiv die auflaufenden Nachrichten ab. Die meisten Message Broker Systeme bieten übrigens ebenfalls Nachrichtenpersistenz an, d. h. auch hier gehen Nachrichten nicht verloren, sondern werden automatisch zugestellt, wenn der Abnehmer wieder verfügbar ist.

Dein Kommentar wartet auf Freischaltung.

Artikel kommentieren

Zurück

Tag Cloud


Kontakt aufnehmen


Anrufen

Gerne beantworten wir Ihre Fragen in einem persönlichen Gespräch!


Kontakt aufnehmen

Schreiben Sie uns eine E-Mail mit Ihren Fragen und Kommentaren!