Architektur

Vorlage: Ereignisgesteuerte Architektur

Producer, Kafka-Topics, Consumer, Dead-Letter-Queue und Analytics

Was drinsteckt

Nodes: 10
Packs: StackDaten
Kategorie: Architektur

Funktioniert im Free-Tarif: 15 Diagramm-Nodes + 150 Notizen, Texte, Sticker & Mindmap-Themen pro Diagramm.

In einer ereignisgesteuerten Architektur melden Services, was passiert ist, und andere Services reagieren darauf, statt sich direkt aufzurufen. Diese Vorlage zeigt, wie checkout-service OrderPlaced im orders-Topic eines Event-Brokers veröffentlicht, während payment-service und inventory-service dieses Topic abonnieren.

Danach veröffentlicht payment-service PaymentCaptured im payments-Topic, das shipping-service und notification-service verarbeiten. Ereignisse, die sich nicht verarbeiten lassen, landen in einer Dead-Letter-Queue, und ein Analyse-Warehouse erhält jedes Ereignis. Erzeuger stehen links, der Broker mit seinen Topics in der Mitte und die Verbraucher rechts, sodass sich der Fluss von links nach rechts liest.

Wann sie passt

Entwerfen, wie Services auf Geschäftsereignisse wie Bestellungen, Zahlungen und Lieferungen reagieren.
Zeigen, welches Team welches Ereignis veröffentlicht und wer davon abhängt.
Die Fehlerbehandlung prüfen: Wiederholungen, Dead-Letter-Queues und erneutes Abspielen.
Ein asynchrones System Menschen erklären, die Request-Response-APIs kennen.

So gehen Sie vor

Benennen Sie Topics und Ereignisse passend zu Ihrer Domäne um, mit Ereignisnamen in der Vergangenheitsform wie OrderPlaced.
Ergänzen Sie Erzeuger und Verbraucher aus dem Stack-Pack und verbinden Sie sie mit gestrichelten Kanten mit den Topics.
Fügen Sie für jeden Verbraucher, der fehlschlagen kann, eine Dead-Letter-Queue hinzu und notieren Sie, welche Ereignisse das Analyse-Warehouse speichert.
Teilen Sie das Diagramm mit jedem Team, das Ereignisse veröffentlicht oder verarbeitet, und speichern Sie eine Version, wenn sich ein Topic oder ein Ereignis ändert.

Fragen

Ist diese Vorlage an Kafka gebunden?

Nein. Der Broker-Rahmen heißt Kafka, weil das verbreitet ist, aber dasselbe Bild passt zu RabbitMQ, Amazon EventBridge, Google Cloud Pub/Sub oder Azure Service Bus: Benennen Sie Rahmen und Topics um.

Was ist eine Dead-Letter-Queue?

Eine Dead-Letter-Queue hält die Ereignisse fest, die ein Verbraucher auch nach seinen Wiederholungen nicht verarbeiten konnte. So gehen sie nicht verloren und blockieren die nachfolgenden Ereignisse nicht. Teams prüfen sie, beheben die Ursache und spielen sie erneut ab.

Kann ich Ereignisse und Anfrageflüsse in einem Diagramm zeigen?

Ja. Verwenden Sie durchgezogene Kanten für direkte Aufrufe und gestrichelte für Ereignisse, oder beginnen Sie mit der Microservice-Vorlage, die ein API-Gateway und einen Event-Bus zusammen zeigt.