CQRS ist ein sehr gutes Werkzeug für die Programmierung. Es ist sehr hilfreich und kann Ihnen viele Dinge erleichtern, weiterlesen und alles über CQRS lernen.
Was ist CQRS?
CQRS ist ein Architekturmuster, bei dem das Akronym für Command Query Responsibility Segregation steht. Wir können über CQRS sprechen, wenn Datenleseoperationen von Datenschreiboperationen getrennt sind und auf einer anderen Schnittstelle auftreten.
In den meisten CQRS-Systemen verwenden Lese- und Schreibvorgänge unterschiedliche Datenmodelle, manchmal sogar unterschiedliche Datenspeicher. Diese Art der Trennung erleichtert das Skalieren, Lesen und Schreiben sowie die Steuerung der Sicherheit, erhöht jedoch die Komplexität Ihres Systems.
Node.js at Scale ist eine Sammlung von Artikeln, die sich auf die Bedürfnisse von Unternehmen mit größeren Node.js-Installationen und fortgeschrittenem Node konzentrieren.
Der Grad der Trennung kann in CQRS-Systemen variieren:
- Einzelne Datenspeicher und separates Modell zum Lesen und Aktualisieren von Daten.
- Separate Datenspeicher und separates Modell zum Lesen und Aktualisieren von Daten.
Bei der einfachsten Datenspeichertrennung können wir schreibgeschützte Replikate verwenden, um eine Trennung zu erreichen.
Warum und wann CQRS verwenden?
In einem typischen Datenverwaltungssystem werden alle CRUD-Operationen (Erstellen, Löschen, Lesen, Aktualisieren) auf derselben Schnittstelle von Entitäten in einem einzelnen Datenspeicher ausgeführt. Erstellen, Aktualisieren, Abfragen und Löschen von Tabellenzeilen in einer SQL-Datenbank über dasselbe Modell.
CQRS glänzt wirklich im Vergleich zum herkömmlichen Ansatz (unter Verwendung eines einzelnen Modells), wenn komplexe Datenmodelle zur Validierung erstellt werden, und erfüllt Ihre Geschäftslogik, wenn Datenmanipulationen auftreten. Lesevorgänge im Vergleich zu Aktualisierungs- und Schreibvorgängen können sehr unterschiedlich oder viel einfacher sein, z. B. der Zugriff auf nur eine Teilmenge Ihrer Daten.
Ein sehr anschauliches Beispiel
In unserem Node.js-Überwachungstool verwenden wir CQRS, um die Speicherung und Darstellung der Daten zu trennen. Wenn Sie beispielsweise eine verteilte Tracking-Visualisierung in unserer Benutzeroberfläche anzeigen, wurden die dahinter stehenden Daten in kleineren Teilen von den Anwendungsagenten unserer Kunden an unsere Public Collector-API gesendet.
In der Collector-API führen wir nur eine Thin-Validierung durch und senden die Daten zur Verarbeitung an eine Messaging-Warteschlange. Am anderen Ende der Warteschlange konsumieren Mitarbeiter Nachrichten und lösen alle erforderlichen Abhängigkeiten über andere Dienste auf. Diese Mitarbeiter speichern auch die transformierten Daten in der Datenbank.
Wenn ein Problem auftritt, geben wir die Nachricht mit einem exponentiellen Fallback und einer maximalen Begrenzung unserer Messaging-Warteschlange zurück. Im Vergleich zu diesem komplexen Datenschreibfluss fragen wir auf der Rendering-Seite des Flusses nur eine Lesereplikatdatenbank ab und visualisieren das Ergebnis für unsere Kunden.
CQRS und seine Ereignisquelle
Ich habe oft gesehen, dass Menschen diese beiden Konzepte verwechseln. Beide werden häufig in ereignisgesteuerten Infrastrukturen sowie in ereignisgesteuerten Mikrodiensten verwendet, haben jedoch sehr unterschiedliche Bedeutungen.
Berichtsdatenbank - Denormalizer
In einigen ereignisgesteuerten Systemen ist CQRS so implementiert, dass das System eine oder mehrere Berichtsdatenbanken enthält.
Eine Berichtsdatenbank ist ein völlig anderer Nur-Lese-Speicher, der Daten im besten Format modelliert und aufbewahrt, um sie darzustellen. Es ist in Ordnung, es in einem Standardformat zu speichern, um es für die Kundenbedürfnisse zu optimieren. In einigen Fällen enthält die Berichtsdatenbank nur abgeleitete Daten, auch aus mehreren Datenquellen.
In einer Microservices-Architektur rufen wir einen Denormalizer-Dienst auf, wenn er auf bestimmte Ereignisse wartet und eine Datenbank mit darauf basierenden Berichten verwaltet. Der Client liest die Berichtsdatenbank aus dem denormalisierten Dienst.
Ein Beispiel könnte sein, dass der Benutzerprofildienst ein Ereignis ausgibt user.edit mit nützlichen Informationen {id: 1, name: 'Mary Anne', Status: 'churn'}Der Denormalizer-Dienst wartet darauf, speichert es jedoch nur in seiner Berichtsdatenbank {Name: 'Mary Anne'}, weil der Client nicht am internen Abwanderungszustand des Benutzers interessiert ist.
Es kann schwierig sein, eine Berichtsdatenbank synchron zu halten. Normalerweise können wir nur eine eventuelle Konsistenz anstreben.
Andere
CQRS ist ein leistungsstarkes Architekturmuster zur Trennung von Lese- und Schreibvorgängen und deren Schnittstellen. Es erhöht jedoch auch die Komplexität Ihres Systems. In den meisten Fällen sollten Sie CQRS nicht für das gesamte System verwenden, sondern nur für bestimmte Teile, für die Komplexität und Skalierbarkeit erforderlich sind.
Um mehr über CQRS und Berichtsdatenbanken zu erfahren, empfehle ich, die folgenden Ressourcen zu lesen:
- CQRS - Martin Fowler
- CQRS - MSDN
- CQRS, aufgabenbasierte Benutzeroberfläche, Ereignisquelle erneut! - Greg Young
- CQRS und Event Source - Code am Strand 2014 - Greg Young
- Berichtsdatenbank - Martin Fowler
Herzlichen Glückwunsch zum Abschluss dieser Lektion!
