Es gibt einige Probleme beim Crossposting aufgrund des Abschriftendialekts im ursprünglichen Beitrag. Insbesondere werden die Diagramme nicht angezeigt, die im ursprünglichen Beitrag vorhanden sind. Schauen Sie sich also bei Interesse auch das Original an. Ich denke, das Original ist verständlicher

HBase-Upgrade zusätzlich zu Event Sourcing und CQRS-Architektur in 3 Wochen

TL;DR

Wir haben eine Blau-Grün-Bereitstellungsstrategie für das Upgrade der HBase-Version zusätzlich zu Event Sourcing und dem CQRS-Architektursystem verwendet.
Der Bereitstellungsansatz funktionierte recht gut und es dauerte insgesamt nur 3 Wochen, um das Projektziel zu erreichen. Diese Erfahrung war neu und aufregend für uns. Also möchte ich es teilen :)

Informationen zum Datenbank-Upgrade

Ein Datenbank-Upgrade ist immer mühsam und wenn Sie in Produktionsszenarien mit solchen Umständen zu tun haben, werden Sie super nervös (ich würde sagen, 100 Mal im Vergleich zu anderen Produktionsvorgängen, mit denen Sie es zu tun haben) .

Dieses Gefühl ist schwer mit Leuten zu teilen, die nicht die Erfahrung oder Erfahrung im Betrieb der Datenbankumgebungen haben. Und ich denke, 99,9 % der Leute würden zustimmen, wenn Sie die Erfahrung haben und die harten Zeiten im Umgang mit datenbankbezogenen Operationen durchgemacht haben. Es ist riskant und kostet viel, aber ein Upgrade selbst bedeutet nicht, dass es dem Produkt einen neuen Wert verleiht, und obwohl es in vielen Fällen nicht priorisiert wird, es sei denn, es gibt einen dringenden Grund.

Gleichzeitig ist es ein riesiges verstecktes Risiko, wenn die Datenbank "unantastbar" wird, und wie man mit diesem Problem umgeht, war ein Thema, viele Entwickler und Betreiber haben mit solchen Situationen zu kämpfen

Upgrade-Ansatz

Im Allgemeinen haben Sie zwei Möglichkeiten.

laufendes Upgrade

Eines ist ein rollierendes Upgrade. Aktualisieren Sie die Datenbankversion einzeln nacheinander.
Hier habe ich eine gute Erklärung gefunden. Bitte lesen Sie dies, wenn Sie mit dem Wort nicht vertraut sind.

Was versteht man unter einem fortlaufenden Upgrade in der Softwareentwicklung?

Vorteile
- Daten befinden sich an einem Ort. Sie müssen sich also keine Gedanken darüber machen, wie Sie die Daten zwischen verschiedenen Clustern synchronisieren und sicherstellen, dass die Synchronisierung einwandfrei funktioniert.
Nachteile
- Sobald das Upgrade abgeschlossen ist, gibt es keine einfache Möglichkeit, es zurückzusetzen. Wenn also das Upgrade irgendwie Leistungsprobleme auslöst, wären Sie in großen Schwierigkeiten.
- Die lange laufende Datenbank weist einen unerwarteten Zustand auf, den Sie in der Testumgebung nicht reproduzieren können. Manchmal müssen Sie sich mit dem Problem befassen, wenn es um die Produktion geht. Und diese Möglichkeit macht Sie wirklich nervös.

Blau-Grün-Bereitstellung

Die andere ist eine Blau-Grün-Bereitstellung. In diesem Fall müssen Sie den aktualisierten Datenbankcluster separat bereitstellen und die Anwendung irgendwann auf die Verwendung des neuen umstellen.
Bitte überprüfen Sie diesen Blogbeitrag, wenn Sie mit dem Wort „blau-grüne Bereitstellung“ nicht vertraut sind.

BlueGreenDeployment

Ich denke, dass dieser Ansatz bei der Bereitstellung von Webanwendungen weit verbreitet ist, aber wenn Sie das Wort „Router“ durch „Anwendung“ und „Webserver“ durch „Datenbank“ ersetzen, kann der gleiche Ansatz auf das Datenbank-Upgrade angewendet werden.

Vorteile
- Sie berühren die laufende Produktionsdatenbank während des Upgrades nicht. Das macht Ihnen das Leben im Vergleich zum Rolling-Upgrade-Ansatz viel einfacher.
- Sie können einfach zum alten Cluster zurückkehren, wenn ein unerwartetes Problem auftritt. Und Sie können die Anfragen auch nach und nach verteilen, sodass Sie den Umfang minimieren können, falls Sie ein Problem haben (um dies zu tun, müssen Sie jedoch, wie in „Nachteile“, Daten vom neuen Cluster zum alten Cluster synchronisieren)
- Aufgrund des oben genannten Faktors können Sie die Belastungstests auf der Testumgebung etwas verkürzen und können zügig mit dem Projekt fortfahren.
Nachteile
- Sie müssen sicherstellen, dass Daten zwischen beiden Datenbank-Clustern synchronisiert werden. Nicht nur vom alten Cluster zum neuen Cluster, sondern auch vom neuen Cluster zum alten Cluster, wenn Sie nach dem Upgrade eine einfache Möglichkeit zum Zurücksetzen haben möchten. Aber die gegenseitige Datenreplikation ist in vielen Fällen ziemlich schwierig. Es kann möglich sein, bei jedem Vorgang in zwei Cluster zu schreiben, aber Sie müssen sich darauf vorbereiten, wenn nur ein Cluster ausgefallen ist und nur der Vorgang zu diesem Cluster fehlschlägt. Diese Handhabung wäre wirklich kompliziert.
- Sie müssen doppelt so große Server haben, während Sie beide Cluster ausführen. Das kostet etwas Geld und kann schwierig sein, wenn sich Ihr System nicht in einer Cloud-Infrastruktur befindet.

Unser Ansatz

Grundsätzlich ist unser Ansatz ein Blue-Green-Deployment. Und da wir Kafka als Event-Sourcing-Bus vorne haben, war es viel einfacher, das Datensynchronisierungsproblem in den oben aufgeführten „Nachteilen“ zu lösen.

Aktuelle Architektur

Lassen Sie mich zunächst die grundlegende Architektur vorstellen. Übrigens nennen wir das gesamte Chat-Nachrichten-Subsystem "Falcon". Deshalb befindet sich das Falkensymbol im Diagramm.

Wenn ein Endbenutzer eine Chat-Nachricht postet, schreibt die Write-API Nachrichtendaten in Kafka
read-model-updater (kurz "rmu") holt Daten von Kafka, wandelt sie in read-model um und legt sie in HBase ab
Wenn ein Endbenutzer Chat-Nachrichten liest, ruft die Read-API Nachrichtendaten von HBase ab

Ich erkläre in diesem Beitrag nicht, warum wir uns für CQRS entschieden haben. Sehen Sie sich also bitte die folgenden Folien an, wenn Sie es im Detail wissen möchten oder wenn Sie mit dem Konzept von CQRS nicht vertraut sind.
Kafka Summit SF 2017 – Weltweit skalierbare und robuste Messaging-Dienste mit Kafka und Kafka Streams
Weltweit skalierbare und robuste Messaging-Dienste von CQRS und Event Sourcing mit Akka, Kafka Streams und HBase

Ablauf des Datenbank-Upgrades

Jetzt werde ich erklären, wie wir das Datenbank-Upgrade auf dieser Architektur durchgeführt haben

Schritt 1: Bereiten Sie neue Cluster vor und führen Sie eine anfängliche Wiederherstellung aus der Sicherung durch.

Schritt 2: Bereiten Sie einen weiteren Consumer (rmu2 in diesem Diagramm) vor, um Daten von Kafka mit dem neuen Datenbankcluster zu synchronisieren. Sie werden alte Kafka-Ereignisse erneut spielen, beginnend vor der ursprünglichen Wiederherstellung. Stellen Sie sicher, dass Sie Idempotenz bei Ihrem Verbraucher implementieren. Ich meine, das System muss ordnungsgemäß funktionieren, auch wenn dasselbe Ereignis mehr als einmal verwendet wird.

Schritt 3: Wenn der neue Verbraucher (rmu2) die neuesten Kafka-Nachrichten eingeholt hat, bereiten Sie eine weitere Lese-API vor, die Daten aus dem neuen Datenbank-Cluster bezieht. Und senden Sie nach und nach Anfragen an neue Lese-APIs.

Es würde einen gewissen Statusunterschied zwischen dem alten Cluster und dem neuen Cluster geben, selbst wenn die Datensynchronisierung in ein paar Millisekunden abgeschlossen ist. Wir hatten aufgrund dieses Unterschieds ein kleines Problem, daher müssen Sie vorher eine Bewertungsprüfung bestätigen und durchführen, um zu sehen, welche Art von Problem durch den Unterschied zwischen Clustern und Ihrer Anwendungslogik ausgelöst werden kann. Oder wenn Sie einige gute Ebenen vor read-api haben, um die Anfrage nach Benutzerattribut oder so zu verteilen (z. B. Routing über Nginx oder Envoy wie Proxy), können Sie dort einfach die richtige Regel festlegen und der Unterschied kann effizient gehandhabt werden und es wird kein Problem sein.

Und im Rückblick auf dieses Projekt haben wir festgestellt, dass Sie, wenn Sie die Anfragen von vorhandener API auf neue API spiegeln können, die Lasttests mit Produktionsdatenverkehr durchführen können, ohne die Endbenutzer zu beeinträchtigen.

Schritt 4: Wechseln Sie zu 100 % zur neuen Lese-API und fahren Sie alte Cluster und Anwendungen herunter, wenn Sie sicher sind, dass alles einwandfrei funktioniert.

Warum ich diesen Ansatz für besser halte

Lassen Sie mich den Unterschied zum normalen Blau-Grün-Ansatz erklären. Ein Problem bei normalem Blau-Grün ist, dass Sie sicherstellen müssen, dass die Daten auf beiden Clustern synchronisiert werden, idealerweise nicht nur vor dem Upgrade, sondern auch nach dem Upgrade. Anstatt die von der Datenbank bereitgestellte Replikationsfunktion zu verwenden, werden bei diesem Ansatz die Datenbankaktualisierungen separat über die von uns geschriebene und vorbereitete Anwendung angewendet. Dieser Ansatz bringt uns viele Vorteile.

Erstens müssen Sie sich nicht darum kümmern, wie Daten in jeder Phase synchronisiert werden, da sie separat arbeiten. Insbesondere müssen Sie einige zusätzliche (und in den meisten Fällen ziemlich schwierige) Anstrengungen unternehmen, um Daten vom neuen Cluster mit dem alten Cluster zu synchronisieren, wenn Sie nach dem Upgrade eine einfache Möglichkeit zum Zurücksetzen haben möchten. Aber bei diesem Ansatz arbeiten sie nur unabhängig voneinander. Sie können also einfach zu alten zurückkehren, falls nach dem Upgrade ein unerwartetes Problem auftritt.

Zweitens müssen Sie sich nicht um die Versionskompatibilität zwischen alten Clustern und neuen Clustern kümmern. Wenn Sie die von der Datenbank bereitgestellte Synchronisierungsfunktion für Clusterdaten verwenden, treten einige Versionseinschränkungen und Kompatibilitätsprobleme auf, die in einigen Grenzfällen auftreten können. Aber bei diesem Ansatz müssen Sie lediglich eine unabhängige Anwendung vorbereiten, die Daten in jede Datenbank eingibt. Ich denke, es ist das Problem, das Sie in den meisten Fällen viel einfacher lösen können. Und theoretisch können Sie nicht nur die Datenbankversion aktualisieren, sondern Sie können den neuen Cluster mit demselben Ansatz auch auf einen völlig anderen (z. B. DynamoDB) umstellen. In diesem Fall können Sie die Sicherungsdaten nicht für die anfängliche Einrichtung verwenden und müssen ein anfängliches Datenmigrationsprogramm vorbereiten. Das wird einige Zeit dauern, aber ich denke, das ist der vernünftige Punkt, mit dem man sich befassen muss.

Fazit

CQRS- und Event-Sourcing-Themen werden häufig in der Softwarearchitektur diskutiert. Aus betrieblicher Sicht erhöht eine weitere Schicht als Ereignisbus die Komplexität der Infrastruktur und die Betriebskosten. Ehrlich gesagt hat mir diese Herangehensweise aus dieser Sicht vorher nicht so gut gefallen. Aber wir haben festgestellt, dass es auch die Art und Weise verändert, wie wir die Infrastruktur betreiben, und uns die Ruhe im Datenbankbetrieb bringt. Und ja, CQRS und Event Sourcing machen mir jetzt riesigen Spaß :)

Nächste Herausforderung

Sie fragen sich vielleicht, was wir Kafka (Event Sourcing Bus) aufwerten würden? Ja, das wird unsere nächste Herausforderung. Ich hoffe, es gibt einen besseren Ansatz als ein normales fortlaufendes Upgrade und eine Blau-Grün-Bereitstellung. Das Ingenieurleben geht weiter!