Wenn man einführende Artikel zum Thema Microservices liest, so heißt es meist lapidar, dass Microservices über REST oder Messaging kommunizieren können (sollten). Die Frage, welche Kommunikation wann sinnvoll ist, wird meist zunächst nicht beantwortet. Dabei hat die Art der Kommunikation einen großen Impact auf die Vor- und Nachteile, die durch eine Microservices-Architektur entstehen.
Erklärtes Ziel einer Microservices-Architektur ist die Autonomie und Unabhängigkeit kleiner Anwendungen, die jeweils für eine bestimmte Fachlichkeit zuständig sind, deren Scope sich also an Bounded Context(en) ausrichtet. Damit die einzelnen Microservices möglichst autonom sind, müssen sie, so weit es geht, von anderen Services entkoppelt werden. In diesem Blogpost beschreibe ich die vier Ebenen der Entkopplung, die man mit Microservices erreichen kann, und für welche Anwendungsfälle sie jeweils Sinn ergeben.
Prämisse
Ich gehe davon aus, dass wir von Full-Stack-Microservices reden, die Persistenz und Fachlogik für einen bestimmten Bounded Context beinhalten. Vor kurzem bin ich mal wieder über eine Folie gestolpert, in der der Autor wie in der folgenden Grafik diverse Schichten aufgezeichnet hatte.
Wer das tatsächlich noch für eine gute Idee hält, sollte vielleicht erst einmal Was man vom Microservices-Hype (mindestens) mitnehmen sollte lesen, und Kaffeeküchengespräche: Microservices und Domain Driven Design kann auch nicht schaden.
Gut diskutieren kann man über den Punkt, ob Presentation immer mit in so einen Microservice gehört, oder ob das wieder eigene Microservices sind. Aber das ist nicht Thema dieses Posts.
Grundsätzlich haben wir in allen folgenden Ebenen separate Prozesse für jeden Microservice. Der Technologiestack eines Microservices ist ein Implementierungsinternum und kann je nach Anforderung sehr unterschiedlich aussehen. Wesentliche Punkte im Bereich Autonomie sind also bereits gegeben. Jetzt geht es darum, wie die Art der Kommunikation die Autonomie beeinflusst.
Arten der Kopplung
Ich unterscheide zwei Arten von Kopplungen, die ich im Folgenden kurz beschreibe.
Laufzeitkopplung
Eine Laufzeitkopplung ist gegeben, wenn zwei kommunizierende Services zur gleichen Zeit online sein müssen. Jederzeitiges Deployment ist dann nicht einfach möglich, man benötigt weitergehende Techniken wie Blue-Green-Deployments.
Organisatorische Kopplung – 2-Wege-Kommunikation vs. 1-Weg-Kommunikation
In der 2-Wege-Kommunikation wird eine Anfrage gestellt, auf die geantwortet wird. Für Frage und Antwort müssen jeweils Datenformate definiert werden, und meistens werden diese exklusiv für diese eine Schnittstelle definiert.
In der 1-Weg-Kommunikation gibt es nur einen Kommunikator, der ein Command oder Event schickt und keine Antwort erwartet.
Eine 1-Weg-Kommunikation ermöglicht eine stärkere Entkopplung als eine 2-Wege-Kommunikation.
Ebene 1: Synchrone Punkt-zu-Punkt-Verbindungen aka REST/SOAP über HTTP
- Starke Laufzeitkopplung.
- 2-Wege-Kommunikation.
In diesem konkreten Beispiel möchte ein Kunde ein Angebot für eine Lebensversicherung berechnen lassen. Der Lebenangebotsservice benötigt für die Berechnung allerdings das Geburtsdatum des Kunden und holt sich dieses über einen synchronen Aufruf des Partnerservices. Diese Art der Kommunikation ist wohl die am stärksten verbreitete.
Ebene 2: Asynchrone Punkt-zu-Punkt-Verbindungen aka Messaging über Queues
- Keine Laufzeitkopplung.
- 2-Wege-Kommunikation.
Auch hier möchte der Kunde ein Angebot berechnen lassen. Der Partnerservice wird nun über eine asynchrone Schnittstelle aufgerufen, in diesem Beispiel über eine Message in einer Queue. Der Lebenangebotsservice wiederum horcht auf eine Reply-Queue, und wenn der Partner das Geburtsdatum liefert, wird die Berechnung angestoßen und das Ergebnis anschließend zum Client gepusht. Dieses Vorgehen stellt neue Anforderungen an den Client. Gut nutzbar für Use-Cases, in denen Backend-Verarbeitungen länger dauern und der Kunde eh kein unmittelbares Feedback erwartet.
Ebene 3: Asynchrone Broadcasts aka Messaging über Topics
- Keine Laufzeitkopplung.
- 1-Weg-Kommunikation.
Hier schickt der Lebenangebotsservice ein AngebotAngefordertEvent, auf das sich andere Services registrieren können. Im Beispiel ist das ein Druckservice, der ein PDF mit dem Angebot erzeugt, und ein Kundenmanagementservice, der Daten darüber sammelt, wer welche Angebote angefordert hat. Sinnvoll also bei Fire-and-Forget-Szenarien.
Ebene 4: Datenduplikation über asynchrone Broadcasts
- Keine Laufzeitkopplung.
- 1-Weg-Kommunikation.
Hier schließt sich der Kreis: Wir haben den gleichen Use Case wie in Ebene 1. Der Lebenangebotsservice dupliziert allerdings nun das Geburtsdatum der Kunden in der eigenen Datenhaltung und kann so schnell antworten, ohne weitere Services aufzurufen. Die Information erhält er vom Partnerservice, der bei Partneränderungen ein PartnerChangedEvent schickt. Der Partnerservice behält so die Datenhoheit über das Geburtsdatum, aber der Lebenangebotsservice kann dieses Datum effektiv nutzen.
Fazit
Häufig wird nur die Ebene 1 verwendet, was kritisch ist, da man so automatisch wieder zu einer Layered Architecture mit synchronen Aufrufkaskaden kommt. Wenn man über Microservices und echte Entkopplung redet, darf man die Ebenen 2 bis 4 nicht aus dem Blick verlieren. Vor allem Ebene 4 wird häufig komplett ignoriert, da Datenduplikation in vielen Unternehmen ein Tabu ist. Das eigentlich zu lösende Problem in Bezug auf Daten ist allerdings die Datenhoheit – es darf nur einen geben, der die Daten ändern darf. Wenn das sichergestellt ist, ist es egal, an wie vielen Stellen das Datum dupliziert wird.
War dieser Beitrag hilfreich?
Weitere Beiträge
von Tobias Flohre
16.2.2022 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Tobias Flohre
Senior Software Developer
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.