Mikro servisler için veritabanı mimarisini tanımlamak için aşağıdaki noktaları dikkate almamız gerekir.
- Servisler gevşek bir şekilde(Loosely Coupled) birleştirilmelidir. Bağımsız olarak geliştirilebilir, dağıtılabilir ve ölçeklenebilirler.
- Bazı ticari işlemlerin birden çok servise ait verileri sorgulaması gerekir.
- Veritabanlarının ölçeklenebilmesi için bazen çoğaltılması ve paylaşılması gerekir.
- Farklı servislerin farklı veri depolama gereksinimleri vardır.
Database per Service
Yukarıdaki maddeleri çözmek için mikro servis başına bir veritabanı tasarlanmalıdır; yalnızca bu servise özel olmalıdır. Yalnızca mikro servis API’si tarafından erişilmelidir. Doğrudan diğer servisler tarafından erişilemez. Örneğin, ilişkisel veritabanları için, servis başına özel tablolar, servis başına şema veya servis başına veritabanı sunucusu kullanabiliriz.
Shared Database per Service
Mikro servisler için ideal olan servis başına bir veritabanından olması gerektiğinden bahsettik. Shared Database ise Mikro servis için bir anti-patterndir. Ancak uygulama bir monolit ise ve mikro servis yapısına girmeye çalışıyorsa, normalden arındırma o kadar kolay değildir. Daha sonraki aşamada, monolit yapıdan kurtarılmasıyla beraber ayrı database modeline geçilebilir.
Paylaşılan bir veritabanı ideal değildir, ancak yukarıdaki senaryo için çalışan çözüm budur. Çoğu insan bunu mikro servisler için bir anti-pattern olarak görür, ancak brownfield uygulamaları için bu, uygulamayı daha küçük mantıksal parçalara bölmek için iyi bir başlangıçtır. Bu, greenfield uygulamaları için uygulanmamalıdır.
Command Query Responsibility Segregation (CQRS)
Her servis başına ayrı veri tabanını uyguladığımızda, birden fazla servisten ortak veri gerektiren sorgulama gereksinimi oluşabilir.
CQRS, uygulamayı iki bölüme ayırmayı önerir — komut tarafı ve sorgu tarafı.
- Command tarafı Oluşturma, Güncelleme ve Silme isteklerini işler.
- Query tarafı, somutlaştırılmış görünümleri kullanarak sorgu bölümünü işler.
Event Sourcing pattern genellikle herhangi bir veri değişikliği için event oluşturmak için bu pattern ile birlikte kullanılır. Gerçekleştirilen görünümler, event akışına(stream) abone olarak güncellenir.
Event Sourcing
Çoğu uygulama verilerle çalışır ve standart yaklaşım, uygulamanın mevcut durumu korumasıdır. Örneğin, geleneksel oluşturma, okuma, güncelleme ve silme (CRUD) modelinde tipik bir veri işlemi, verileri depodan okumaktır. Sıklıkla işlemleri kullanarak verileri kilitlemenin(Locking) sınırlamalarını içerir.
Event Sourcing pattern, her biri yalnızca ek depoda(append-only store) kaydedilen bir dizi olay(event) tarafından yönlendirilen veriler üzerindeki işlemlerin işlenmesine yönelik bir yaklaşımı tanımlar. Uygulama kodu, verilerde meydana gelen her eylemi zorunlu olarak açıklayan bir dizi olay, kalıcı oldukları olay deposuna gönderir. Her olay, verilerde yapılan bir dizi değişikliği temsil eder (örneğin, AddedItemToOrder).
Olaylar, kayıt sistemi olarak hareket eden bir olay deposunda saklanır. Olay deposu tarafından yayınlanan olayların tipik kullanımları, uygulamadaki eylemler onları değiştirirken varlıkların somutlaşmış görünümlerini korumak ve harici sistemlerle entegrasyon içindir.
Örneğin, bir sistem, kullanıcı arayüzünün bölümlerini doldurmak için kullanılan tüm müşteri siparişlerinin somutlaştırılmış bir görünümünü koruyabilir. Uygulama yeni siparişler ekledikçe, siparişe ürün ekledikçe veya çıkardıkça ve sevkiyat bilgilerini ekledikçe, bu değişiklikleri açıklayan olaylar işlenebilir ve gerçekleştirilmiş görünümü güncellemek için kullanılabilir.
Saga Pattern
Her servisin kendi veri tabanı olduğunda ve bir ticari işlem birden çok servisi kapsadığında, servisler arasında veri tutarlılığını oluşabilir. Her talep, talep başarısız olduğunda yürütülen bir telafi talebine sahip olmalıdır.
İki şekilde uygulanabilir:
- Koreografi (Choreography)— Merkezi koordinasyon olmadığında, her servis başka bir servisin olaylarını üretir ve dinler ve bir eylemin yapılıp yapılmayacağına karar verir. Koreografi, iki veya daha fazla partinin nasıl olduğunu belirlemenin bir yoludur; hiçbiri diğer tarafların süreçleri üzerinde herhangi bir kontrole sahip olmayanlar veya belki de bu süreçlerin herhangi bir görünürlüğü — bilgi ve değeri paylaşmak için faaliyetlerini ve süreçlerini koordine edebilir. Kontrol / görünürlük alanlarında koordinasyon gerektiğinde koreografi yaklaşımını kullanabilirsiniz. Taraflar arasında kabul edilebilir istek ve yanıt modellerini belirler.
- Orchestration— Bir orkestratör (nesne), bir saga nın karar verme ve iş mantığını sıralama sorumluluğunu üstlenir. bir süreçteki tüm aktörler üzerinde kontrole sahip olduğunuzda kullanımı tercih edilebilir. hepsi tek bir kontrol alanında olduğunda ve faaliyetlerin akışını kontrol edebilirsiniz. Bu elbette, çoğunlukla kontrolünüzün olduğu bir organizasyon içinde uygulanacak bir iş sürecini dahil olabileceğiniz zamandır.
