Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Migration der Geschäftslogik von der Datenbank zur Anwendungsebene
Die Migration der Geschäftslogik von in der Datenbank gespeicherten Prozeduren, Triggern und Funktionen zu Diensten auf Anwendungsebene ist ein entscheidender Schritt bei der Zerlegung monolithischer Datenbanken. Diese Transformation verbessert die Autonomie der Dienste, vereinfacht die Wartung und verbessert die Skalierbarkeit. Dieser Abschnitt enthält Anleitungen zur Analyse der Datenbanklogik, zur Planung der Migrationsstrategie und zur anschließenden Implementierung der Transformation unter Wahrung der Geschäftskontinuität. Außerdem wird die Erstellung eines effektiven Rollback-Plans erörtert.
In diesem Abschnitt werden folgende Themen behandelt:
Phase 1: Analyse der Geschäftslogik
Bei der Modernisierung monolithischer Datenbanken müssen Sie zunächst eine umfassende Analyse Ihrer vorhandenen Datenbanklogik durchführen. Diese Phase konzentriert sich auf drei Hauptkategorien:
-
Gespeicherte Prozeduren enthalten häufig kritische Geschäftsvorgänge, darunter Datenmanipulationslogik, Geschäftsregeln, Validierungsprüfungen und Berechnungen. Als Kernkomponenten der Geschäftslogik der Anwendung müssen sie sorgfältig zerlegt werden. Beispielsweise können die gespeicherten Prozeduren einer Finanzorganisation Zinsberechnungen, Kontenabstimmungen und Konformitätsprüfungen übernehmen.
-
Trigger sind wichtige Datenbankkomponenten, die Prüfpfade, Datenvalidierung, Berechnungen und tabellenübergreifende Konsistenz verwalten. Beispielsweise könnte ein Einzelhandelsunternehmen Trigger verwenden, um Inventaraktualisierungen in seinem gesamten Auftragsverarbeitungssystem zu verwalten, was die Komplexität automatisierter Datenbankvorgänge verdeutlicht.
-
Funktionen in Datenbanken verwalten hauptsächlich Datentransformationen, Berechnungen und Suchvorgänge. Sie sind häufig in mehrere Verfahren und Anwendungen eingebettet. Eine Organisation im Gesundheitswesen könnte beispielsweise Funktionen verwenden, um Patientendaten zu normalisieren oder medizinische Codes nachzuschlagen.
Jede Kategorie steht für unterschiedliche Aspekte der Geschäftslogik, die in die Datenbankschicht eingebettet ist. Sie müssen alle sorgfältig evaluieren und planen, um sie auf die Anwendungsebene zu migrieren.
Während dieser Analysephase stehen Kunden in der Regel vor drei großen Herausforderungen. Erstens entstehen komplexe Abhängigkeiten durch verschachtelte Prozeduraufrufe, schemaübergreifende Verweise und implizite Datenabhängigkeiten. Zweitens wird das Transaktionsmanagement von entscheidender Bedeutung, insbesondere wenn es um mehrstufige Transaktionen geht und die Datenkonsistenz über verteilte Systeme hinweg aufrechterhalten wird. Drittens müssen Leistungsaspekte sorgfältig abgewogen werden, insbesondere bei Stapelverarbeitungsvorgängen, Massendatenaktualisierungen und Echtzeitberechnungen, die derzeit von der Nähe zu den Daten profitieren.
Um diesen Herausforderungen effektiv zu begegnen, können Sie AWS Schema Conversion Tool (AWS SCT) für die Erstanalyse und anschließend detaillierte Tools zur Abhängigkeitsabbildung verwenden. Dieser Ansatz hilft Ihnen, den vollen Umfang Ihrer Datenbanklogik zu verstehen und eine umfassende Migrationsstrategie zu entwickeln, die die Geschäftskontinuität während der Zerlegung gewährleistet.
Wenn Sie diese Komponenten und Herausforderungen gründlich verstehen, können Sie Ihre Modernisierung besser planen und fundierte Entscheidungen darüber treffen, welche Elemente Sie bei der Migration zu einer Microservices-basierten Architektur priorisieren sollten.
Erstellen Sie bei der Analyse von Datenbankcodekomponenten eine umfassende Dokumentation für jede gespeicherte Prozedur, jeden Trigger und jede Funktion. Beschreiben Sie zunächst klar ihren Zweck und ihre Kernfunktionen, einschließlich der implementierten Geschäftsregeln. Erläutern Sie alle Eingabe- und Ausgabeparameter und notieren Sie sich ihre Datentypen und gültigen Bereiche. Ordnen Sie Abhängigkeiten von anderen Datenbankobjekten, externen Systemen und nachgelagerten Prozessen zu. Definieren Sie klar die Transaktionsgrenzen und Isolationsanforderungen, um die Datenintegrität aufrechtzuerhalten. Dokumentieren Sie alle Leistungserwartungen, einschließlich der Anforderungen an die Reaktionszeit und der Muster der Ressourcennutzung. Analysieren Sie abschließend die Nutzungsmuster, um Spitzenlasten, Ausführungshäufigkeit und kritische Geschäftsperioden zu verstehen.
Phase 2: Klassifizierung der Geschäftslogik
Eine effektive Datenbankzerlegung erfordert eine systematische Kategorisierung der Datenbanklogik nach Schlüsseldimensionen: Komplexität, geschäftliche Auswirkungen, Abhängigkeiten, Nutzungsmuster und Migrationsschwierigkeiten. Diese Klassifizierung hilft Ihnen dabei, Komponenten mit hohem Risiko zu identifizieren, Testanforderungen zu ermitteln und Migrationsprioritäten festzulegen. Beispielsweise erfordern komplexe gespeicherte Prozeduren mit großen geschäftlichen Auswirkungen und häufiger Nutzung eine sorgfältige Planung und umfangreiche Tests. Einfache, selten verwendete Funktionen mit minimalen Abhängigkeiten könnten sich jedoch für frühe Migrationsphasen eignen.
Dieser strukturierte Ansatz schafft einen ausgewogenen Migrationsplan, der Geschäftsunterbrechungen minimiert und gleichzeitig die Systemstabilität gewährleistet. Wenn Sie diese Zusammenhänge verstehen, können Sie die Reihenfolge Ihrer Zerlegungsmaßnahmen verbessern und Ressourcen angemessen zuweisen.
Phase 3: Migration der Geschäftslogik
Nachdem Sie Ihre Geschäftslogik analysiert und klassifiziert haben, ist es an der Zeit, sie zu migrieren. Bei der Migration von Geschäftslogik aus einer monolithischen Datenbank gibt es zwei Ansätze: Verschieben Sie die Datenbanklogik auf die Anwendungsebene oder verschieben Sie die Geschäftslogik in eine andere Datenbank, die Teil des Microservices ist.
Wenn Sie die Geschäftslogik zur Anwendung migrieren, speichern die Datenbanktabellen nur die Daten, und die Datenbank enthält keine Geschäftslogik. Dies ist der empfohlene Ansatz. Sie können Ispirer
Wenn Sie die Geschäftslogik in eine andere Datenbank migrieren, können Sie AWS Schema Conversion Tool (AWS SCT) verwenden, um vorhandene Datenbankschemas und Codeobjekte in Ihre Zieldatenbank zu konvertieren. Es unterstützt speziell entwickelte AWS Datenbankdienste wie Amazon DynamoDB, AmazonAurora und Amazon Redshift. Durch die Bereitstellung eines umfassenden Bewertungsberichts und automatisierter Konvertierungsfunktionen wird der AWS SCT Übergangsprozess optimiert, sodass Sie sich auf die Optimierung Ihrer neuen Datenbankstruktur konzentrieren können, um Leistung und Skalierbarkeit zu verbessern. AWS SCT Kann im Verlauf Ihres Modernisierungsprojekts schrittweise Konvertierungen durchführen, um einen schrittweisen Ansatz zu unterstützen, sodass Sie jeden Schritt Ihrer Datenbanktransformation validieren und optimieren können.
Rollback-Strategie für Geschäftslogik
Zwei wichtige Aspekte jeder Zerlegungsstrategie sind die Wahrung der Abwärtskompatibilität und die Implementierung umfassender Rollback-Verfahren. Diese Elemente tragen zusammen dazu bei, den Betrieb während der Übergangsphase zu schützen. In diesem Abschnitt wird beschrieben, wie die Kompatibilität während des Zerlegungsprozesses gewährleistet und effektive Rollback-Funktionen für Notfälle eingerichtet werden können, die vor potenziellen Problemen schützen.
Wahrung der Abwärtskompatibilität
Bei der Zerlegung der Datenbank ist die Aufrechterhaltung der Abwärtskompatibilität für reibungslose Übergänge unerlässlich. Behalten Sie die bestehenden Datenbankprozeduren vorübergehend bei und implementieren Sie gleichzeitig schrittweise neue Funktionen. Verwenden Sie die Versionskontrolle, um alle Änderungen nachzuverfolgen und mehrere Datenbankversionen gleichzeitig zu verwalten. Planen Sie einen längeren Koexistenzzeitraum ein, in dem sowohl das Quell- als auch das Zielsystem zuverlässig funktionieren müssen. Auf diese Weise haben Sie Zeit, das neue System zu testen und zu validieren, bevor ältere Komponenten ausgemustert werden. Dieser Ansatz minimiert Betriebsunterbrechungen und bietet ein Sicherheitsnetz für Rollbacks, falls erforderlich.
Rollback-Plan für Notfälle
Eine umfassende Rollback-Strategie ist für eine sichere Datenbankzerlegung unerlässlich. Implementieren Sie Feature-Flags in Ihrem Code, um zu kontrollieren, welche Version der Geschäftslogik aktiv ist. Auf diese Weise können Sie sofort zwischen der neuen und der ursprünglichen Implementierung wechseln, ohne Änderungen an der Bereitstellung vornehmen zu müssen. Dieser Ansatz bietet eine detaillierte Kontrolle über den Übergang und hilft Ihnen, bei Problemen schnell ein Rollback durchzuführen. Behalten Sie die ursprüngliche Logik als verifiziertes Backup bei und führen Sie detaillierte Rollback-Verfahren ein, in denen Auslöser, Zuständigkeiten und Wiederherstellungsschritte festgelegt sind.
Testen Sie diese Rollback-Szenarien regelmäßig unter verschiedenen Bedingungen, um ihre Wirksamkeit zu überprüfen und sicherzustellen, dass die Teams mit den Notfallmaßnahmen vertraut sind. Feature-Flags ermöglichen auch eine schrittweise Einführung, indem neue Funktionen selektiv für bestimmte Benutzergruppen oder Transaktionen aktiviert werden. Dies bietet eine zusätzliche Ebene der Risikominderung während der Umstellung.
