Reaktiv

Reaktiv

0:00 Bis hierher haben wir gebaut, was eine Anwendung ausmacht: Konfiguration, Daten, zwei Schnittstellen. In diesem letzten Modul geht es um die Frage, was passiert, wenn es ernst wird — wenn nicht zehn Anfragen ankommen, sondern zehntausend, und wenn die Anwendung nicht allein ist, sondern einer von vielen Diensten. Drei Themen gehören dazu: reaktive Verarbeitung, damit Last nicht in Wartezeit umschlägt, Messaging als Alternative zum synchronen Zuruf, und Observability — denn was Sie nicht sehen können, können Sie auch nicht reparieren.

0:30 Das ist der Blick über den Tellerrand, und er verändert, wie Sie den Rest bewerten.

Reaktiv mit Quarkus

0:35 Fangen wir mit dem Begriff an, der am häufigsten verwendet und am seltensten erklärt wird. Was heißt "reaktiv" eigentlich konkret? Rund um das Wort hat sich viel Marketing angesammelt, und das macht es schwer, die eigentlich recht einfache Idee dahinter zu erkennen. Wir nehmen uns deshalb ein Alltagsbild zu Hilfe, klären dann, wann sich der Aufwand lohnt — und ebenso wichtig, wann nicht. Denn reaktiv ist ein Werkzeug, kein Qualitätsmerkmal.

1:03 Stellen Sie sich eine Kellnerin vor, die eine Bestellung aufnimmt und dann in der Küche neben dem Herd stehen bleibt, bis das Essen fertig ist. Das ist das klassische, blockierende Modell: Ein Thread nimmt die Anfrage entgegen und wartet, bis die Datenbank antwortet. Er tut nichts, aber er ist belegt. Reaktiv arbeitet wie eine Kellnerin, die die Bestellung durchgibt und in der Zwischenzeit andere Tische bedient. Der Thread ist nur beschäftigt, wenn wirklich etwas zu tun ist.

1:29 Dazu kommt Backpressure — ein Rückkanal, über den das System signalisiert, wenn es nicht hinterherkommt. Ohne den würde man den schnelleren Erzeuger einfach ins Leere laufen lassen, bis der Speicher voll ist. Der Gewinn ist am größten bei Anwendungen, die viel warten — auf Datenbanken, auf andere Dienste, auf das Netz. Genau das ist der Alltag in einer Microservice-Architektur.

1:52 Wenn Threads nicht mehr die Engstelle sind, verarbeitet dieselbe Maschine ein Vielfaches an gleichzeitigen Anfragen, mit weniger Speicher. Ein Wort zur Einordnung: Reaktiv ist kein Allheilmittel. Eine Anwendung, die hauptsächlich rechnet statt zu warten, gewinnt nichts, und der Code wird schwerer zu lesen. Die ehrliche Regel lautet: Nehmen Sie es, wenn Sie ein Problem damit lösen — nicht, weil es moderner klingt.

2:17 Worauf es hier ankommt, ist der Rückgabetyp. Statt eines fertigen Objekts liefert die Methode ein Versprechen: Ein Wert wird kommen, aber nicht jetzt. Das ist der ganze Unterschied — die Methode ist sofort fertig, der Thread wieder frei, und wenn die Daten da sind, macht das Framework weiter. Es gibt zwei Formen davon: eine für einen einzelnen Wert und eine für eine Folge von Werten.

2:40 Und das Schöne, das ich in Modul drei angekündigt habe: Sie brauchen dafür keine andere Erweiterung. Es ist dieselbe REST-Grundlage — nur mit einem anderen Rückgabetyp. Hier liegt der Fehler, der reaktive Projekte am häufigsten scheitern lässt: Reaktiv funktioniert nur durchgängig. Ein einziger blockierender Aufruf in der Kette — etwa ein klassischer Datenbanktreiber — und der gesamte Vorteil ist weg.

3:04 Schlimmer noch, Sie haben dann die Komplexität ohne den Gewinn. Deshalb braucht es den reaktiven Treiber und die reaktive Variante der Datenzugriffsschicht. Und noch eine ehrliche Einordnung: Relationale Datenbanken passen konzeptionell schlecht zu Datenströmen. Sie liefern Ergebnismengen am Stück, nicht tröpfchenweise.

3:23 Man kann das überbrücken, aber man sollte wissen, dass man es tut.

Messaging mit Quarkus

3:28 Kommen wir zur zweiten Möglichkeit, mit Last umzugehen — der, bei der man gar nicht erst wartet. Statt einen anderen Dienst anzurufen und auf seine Antwort zu hoffen, hinterlässt man ihm eine Nachricht. Das klingt nach einem kleinen Unterschied und ist in Wahrheit ein anderer Architekturstil, mit anderen Stärken und anderen Fallstricken.

3:47 Wir schauen uns an, wann sich der Wechsel lohnt und welche Broker Quarkus dafür anbietet. Der Unterschied lässt sich mit zwei Arten der Kommunikation beschreiben. Ein Anruf verlangt, dass beide gleichzeitig Zeit haben; eine Nachricht auf dem Anrufbeantworter nicht. Synchrone Aufrufe zwischen Diensten sind Anrufe: Wenn der andere gerade nicht kann, warten Sie — und Ihr Aufrufer wartet auf Sie.

4:10 So pflanzt sich eine Störung durch das ganze System fort. Beim Messaging schreibt ein Dienst eine Nachricht, ein anderer holt sie ab, wenn er soweit ist. Die beiden müssen nicht gleichzeitig verfügbar sein. Das ist der eigentliche Gewinn — nicht Geschwindigkeit, sondern Entkopplung. Der wichtigste Satz auf dieser Folie ist der erste: Fragen Sie nach, wenn jemand "sofort" verlangt.

4:33 Erstaunlich oft heißt "sofort" in Wahrheit "innerhalb von ein paar Sekunden", und dann ist asynchrone Verarbeitung nicht nur möglich, sondern besser. Denn sie ist von Natur aus nicht-blockierend und macht das System widerstandsfähiger: Fällt der Empfänger aus, sammeln sich die Nachrichten, statt dass Anfragen verloren gehen.

4:51 Praktisch nützlich ist außerdem, dass ein Erzeuger mehrere Empfänger bedienen kann. Was heute nur protokolliert wird, kann morgen zusätzlich eine Benachrichtigung auslösen — ohne dass der Erzeuger davon erfährt. Drei Optionen, und die Wahl richtet sich nach einer Frage: Wollen Sie Nachrichten noch einmal lesen können? Kafka speichert den Verlauf und erlaubt, ihn erneut abzuspielen — das ist wertvoll, wenn ein Fehler in der Verarbeitung steckte und Sie die Daten nochmals durchlaufen lassen wollen.

5:20 Die beiden anderen sind klassische Warteschlangen: Nachricht rein, Nachricht raus, weg. Das ist leichtgewichtiger und für viele Fälle völlig ausreichend. Ein Hinweis zur RabbitMQ-Erweiterung: Die ist weiterhin als Preview eingestuft, das heißt, Konfiguration und Schnittstellen können sich noch ändern. Für ein Produktivsystem sollte man das wissen — es spricht nicht dagegen, aber es gehört in die Entscheidung.

5:44 Hier greift wieder, was wir in Modul zwei bei der Datenbank gesehen haben: Quarkus startet Ihnen auch den Broker automatisch, solange Sie entwickeln oder testen. Das nimmt eine echte Einstiegshürde — Kafka lokal aufzusetzen war früher ein Nachmittagsprojekt. Der Stolperstein ist die Verwechslung: Das gilt nur für Entwicklung und Test.

6:03 In Produktion brauchen Sie einen richtigen Broker, betrieben, überwacht, mit Datensicherung. Trennen Sie beides sauber über Profile, dann kann nichts durcheinandergeraten. Der Fehler, den man nicht machen will, ist der, bei dem in Produktion versehentlich ein Wegwerf-Broker läuft und niemand es merkt, bis Nachrichten fehlen.

Observability mit Quarkus

6:22 Bleibt das dritte Thema — und das, das am häufigsten aufgeschoben und am bittersten vermisst wird. Solange alles läuft, wirkt Observability wie Aufwand ohne Gegenwert. An dem Tag, an dem eine Anfrage irgendwo in fünf Diensten hängen bleibt, entscheidet sie darüber, ob Sie das Problem in zehn Minuten finden oder in zwei Tagen.

6:41 Wir schauen uns an, welche vier Bausteine dazugehören und welche Fragen jeder von ihnen beantwortet. Solange eine Anwendung aus einem Stück besteht, reicht ein Blick ins Logfile. Sobald eine Anfrage durch fünf Dienste läuft, ist diese Zeit vorbei: Irgendwo dauert es zu lang, und niemand weiß wo. Observability ist der Sammelbegriff für das, was ein System von außen erklärbar macht — Health Checks für die Frage, ob ein Dienst überhaupt bereit ist, Tracing für den Weg einer Anfrage durch das System, Metriken für Zahlen über die Zeit, und Logging für die Details.

7:14 Vier Werkzeuge, vier Fragen. Wichtig ist die Reihenfolge im Projekt: Das gehört an den Anfang, nicht ans Ende. Nachrüsten ist möglich, aber ungleich mühsamer. Alle vier Bausteine sind Erweiterungen, die Sie hinzufügen und konfigurieren — Sie schreiben dafür kaum Code. Bei den Health Checks bekommen Sie fertige Adressen, die Kubernetes von sich aus abfragt. Für Tracing exportiert Quarkus über OpenTelemetry an ein Sammelsystem.

7:40 Die Metriken kommen über Micrometer, und beim Logging bleibt es bei den bekannten Fassaden, sodass Bibliotheken aus dem Ökosystem einfach mitschreiben. Der Aufwand ist also gering. Was Aufwand macht, ist die Frage dahinter: Welche Zahl sagt Ihnen tatsächlich, ob es Ihrer Anwendung gut geht? Das kann Ihnen kein Framework abnehmen.

8:01 Drei Typen, und die Verwechslung der ersten beiden ist der häufigste Anfängerfehler. Ein Zähler kennt nur eine Richtung: nach oben. Er beantwortet Fragen wie "wie oft ist das passiert". Ein Messwert kann steigen und fallen und beantwortet "wie viele sind es gerade" — offene Verbindungen, Einträge in einer Warteschlange. Wer die Warteschlangenlänge als Zähler modelliert, bekommt eine Kurve, die nur wächst und nichts aussagt.

8:25 Der dritte Typ misst Dauer und Verteilung und beantwortet die Frage, die Nutzer wirklich stellen: Wie lange dauert es? Wählen Sie den Typ nach der Frage, die Sie später stellen wollen — nachträglich ändern heißt, die Historie zu verlieren. Zum Schluss vier Punkte aus der Praxis. Erstens die Einordnung: Bei OpenTelemetry sind derzeit nur die Traces stabil, Metriken und Logs laufen dort als Tech Preview.

8:50 Für Metriken nehmen Sie deshalb Micrometer — das ist der belastbare Weg. Zweitens, ein Klassiker: Ein Readiness-Check, der nur meldet "ich laufe", ohne die Datenbank zu prüfen, ist wertlos. Der Dienst bekommt Verkehr und kann ihn nicht bedienen. Drittens gehören Trace- und Span-Kennung in jede Logzeile, sonst können Sie die Puzzleteile über Servicegrenzen hinweg nicht zusammensetzen.

9:14 Und viertens: einheitliche Logformate über alle Dienste. Damit endet unser Seminar — Sie haben jetzt alles beisammen, um mit Quarkus einen belastbaren Dienst zu bauen.