Antwort.

In einer mikroservicereichen Architektur ist jeder Dienst oft für seine eigene Datenbank verantwortlich. Um die Migrationen von Datenbankschemas zu verwalten, sollten spezialisierte Migrationswerkzeuge (Liquibase, Flyway, Alembic) verwendet werden, und deren Ausführung sollte über CI/CD-Pipelines erfolgen, um Automation und Vorhersehbarkeit der Ergebnisse zu gewährleisten.

Eine gute Praxis besteht darin, dass jede Migration als Migrationsskript mit Versionierung und Idempotenz vorbereitet wird – das erneute Ausführen derselben Änderung führt nicht zu einem Fehler oder einer Inkonsistenz.

Beispiel einer Migration mit Python Alembic:

from alembic import op
import sqlalchemy as sa

def upgrade():
    op.add_column('user', sa.Column('status', sa.String(8)))

def downgrade():
    op.drop_column('user', 'status')

Wesentliche Merkmale:

• Automatisierung der Migrationen auf CI/CD-Ebene
• Idempotenz – die Möglichkeit der wiederholten Anwendung ohne Beeinträchtigung der Struktur
• Versionierung der Datenbankschemas und Rollback

Fangfragen.

Kann das DB-Schema manuell in der Produktion ohne Migrationen (manuelles DDL) geändert werden?

Das wird kategorisch nicht empfohlen: die Kontrolle über den Zustand des Schemas geht verloren und es entstehen Schwierigkeiten beim Rollback/Verfolgen von Änderungen.

Stimmt es, dass Migrationen in einer mikroservicereichen Architektur zentral für alle Dienste ausgeführt werden müssen?

Nein, jedes Team/Dienst ist für sein eigenes Schema und seine eigene Migration-Pipeline verantwortlich. Zentralisierung widerspricht den Prinzipien der Unabhängigkeit der Dienste.

Ist der Rollback von Migrationen völlig sicher?

Nein: Es ist nicht immer möglich, Änderungen zurückzusetzen, insbesondere wenn sich die Struktur oder das Format der Daten geändert hat (z. B. wenn ein Feld gelöscht wurde und Daten verloren gegangen sind). Es ist besser, Migrationen mit Blick auf das Rollback zu entwerfen.