Seite 2: Der Monolith steckt noch in der synchronen Kommunikation

Inhaltsverzeichnis

Die Probleme von Microservices sind zum großen Teil mit den gegenseitigen Netzwerkaufrufen verbunden. Die einfachste Möglichkeit, eine monolithische Anwendung zu Microservices zu migrieren, ist die Anwendung aufzuspalten und Methodenaufrufe zwischen Modulen (bzw. Microservices) mit synchronen Netzwerkaufrufen zu ersetzen. Eine asynchrone Umsetzung der Kommunikation bietet allerdings Vorteile wie eine geringere Latenz und eine losere Kopplung der Microservices. Die Schwierigkeit ist, sich von der Frage-Antwort-Interaktion loszulösen.

In Abbildung 1 sind die synchrone Kommunikation sowie zwei Ansätze für die asynchrone Umsetzung der Kommunikation zwischen Microservices gegenübergestellt. Asynchrone Kommunikation kann man über eine Message Queue (MQ) oder mit HTTP implementieren. Kommt eine Message Queue zum Einsatz, kommunizieren die Microservices nicht direkt miteinander, sondern senden und empfangen Ereignisse über sie (Microservice B, C und D rechts in Abb. 1). Bei asynchroner Interaktion über HTTP entfällt ein Warten auf die Antwort nach einer Anfrage (Microservice A rechts in Abb. 1). Ist ein Ergebnis notwendig, kommt es an einem weiteren Endpunkt regelmäßig zur Abfrage (Polling).

Anders als bei der synchronen Kommunikation müssen Microservices, die asynchron kommunizieren, meist keine besonderen Vorkehrungen für Ausfälle und Verzögerungen treffen, da sie nur mit der hoch verfügbaren Message Queue kommunizieren. Da der Empfänger einer Client-Anfrage, beispielsweise Microservice A, nicht auf die Antwort von anderen Microservices wie Microservice B, wartet, kann die asynchrone Kommunikation eine viel kürzere Antwortzeit erreichen. Bei einer synchronen Abarbeitung (Abb. 1 links) muss Microservice A auf Microservice B, C und D warten, bevor er die Client-Anfrage beantworten kann.

Ganzheitliche Module mit Self-contained Systems

Anders als ein Microservice besteht ein Self-contained System aus Webanwendungen (oder Web-Apps), die in sich geschlossen und möglichst unabhängig von anderen Anwendungen sind. Ein SCS kann Anwendungsfälle komplett bedienen und schließt dazu Daten und das zugehörige Frontend ein. Wenn Aufrufe zwischen SCS nötig sind (wie in Abb. 2 zwischen SCS A und SCS B) finden sie bevorzugt asynchron statt. Innerhalb jedes SCS können Entwickler über Modularisierung und Architektur frei entscheiden. Wie die Abbildung zeigt, kann ein SCS etwa aus einer Web-App bestehen oder in Microservices aufgeteilt sein.

Gegenüber klassischen Microservices haben SCS zusätzlich den Vorteil, dass Entwickler Entscheidungen zu Technik und Mikroarchitektur für zusammenhängende Komponenten fällen können, ohne dass andere SCS davon betroffen sind.