Her biri kendine özgü verileri olan birden fazla hizmeti içeren bir web platformu inşa ediyoruz. Bu servisler Servis Odaklı Mimari ilkelerini takip ederek bağımsız olarak inşa edilir , ancak potansiyel olarak ilişkili verilere karşı işlem yaparlar. Bu hizmetlerin büyük bir veritabanını paylaşması gerekip gerekmediğini veya her birinin kendi veritabanına sahip olup olmadığını düşünüyoruz. (SQL Server 2008 Enterprise'ı bir Windows 2008 kümesinde kullanmayı planlıyoruz.)

Zaten dikkate aldığımız her yaklaşımın avantajlarından bazıları şunlardır:

Tek veritabanı

• Farklı servislerden gelen verilerin ilişkilendirilmesi yabancı anahtar kısıtlamaları ile birbirine bağlanabilir
• Analitik ekstrelerin yazılması daha kolay ve yürütülmesi daha hızlıdır
• Bir felaket durumunda, platformu tutarlı bir duruma geri yüklemek daha kolaydır
• Birden fazla servis tarafından referans alınan veriler için, bir servis tarafından önbelleğe alınan verilerin kısa süre sonra başka bir servis tarafından kullanılması muhtemeldir.
• Yönetim ve izleme daha basit ve daha ucuzdur

Birden çok veritabanı

• Bakım çalışmaları, donanım sorunları, güvenlik ihlalleri vb. Tüm platformu etkilemeyebilir.
• Her veritabanının ayrı bir donanımda olduğunu varsayarsak, birden fazla makineyi ölçeklendirmek, büyük bir tane ölçeklendirmekten daha fazla performans avantajı sağlar

Operasyonel açıdan bakıldığında, bu platformdaki her hizmetin kendi veritabanına sahip olması veya hepsinin aynı veritabanında olması daha avantajlı mı? Bu sorunun cevabını hangi kilit faktörler bildirir?

Kanımca, gerçek SOA sistemlerinin (sözde SOA üzerinden, her yerde bulunan / dağıtılmış sistemler üzerinden) temel farklılaştırıcısı, ayrık hizmetler arasında sıfır etkileşimin olması gerektiğidir. Bunun başarıldığı durumlarda, bu hizmetlerden oluşturduğunuz herhangi bir uygulama, herhangi bir tutarlı parçanın arızasını tolere etmek için inşa edilebilir ve yapılmalıdır. Bir arıza işlevselliği azaltır, ancak servis sağlanır.

Bu senaryoda, her hizmet için temel veritabanını ayırmak mantıklı veya zorunludur. Bununla birlikte, birbirine bağımlı olan hizmetleriniz varsa, bölünmeden elde edilecek çok az (belki de hiçbir şey) yoktur.

Asla başarısız olmayan web siteleri tarafından benimsenen mimarileri inceleyen HighScalability.com gibi sitelerin okunmasını tavsiye ederim . Son zamanlardaki favorilerimden biri de Kodlama Korkusu'nda adı geçen Netflix Kaos Maymunun hikayesiydi .

Sorunuzdaki birkaç noktayı ele alarak:

Bir felaket durumunda, platformu tutarlı bir duruma geri yüklemek daha kolaydır.

Bu doğrudur, ancak belki de bu hizmetleri nasıl daha iyi bir şekilde birleştireceğinizi düşünmelisiniz, bu yüzden bu sorun olmayacaktır. Alternatif olarak, örneğin birden fazla veritabanı arasında senkronizasyon sağlama yöntemleri, örneğin SQL Server'daki işlem işaretleri vardır .

Birden fazla servis tarafından referans alınan veriler için, bir servis tarafından önbelleğe alınan verilerin kısa süre sonra başka bir servis tarafından kullanılması muhtemeldir.

Dağıtılmış önbellek çözümleri (memcached et al) burada yardımcı olabilir, ancak hizmet bağımsızlığı ilkelerini ihlal ediyor olursunuz. Bu, birbiriyle doğrudan iletişim kuran iki hizmete sahip olmakla ya da hizmet arayüzünü tamamen geçerek bir hizmet erişimine sahip olan annelerin veri deposuna sahip olmakla karşılaştırılabilir. Kaçınılmaz olarak veriler çağrılacak platform tarafından hizmetler arasında ilişkilendirilecek ve verilecek, zor kararlar hangi hizmetin hangi veri parçalarına sahip olacağı konusunda eğilimindedir. StackOverflow veya Programmers siteleri, daha genel SOA sorunlarına yardımcı olmak için daha iyi yerleştirilebilir.

Her bir veritabanının ayrı bir donanımda olduğu varsayılırsa, ölçeklendirme daha fazla performans avantajı sağlar.

Kesinlikle birden fazla düşük özellikli makinede ölçeklendirmek, tek bir makineyi ölçeklendirmekten daha ucuz olabilir. Bununla birlikte, ek geliştirme çabasının ve operasyonel karmaşıklığın yumuşak maliyetleri hesaba katıldığında, düşük donanım maliyetleri toplam sahip olma maliyetinde dwarf edilebilir.

Eğer bu SOA değilse ve bu platformun bileşen hizmetlerinin farklı sebepler / tedarikçiler tarafından lojistik nedenlerden dolayı üretildiği bir durum varsa, tek bir veritabanına bağlı kalın ve yukarıdaki her şeyi tamamen görmezden gelin! :)