Integration von Microservices
Die Microservices innerhalb eines Systems müssen integriert werden und miteinander kommunizieren können. Die Integration kann dabei auf drei Ebenen stattfinden:
Abbildung: Integration von Microservices auf unterschiedlichen Ebenen
Das im Rahmen des Projektes entworfene System soll eine grafische Benutzeroberfläche erhalten. Folglich ist eine Integration der Microservices auf Ebene der UI möglich. Wie die Integration auf Ebene der UI aussehen könnte, ist in folgendem Kapitel beschrieben.
Eine Integration der Services ist aber auch auf Ebene der Logik möglich. Hierzu werden in der Regel Techniken und Protokolle verwendet wie REST, SOAP, RCP oder Messaging bzw. Eventing.
Obwohl eine REST-Api spezifiziert und implementiert wurde, hat sich das Team für die Kommunikation zwischen den Microservices und die Abbbildung Service übergreifender Transaktionen für eine Event-driven Architecture entschieden.
Im Vergleich zu REST, beidem es sich im Kern um ein synchrones Kommunikationsprotokoll handelt, kann durch die Abbildung der Kommunikation mit Hilfe von Eventing eine geringere Kopplung zwischen den Microservices erreicht werden. Darüber hinaus kann Eventing aufgrund seiner Asynchronität besser mit den Herausforderungen verteilter Kommunikation über das Netz umgehen, wie es bei solch einer Microservice-Architektur der Fall ist.
Die dritte Option stellt die Integration der Microservices auf Ebene der Daten dar. Hierzu werden in der Regel direkte Datenreplikationen zwischen den Datenbanken der Microservices bzw. Self Contained Systems verwendet. Typische Anwendungsbeispiele für Datenreplikationen sind Reporting-Anwendungen oder Data-Warehouse-Systeme.
Ein gemeinsames Datenbankschema, welches sich zwei oder mehr Microservices teilen, wäre technisch möglich, würde aber ein Verstoß gegen die Paradigmen der Microservice-Architektur darstellen. Hierbei wären die Microservices zu eng aneinander gekoppelt, da sie eine gemeinsame interne Datenrepräsentation hätten.
Zwischen den beiden Microservices Standortverlauf und Ungewöhnlicher Aufenthaltsort wäre eine Integration mit Hilfe einer Datenreplikationen denkbar gewesen, da es sich bei dem Microservice Standortverlauf imprinzip um eine Reporting-Anwendung handelt. Folglich würde der Microservice Standortverlauf in regelmäßigem Abständen die persistierten Daten von dem Service Ungewöhnlicher Aufenthaltsort abfragen.
Durch die Replikation würde eine redundante Speicherung der Daten entstehen. Das bedeutet, dass die Daten nicht sofort konsistent sind. Folglich dauert es einige Zeit, bis Änderungen überhall repliziert worden sind. Sofortige Konsistenz wäre für den gegebenen Anwendungsfall jedoch verzichtbar gewesen.
Problematisch ist jedoch, dass durch die Verwendung von Datenreplikationen die Kopplung zwischen den beiden Microservices steigt. Folglich wären die beiden Services stärker aneinander gebunden und könnten nicht mehr unabhängig voneinander weiterentwickelt und Deployed werden. Dies gilt insbesondere für das Datenmodell des Microservice Ungewöhnlicher Aufenthaltsort.
Ausgehend von dieser Bewertungsgrundlage hat sich das Team dazu entschieden, von einer Integration auf Ebene der Datenbank durch Datenreplikationen abzusehen. Statdessen sollen beide Microservices gleichermaßen auf die Orts Events horchen.
Abbildung - Integration von Microservices auf unterschiedlichen Ebenen: Eberhard Wolff, Microservices: Grundlagen flexibler Softwarearchitekturen, 2. Auflage, D Punkt Verlag, Heidelberg, 2018
Inhalt vergleichend: Eberhard Wolff, Microservices: Grundlagen flexibler Softwarearchitekturen, 2. Auflage, D Punkt Verlag, Heidelberg, 2018