Mikroservis Mimarisine Geçişte Veritabanı Paylaşım Sorunları ve Çözüm Yolları

Monolitik yapılardan modern mimarilere geçiş, işletmeler için kritik bir dönüm noktasıdır. Özellikle Kurumsal Yazılım & ERP projelerinde birden fazla departmanı ve süreci aynı çatı altında yönetirken, bu geçişin teknik altyapısı büyük bir dikkat gerektirir. Dağıtık sistemler dünyasına adım atarken karşılaşılan en temel zorlukların başında, veritabanı mimarisi kurgusu ve servislerin veriye erişim modelleri gelir.

Ortak Veritabanı Anti-Patern'i ve Riskleri

Monolitik sistemlerden mikroservis yapısına evrilen ekiplerin düştüğü ilk tuzak, tüm servislerin aynı veritabanını paylaşmaya devam etmesidir. Bu yaklaşım kısa vadede kolaylık sağlasa da uzun vadede dağıtık sistemler prensiplerine tamamen aykırıdır.

• Sıkı Bağlılık (Tight Coupling): Servisler arası bağımlılık azalmaz, aksine veritabanı seviyesinde artar.
• Ölçeklenebilirlik Engeli: Farklı yük altındaki servisler aynı veritabanı kaynakları için yarışır.
• Şema Değişikliği Çatışmaları: Bir servisteki tablo güncellemesi diğer servislerin kodunu kırabilir.

Veri Bütünlüğünü Koruma Stratejileri

Her mikroservisin kendi veritabanına sahip olması (Database-per-Service), veri bütünlüğü yönetimini karmaşıklaştırır. İşlemler tek bir ACID transaction sınırları dışına çıkarak dağıtık yapılara taşınır.

Saga Deseni Uygulaması

Dağıtık sistemlerde yerel transaction'ların birleşimiyle oluşan süreçleri yönetmek için Saga deseni kullanılır. Bu yaklaşım iki farklı yöntemle uygulanabilir:

1. Choreography (Koreografi): Servisler birbirlerinin olaylarını (events) dinleyerek kendi yerel işlemlerini tetikler ve süreci ilerletir.
2. Orchestration (Okestrasyon): Merkezi bir servis (saga orchestrator), tüm adımların sırasını kontrol eder ve olası hatalarda telafi edici (compensating) işlemleri devreye sokar.

CQRS ve Olay Tabanlı Mimari

Karmaşık kurumsal yazılım senaryolarında, okuma ve yazma işlemlerini ayırmak performans açısından şarttır. Komut Sorgu Sorumluluk Ayrımı (CQRS) deseni sayesinde, veri değişimleri asenkron olarak diğer servislerle paylaşılır. Böylece veritabanı mimarisi, farklı iş yüklerinin altından rahatlıkla kalkabilir.

Adım Adım Geçiş Yol Haritası

Geçiş sürecini güvenli tamamlamak için aşağıdaki adımlar izlenmelidir:

• Alan Modellemesi (Domain Modeling): İş süreçlerini doğru bounded context (sınırlandırılmış bağlam) sınırlarına ayırın.
• Veri Ayrıştırma: Ortak veritabanındaki tabloları ilgili mikroservis sorumluluklarına göre parça parça taşıyın.
• Asenkron Senkronizasyon: Servisler arası veri tutarsızlığını gidermek için güvenilir mesaj kuyrukları (message brokers) kullanın.

Hipotetik Senaryo: Sipariş ve Stok Entegrasyonu

Bu teorik senaryoyu ele alırken, e-ticaret tabanlı bir kurumsal mimaride sipariş ve stok servislerinin ayrıştırılmasını inceleyelim. Monolitik yapıda sipariş oluşturulduğunda stok tablosu doğrudan güncelleniyordu. Mikroservis dönüşümünde bu iki alan ayrıldı ve her servisin kendi veritabanı kurgulandı. Kullanıcı bir sipariş verdiğinde, Sipariş Servisi kendi veritabanına yeni kaydı yazar ve bir SiparisOlusturuldu olayı fırlatır. Stok Servisi bu olayı dinleyerek kendi veritabanındaki miktarı düşer. Ancak burada kritik bir ticaret ödünçlemesi (trade-off) ortaya çıkar: Güçlü tutarlılık (strong consistency) yerine nihai tutarlılık (eventual consistency) kabul edilir. Ağ kesintisi veya mesaj kuyruğu hatalarında Stok Servisi yanıt veremezse, sipariş tablosu ile stok tablosu anlık olarak uyuşmaz. Bu hatayı yönetmek için telafi edici işlemler devreye sokulur. Eğer stok yetersiz kalırsa, Saga orkestratörü siparişi iptal etmek üzere telafi komutu gönderir. Hata yönetimi aşamasında dead-letter queue (ölü mektup kuyruğu) mekanizmaları kurularak, işlenemeyen mesajlar loglanır ve sistem yöneticilerine manuel müdahale için fırsat tanınır.

Detaylı Geçiş ve Uygulama Kontrol Listesi

Veritabanı paylaşımından izole mikroservis veritabanlarına geçiş sürecini risksiz yönetebilmek için belirli adımlardan oluşan bir kontrol listesi uygulanmalıdır. İlk aşamada, her servisin sınırlandırılmış bağlamı (bounded context) kesin hatlarla belirlenmeli ve servisler arası doğrudan veritabanı join sorguları tamamen ortadan kaldırılmalıdır. İkinci adımda, ortak tabloların sahipliği tek bir servise devredilirken, diğer servislerin bu verilere salt okunur erişimi için API veya CQRS tabanlı yansıtma katmanları oluşturulmalıdır. Üçüncü aşamada, veri geçişi esnasında kesinti süresini (downtime) minimumda tutmak adına çift yazma (dual-write) veya Change Data Capture (CDC) araçları projeye entegre edilir. Dördüncü aşamada, dağıtık işlemlerin başarısızlık senaryoları uçtan uca simüle edilerek yük testlerine tabi tutulur. Bu süreçte karşılaşılan en büyük başarısızlık, asenkron akışlarda mesajların mükerrer (duplicate) işlenmesidir. Bunu engellemek için idempotent (tekrar eden çağrılarda aynı sonucu üreten) tüketici tasarımları kod tabanına mutlaka dahil edilmelidir. Nihai aşamada ise tüm sistem metrikleri izleme araçlarıyla mercek altına alınarak performans darboğazları giderilir.

Kaynaklar

• Kurumsal Yazılım & ERP — Cy Logic Software