• Zuhause
  • Artikel
  • Wie bereiten Sie sich auf das Update Ihrer Serveranwendung vor?
Veröffentlicht am 18-02-2019

Wie bereiten Sie sich auf das Update Ihrer Serveranwendung vor?

Wir arbeiten an einem relativ neuen Projekt, und vor einigen Monaten haben wir in der neuen Version zum ersten Mal einige Änderungen in der Datenbank und in der Konfiguration vorgenommen, die einen Migrationsprozess erforderten. Während wir den Migrationsfortschritt überdenken und gestalten, hatten wir viele Fragen und Entscheidungen musste machen. In diesem Beitrag werde ich versuchen, diese Fragen und Entscheidungen aufzulisten, damit Sie Ihren Migrationsprozess besser vorbereiten und gestalten können.

Beachten Sie, dass sich dieser Fall auf einen Anwendungsserver bezieht, der auf den Client-Servern installiert ist (On-Prem), der Großteil der Punkte ist jedoch auch für Saas-Anwendungen relevant.

Außerdem gibt es keine magischen Lösungen oder Rahmenbedingungen für die Migration. Jede Anwendung hat andere Anforderungen und daher eine andere Lösung. Das Verständnis der Anforderungen ist ein wesentlicher Bestandteil beim Entwurf einer Lösung.

Schritt 1) ​​Ermitteln Sie, was Sie migrieren müssen Ist es Dateien (normalerweise Konfigurationsdateien) oder sind es Datenbanksammlungen und Tabellen oder möglicherweise auch beide. Dies ist ein wichtiger Schritt, da sich dies möglicherweise auf den Zeitpunkt der Migration auswirkt. Beispielsweise sollte die Migration von Konfigurationsdateien wahrscheinlich viel früher als die Datenbankmigration ausgeführt werden und vor dem Start der Anwendung abgeschlossen sein (wenn also die Anwendung nach dem Start der Anwendung gestartet wird) Bei Aktualisierung handelt es sich bereits um die neuen, aktualisierten Dateien. Die Datenbankmigration kann jedoch in einigen Fällen weiter ausgeführt werden, während der Server bereits Benutzeranforderungen verarbeitet.

Schritt 2) Welche Art von Migration müssen Sie ausführen?

  • Fliegende Migration - wenn der Migrationsprozess auch dann fortgesetzt wird, wenn die neue Anwendungsversion gestartet wurde und bereits Benutzeranforderungen verarbeitet werden
  • Faule Migration - wenn Sie nur die aktuell verwendeten Daten migrieren.
  • Migration blockieren - Wenn Sie den Anwendungsstart blockieren, bis alle Daten migriert sind.

Die Entscheidung wird durch die Menge der zu migrierenden Daten in der aktuellen Version und in der Zukunft beeinflusst. Wenn Ihre Anwendung voraussichtlich auf einer großen Datenbank ausgeführt wird, müssen Sie möglicherweise die "On-the-fly-Migration" oder die "Faule" Migration, aber wenn Ihre Anwendung auf einer kleineren Datenbank ausgeführt wird, können Sie die "blockierende Migration" verwenden.

Schritt 3) Laufen Sie in einer Umgebung mit hoher Verfügbarkeit / Cluster? Hier beginnt der Spaß :). Sie müssen hier einige wirklich schwierige Fragen stellen:

  1. Erlauben wir uns bei der Installation neuer Versionen Ausfallzeiten für den gesamten Cluster?
  2. Lassen wir zu, dass die alten Knoten während des Upgrades aktiv sind? Während in der Mitte des Update-Prozesses einige Knoten mit einer neuen Version ausgeführt werden und einige noch in der alten Version vorhanden sind, erlauben wir ihnen, dass sie wie gewohnt funktionieren, oder gehen wir in einen "Upgrade in Progress" -Modus, in dem möglicherweise einige Funktionen deaktiviert sind bis alle Knoten aktualisiert sind (um zu verhindern, dass die Daten, die derzeit vom anderen Aktualisierungsknoten migriert werden, geändert werden)
  3. Erlauben wir eine Situation, in der alte Knoten und neue Knoten lange Zeit zusammenarbeiten?
  4. Wie erfahren die nächsten Knoten, wenn der erste Knoten das Upgrade und die Migration der Datenbanktabellen bereits abgeschlossen hat, ob sie auch den Migrationsprozess ausführen sollen oder welcher Teil der Daten noch zu migrieren ist? (Ein Teil der Daten ist möglicherweise noch im alten Format, da er von einem Knoten mit einer älteren Version hinzugefügt wurde, während der erste Server ein Upgrade durchführte).

Nachdem Sie alle diese Fragen gestellt und einige Antworten gefunden haben (stellen Sie sicher, dass sich einige im Laufe der Zeit und sogar während der Entwicklung des Migrationsrahmens ändern können), hier einige Tipps und mögliche Gefahren, die Sie vermeiden sollten:

  1. Inkrementelle Migration: Jede Anwendungsversion sollte nur die Migration der vorherigen Version implementieren. Sie wird in der angegebenen Reihenfolge ausgeführt und migriert die Daten schrittweise.
  2. Obligatorische Versionen - Einige Versionen können als obligatorische Versionen betrachtet werden. Bei einem Upgrade von einer älteren Version müssen Sie zuerst auf diese Version aktualisieren und dann nur die neuere Version. (Wenn Sie beispielsweise von Version 1.3.0 auf 3.1.0 aktualisieren, müssen Sie zuerst 2.0.0 und erst dann 3.1.0 installieren). Sie sollten versuchen, diese zu vermeiden, da die Aktualisierung schwieriger wird. In einigen Fällen sind sie jedoch unvermeidbar (normalerweise, wenn grundlegende Änderungen am Rahmen vorgenommen werden, z. B. das Ändern des Datenbanktyps usw.).
  3. Verwenden Sie keine POJOs / Entitäten / Dokumente. Verwenden Sie Raw-Objekte: Wenn Sie ein ORM-Framework (z. B. Federdaten / Ruhezustand) verwenden, sind Sie es gewohnt, mit POJO / Dokumenten zu arbeiten, um Daten aus Ihrer Datenbank zu lesen. Wenn Sie jedoch den Migrationsprozess schreiben, sollten Sie sie seit dem nicht verwenden Die Codebasis, auf der die Migration ausgeführt wird, muss nicht unbedingt dasselbe POJO haben (ein Upgrade von 1.5 auf 2.6 wird mit der Codebasis von 2.6 ausgeführt, deren POJO möglicherweise völlig anders ist und die Daten von 1.5 nicht lesen kann). Verwenden Sie daher grundlegende Cursor und rohe Datenbankelemente, um dies zu vermeiden.
  4. Kompatibilität - Wenn Sie das Datenobjekt zwischen den Versionen ändern, versuchen Sie, die Änderung so vorzunehmen, dass der alte Code die neuen Daten noch lesen kann und der neue Code die alten Daten lesen kann. Wenn Sie mehrere Knoten im Cluster haben, wird dies jedoch keiner scheitern, wenn sich die Daten zu ändern beginnen.
  5. Erwägen Sie die Verwendung neuer Sammlungen / Tabellen. Wenn die anderen Knoten während der Migration weiterarbeiten sollen oder ein Fallback oder eine Sicherung erfolgen soll, sollten Sie eine neue Tabelle für die neue Version hinzufügen und die Daten in die neue Tabelle migrieren Version funktioniert mit der neuen Tabelle und die alte Version funktioniert mit der alten Tabelle, bis sie auch das Upgrade durchläuft.
  6. Abwärtskompatibilität beibehalten - Ändern Sie niemals den Typ eines vorhandenen Felds / einer vorhandenen Spalte in der Datenbank. Wenn Sie beispielsweise ein vorhandenes int-Typ-Feld in ein String-Typ-Feld in der neuen Version ändern, verwenden Sie einfach ein neues Feld. (siehe Abschnitt 4).

Wenn Sie all diese Punkte durchgehen, werden Sie hoffentlich ein besseres Verständnis und ein klareres Bild darüber haben, wie Sie Ihren Prozess entwerfen und implementieren.

Im nächsten Beitrag werde ich ein Beispiel auf hoher Ebene für das von uns implementierte System zeigen.

Siehe auch

Das hat Spaß gemacht zu lesen, Lolla. Du hast einen einzigartigen Stil.Money Management für Kinder: Ausgabe 2019AI im Gesundheitswesen mit Peter LeeBester Gaming-Laptop unter 30000 in IndienSamsung Galaxy S10: Vor dem StartExpat Empire Podcast 6 | Mit Matthew Jordan von der Lebensmittelabgabe bis zur Softwareentwicklung in Deutschland