Cevap.

Mikroservis mimarisinde her servis genellikle kendi veritabanından sorumludur. Veri şeması göçlerini yönetmek için, özel göç araçları (Liquibase, Flyway, Alembic) kullanılmalı ve bunlar CI/CD pipepline üzerinden otomasyon ve sonuçların öngörülebilirliği için çalıştırılmalıdır.

İyi bir uygulama, her göçün versiyonlama ve idempotentlik ile birlikte bir göç betiği olarak hazırlanmasıdır; aynı değişikliğin yeniden çalıştırılması hata veya tutarsızlığa yol açmamalıdır.

Python Alembic ile bir göç örneği:

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')

Ana özellikler:

• CI/CD düzeyinde göçlerin otomasyonu
• İdempotentlik — yapının zarar görmeden yeniden uygulanabilirliği
• Veri şeması versiyonlama ve geri alma

Kandırma soruları.

Üretimde veri tabanı şemasını göç olmadan elle değiştirmek mümkün mü (elle DDL)?

Bu kesinlikle önerilmez: şemanın durumu üzerinde kontrol kaybolur ve geri alma/değişiklik takibi zorluğu yaşanır.

Mikroservis mimarisinde, göçlerin tüm servisler için merkezi olarak yapılması gerektiği doğru mu?

Hayır, her ekip/servis kendi şemasından ve kendi göç pipeline'ından sorumludur. Merkeziyetçilik, hizmetlerin bağımsızlık prensiplerine ters düşmektedir.

Göçlerin geri alınması tamamen güvenli midir?

Hayır: değişikliklerin geri alınması her zaman mümkün olmayabilir, özellikle yapısal veya veri biçimi değiştiyse (örneğin, bir alan silinmişse ve veriler kaybolduysa). Geri alma dikkate alınarak göçler tasarlanmalıdır.