1. Motivation zur Einführung einer MS basierten Architektur, nicht nur, weil MS gerade „in“ sind, sondern um schnelles Wachstum zu ermöglichen, indem große Probleme in kleine, handhabbare, Teilprobleme zerlegt werden.

2. „Eventing“ stellt eine gute Methode dar, um die Abhängigkeiten zwischen den verschiedenen MS in allen Stadien (Entwicklung, Deployment, Betrieb) möglichst gering zu halten.

3. MS können mit synchronen APIs betrieben werden, dies führt aber zu mehreren Problemen:

   ◦ Die Widerstandsfähigkeit des Gesamtsystems sinkt, da einzelne ausgefallene MS alle von diesen abhängigen MS aufhalten oder blockieren können. Gegenmaßnahmen wie Timeouts oder Circuit Breaker mindern die Auswirkungen, lösen jedoch nicht das zugrundeliegende Problem. (Timeouts sollten kurz sein [300 ms], da sie sonst duch blockieren von Workerthreads sogar kontraproduktiv wirken können.)

   ◦ Es bilden sich Ketten von abhängigen MS heraus. Die Laufzeiten der einzelnen Aufrufe können sich so addieren und die Performance sinkt unter die eines vergleichbaren Monolithen. Auch hier lösen die Gegenmaßnahmen wie Caching oder Parallelisierung das zugrundeliegende Problem nicht.

4. Die eigentliche Lösung wird durch das Motto – „having data before needing data“ – beschrieben. Gemeint ist, dass jeder MS alle Daten die er zur Verarbeitung einer gestellten Anfrage benötigt bereits vorliegen haben sollte. Es müssen also nicht rekursiv weitere MS zur Abarbeitung einer Anfrage herangezogen werden.

5. Praktisch wird dies durch „Eventing“ erreicht. Ziel des Eventings ist es, dass jeder Service über eine Art eigene DB-Replikation verfügt und sich mithilfe von Events bereits mit den benötigten Daten versorgt hat.

6. Ein „Event“ ist in diesem Kontext die Repräsentation eines Ereignisses, welches in der Domäne in der Vergangenheit stattgefunden hat. Events beschreiben dabei immer auch die Domäne und tragen zur ubiquitous language bei. Das Event besteht dabei aus zwei Komponenten:

   ◦ Der Entität, welche das Event betrifft und welches vollständig in dem Event enthalten ist.

   ◦ Dem „state change“, also dem Zustandsübergang des Objekts.

7. Die Aussage „don‘t repeat yourself“ gilt im Kontext der MS Architektur nicht mehr. Replikation von Daten und Funktionen ermöglicht erst den effizienten Einsatz von MS.

8. Events werden als eigene API betrachtet. Beim Aufbau einer Eventing API muss folgendes beachtet werden:

   ◦ Events müssen „self contained“ und transaktional Vollständig sein. Keine weiteren Events oder API Aufrufe dürfen erforderlich sein, um einen konsistenten Zustand zu erreichen. Events müssen immer das komplette Aggregat enthalten.

   ◦ Es darf nur publiziert werden was sicher passiert und abgespeichert ist. Ein Event darf erst als gelesen markiert werden, wenn es wirklich vollständig gelesen wurde.

   ◦ Events ersetzen immer nur „GET“. Sie stellten nur da, was passiert ist und können daher niemals eine „Aufforderung etwas zu tun“ darstellen.

   ◦ Events bieten maximal „eventual consistency“ und eignen sich nicht für zeitkritische Datenflüsse oder generell Abläufe für die ein bestimmter Fluss erforderlich ist.

   ◦ Services müssen Events idempotent verarbeiten und damit rechnen, dass Nachrichten mehrfach zugestellt werden.

(Rechtsklick -> Ziel speichern unter)

Kernaussagen (PDF)