Mikro hizmette, her hizmet için tek veritabanı mı yoksa tek veritabanı örneği mi?

Bir mikro hizmet mimarisindeki her bir hizmetin kendi veritabanına sahip olması gerektiğini biliyorum. Ancak, kendi veritabanına sahip olmak, aslında sadece aynı veritabanı örneğinde başka bir veritabanına sahip olmak veya tam anlamıyla başka bir veritabanı örneğine sahip olmak anlamına mı geliyor?

Bununla, hayır amaçlı bir veritabanı değil, veritabanını paylaşmayı kastetmiyorum.

Örneğin, AWS kullanıyor olsaydım ve 3 servisim varsa, her bir servis için tek bir RDS örneğinde 3 veritabanı oluşturuyor muyum yoksa her biri 3 servisin her biri tarafından bağımsız olarak kullanılan bir veritabanı içeren 3 RDS örneği yaratıyor muyum?

Tek bir RDS örneğinde birden fazla veritabanı kullanmak daha iyi bir fikir ise, bağımsız hizmetler sağlama amacını yitirir, çünkü:

1. RDS örneğinin kaynağı hizmetler arasında paylaşılacaktır. Belirli bir zamanda yoğun veritabanı kullanımı olan Servis A, farklı bir veritabanı kullanan ancak aynı RDS örneğinde Hizmet B'yi etkiler mi?

2. Tüm hizmetler, bu RDS örneğindeki veritabanı sürümüne bağlı olacaktır.

Bu, gerçekten ölçeklenebilirlik gereksinimlerinize ve mikro hizmet örneklerinin tek bir sonuç elde etmek için nasıl işbirliği yapmaları gerektiğine bağlıdır. Takasların ne olduğunu bilmek yardımcı olur:

Hepsini bir veritabanında tutmak

• Daha kolay yapılandırma
• Hizmetinizin diğer örnekleri ile koordinasyon veya iletişim gerekmez
• Veri setinizi tam olarak keşfetmek daha kolay
• Sistem performansı veritabanı performansıyla sınırlıdır

Veritabanlarını ayrı tutmak

• Bir isteğin tam cevabı, mikro hizmet örnekleri arasında yayılabilir.
• Bu durumda, talebi çözmek için iletişimi ve pazarlığı arttırdınız.
• Bu mikro hizmet düğümünü gevşettiğinizde verileri kullanma (veritabanı hala açıkken bile, doğru yapılandırmaya sahip yeni bir tane geri alınana kadar elde edemezsiniz)
• Artırılmış yapılandırma karmaşıklığı

Çözmekte olduğunuz problem nedir?

Bazı durumlarda, yalnızca geçici veriler için endişeleniyorsunuz. Veri tabanı düşerse, önemli bir sorun değil. Bu gibi durumlarda, başlamak için bir veritabanına bile ihtiyacınız olmayabilir. Sadece hepsini bellekte tut ve cayır cayır yanan hızlı şeyler yap. Bu çalışmak için en kolay çözümdür.

Diğer durumlarda, veri bütünlüğüne ihtiyacınız vardır, ancak veritabanınız sahip olduğu düğüm sayısına göre kapasitesini artırabilir. Bu durumda, tek bir veritabanı muhtemelen fazlasıyla yeterlidir ve duyarlılığını bağımsız olarak yönetmek doğru cevaptır.

Arada birkaç dava var. Örneğin, bölgesel olarak özel veritabanları olabilir, bu nedenle farklı bir bölgedeki hizmetinizin her bir örneği için ayrı bir veritabanınız vardır. Genellikle, paylaşılan veritabanları bölgeler arasında iyi sonuç vermez, bu nedenle verileri biraz yerelleştirmek ve koordinasyonu kendiniz kontrol etmek için bir yoldur.

Doktrin ve Gerçeklik

Mikro hizmetler ve ne kadar modüler olmaları gerektiği hakkında birkaç makale okudum. Öneriler, tüm durumlar için ön uç, mikro servis ve veri seviyesinin bir bütün olarak tutulması ile veri tabanı ve / veya ön uç kodunun paylaşılmasına kadar uzanmaktadır. Genellikle, daha fazla yalıtım, en yüksek ölçeklenebilirliği sağlar, ancak artan karmaşıklık pahasına gelir.

Mikro hizmetiniz hesaplama ağırsa, bu mikro hizmetlerin sayısının gerektiği gibi ölçeklendirilmesine izin vermek mantıklıdır; veritabanını veya hatta ön uç kodunu paylaşmak bu yaklaşıma zarar vermez veya engellemez.

Gerçek şu ki, projenizin özel gereksinimlerinin zamanında yapılması gereken işleri yapmak ve ölçtüğünüz sistem yükünü ele almak için farklı bir uzlaşmaya ihtiyaç duyacağıdır (ve biraz daha fazlası). Tamamen izole edilmiş ön uç, mikro hizmet ve veri katmanı üçlüsünün yüce amaç olduğunu düşünün. Sisteminize ne kadar çok talep olursa, o hedefe o kadar yakın olmanız gerekir. Hepimiz değiliz [insert name of highly successful web entity here]ve şimdi oldukları yerde başlamadılar. Bazen mükemmel durumdan daha azıyla başlamalısın ve bundan mutlu olmalısın.

Farklı veritabanı veya db örnekleri kullanıyorsanız, tasarım zamanında vermeniz gerekmeyen bir kararsa, aynı tür DB sistemi ve sürümünü kullanabilen bazı servislerinizin olduğunu varsayıyoruz. Bunun yerine, dağıtım zamanında karar verebilmeniz gerekir, bu da kolayca yapılandırabilirsiniz. Hizmetlerinizi, diğer hizmetlerin veritabanlarının barındırıldığı yerin agnostiği olacak şekilde tasarlayın.

Çalışma sırasında bir örnekle başlayabilirsiniz ve sistem iyi çalışıyorsa, bu şekilde bırakın. Bununla birlikte, bunun sisteminiz için iyi bir şekilde ölçeklendirilmediğini fark ederseniz, bir örnekte farklı veritabanları çok fazla kaynak paylaştığından, her zaman farklı örnekler kullanma seçeneğiniz vardır, eğer yardımcı olursa.

Dolayısıyla, bir hizmet, yalnızca ikisinin bazı kaynakları paylaşmasına izin verdiğiniz için, mikro hizmet mimarisini ihlal etmez - bu, kaynak paylaşımı zorunlu hale geldiğinde onu ihlal eder.

Önemli değil.

Teorik olarak önemli olabileceği tek senaryo, bir hizmetin veritabanının farklı bir sürümüne geçmesi gerekip gerekmediğidir. Ancak o zaman bile, başlangıçtan ayrı örneklere sahip olmakla, o hizmeti paylaşılan bir örnekten ayrı bir yere geçirmek arasında gerçek bir fark yoktur. Aslında, sadece bu senaryo nedeniyle ayrı örneklere sahip olmanın YAGNI örneği olduğunu söyleyebilirim.

Bir RDS örneği tek bir kutudur. Tek bir örnekte birden fazla veritabanınız varsa, CPU / Belleği vb. Paylaşırlar.

Mikro hizmet performansınız veritabanı performansına bağlıysa : her biri farklı bir veritabanı kullanarak, ancak her biri aynı RDS örneğinde bulunan mikro hizmetin birden çok kopyasını dağıtma. Anlamsız * (yerine çalışma hariç). Mikro hizmet kümeniz, tek bir mikro hizmet ile aynı hızda çalışır

Ancak , veritabanı performansına bağlı bir mikro hizmetin olağandışı olduğunu söyleyebilirim.

Genellikle mikro servisiniz bir db'den veri alır, bir mantık gerçekleştirir ve bazı bilgileri tekrar veritabanına yazar. Performans darboğazı, seçme ve / veya ekleme değil mantıktır .

Bu durumda, aynı veritabanını tüm mikro servis örnekleriniz arasında paylaşabilirsiniz.

Veritabanını bir hizmete özel tutma hedefi, kapsüllemedir. Mikro hizmetiniz, sistemdeki diğer hizmetlerin ortak arabirim aracılığıyla kullanacağı bir kara kutudur.

Bu kapsüllemenin üzerinde çalıştığı iki uçak var:

• İlki, uygulama düzeyinde mantıklı. Hizmetiniz sisteminizde bazı işletme nesnelerine sahip ve bu nesneler hakkında durumlarını devam ettirmesi gerekiyor. Bazı özel veritabanlarının bu işletme nesnelerini desteklemesi sadece uygulama detayıdır. Ayrı bir veritabanını tutarak, diğer hizmetlerin uygulamanıza arka kapıdan erişmesini önler ve bunun yerine ortak arabiriminizi kullanmaya zorlarsınız. Buradaki amaç temiz mimari ve disiplinli programlama. Veritabanının tam olarak yaşadığı yer bu düzeyde önemsizdir, hizmetiniz onu bulabilmesi için doğru bağlantı ayrıntılarına sahip olduğu sürece.

• İkinci seviye operasyonel. Tasarımınız mükemmel bir kara kutu olsa da, belirttiğiniz gibi, tek bir makinede toplanan farklı işler kaynaklar için rekabet edebilir. Bu, ayrı makinelere ayrı mantıksal veritabanları koymak için iyi bir nedendir. Diğer cevapların belirttiği gibi, ihtiyaçlarınız çok talepkar değilse ve bütçeniz kısıtlıysa, bu tek bir makinede bir araya gelmenin pragmatik bir argümanıdır. Bununla birlikte, her zaman olduğu gibi, değişimler: bu kurulum sisteminiz büyüdükçe daha fazla bebek bakıcılığı gerektirebilir. Bütçenin izin vermesi durumunda, iki görevi yürütmek yerine daha büyük bir makineyi paylaşmaya karşı neredeyse her zaman iki ayrı küçük makineyi tercih ederim.

Bence burada biraz daha teorik olmak yardımcı olabilir. Mikro hizmetlerin arkasındaki motive edici fikirlerden biri, hiçbir şey paylaşılmaz, mesaj gönderme süreçleridir. Bir mikro hizmet, Aktör modelinde bir oyuncu gibidir. Bu, her bir sürecin kendi yerel durumunu koruduğu anlamına gelir ve bir işlemin diğerinin durumuna erişmesinin tek yolu ileti göndermektir (ve o zaman bile diğer işlem bu iletilere benzer şekilde yanıt verebilir). "Her mikro servisin kendi veri tabanı vardır" ile kastedilen, aslında bir sürecin (yani mikro hizmet) yerel ve özel olmasıdır . Büyük ölçüde, bu "veritabanı" nın ortaklaşa bırakılması gerektiğini göstermektedir.mikro servis ile, yani "veri tabanı" saklanmalı ve mikro servis ile aynı mantıksal düğümde çalıştırılmalıdır. Mikro hizmetin farklı "örnekleri" ayrı işlemlerdir ve bu nedenle her birinin kendi "veritabanı" olması gerekir.

Küresel bir veritabanı veya mikro hizmetler veya hatta bir mikro hizmet örnekleri arasında paylaşılan bir veritabanı, bu açıdan, paylaşılan durum oluşturacaktır. Bunu mikro servisler perspektifinden ele almanın "uygun" yolu, paylaşılan veri tabanına bir "veri tabanı" mikro hizmetinin aracılık etmesidir. Veritabanının içeriğini bilmek isteyen diğer mikro servisler bu "veri tabanı mikro servisine" mesajlar gönderir. Bu, tipik olarak, orijinal mikro hizmetler için yerel duruma (yani mikro hizmet için örnek "veritabanlarına" göre) olan ihtiyacı ortadan kaldırmayacaktır! Değişen şey, yerel devletin temsil ettiği şeydir. "Kullanıcı Sally bir yöneticidir" saklamak yerine, "Veritabanı mikro hizmeti" Kullanıcı Sally bir yöneticidir "dedi, beş dakika önce. Başka bir deyişle, diğer mikro servislerin durumu hakkında.

Bunun faydası, her mikro hizmetin kendi kendine yetmesidir. Bu, bir mikro hizmetin atomik bir başarısızlık birimi olmasını sağlar. Siz (çoğunlukla), kısmen işlevsel bir durumda olan bir mikro hizmet için endişelenmenize gerek yoktur. Tabii ki, sorun mikro-servis ağına taşınmıştır. Bir mikro hizmet, diğer mikro hizmetlerle temas kuramadığı için istenen işlevi yerine getirmekte başarısız olabilir. Bununla birlikte, bunun yararı, mikro hizmetin iyi tanımlanmış bir durumda olacağı ve örneğin eski tarihli inançları çözerek düşük veya sınırlı hizmet sunabileceğidir. Olumsuz tarafı, bir bütün olarak sistemin tutarlı bir anlık görüntüsünü elde etmenin çok zor olmasıdır ve oldukça fazla (istenmeyen) fazlalık ve çoğaltma olabilir.

Tabii ki, öneri bir Oracle örneğini her Docker konteynerine yapıştırmak değildir. İlk olarak, her mikro hizmetin bir "veritabanı" na ihtiyacı yoktur. Bazı işlemlerin düzgün çalışması için kalıcı bir duruma gerek yoktur. Örneğin, iki protokol arasında çeviri yapan bir mikro servis mutlaka kalıcı bir duruma ihtiyaç duymaz. Kalıcı duruma ihtiyaç duyulduğunda, "veritabanı" kelimesi "kalıcı durum" için sadece bir kelimedir. İçinde JSON ile bir dosya veya bir SQLite veritabanı veya Oracle yerel olarak çalışan kopyasını isterseniz veya dışındaki herhangi bir yöntemle olabilir lokalsürekli veri depolamak. Eğer “veritabanı” yerel değilse, saf bir mikro hizmet bakış açısından ayrı (mikro) bir hizmet gibi ele alınmalıdır. Bu amaçla, bir RDS örneğinin bir mikro hizmet için "veritabanı" olması hiçbir zaman anlamlı değildir. Yine, bakış açısı “kendi RDS veritabanlarına sahip bir grup mikro hizmet” değil, “ RDS veritabanlarıyla iletişim kuran bir grup mikro hizmet ”. Bu noktada, verilerin aynı veritabanı örneğinde depolanıp saklanmadığı önemli değildir.

Pragmatik olarak, bir mikro hizmet mimarisi büyük miktarda karmaşıklık ekler . Bu karmaşıklık, kısmi başarısızlıkla ciddi bir şekilde uğraşmanın bedeli. Birçokları için, faydaya değmeyecek kadar büyük bir ihtimal. Sisteminizi, en faydalı görünen yöntemle oluşturmakta özgürsünüz. Basitlik ve verimlilikle ilgili endişelerin saf bir mikro hizmet mimarisinden sapmalara yol açması olasılığı yüksektir. Maliyet, hizmetler arasında görünmeyen etkileşimler ve istediğiniz gibi konuşlandırma ve ölçeklendirme özgürlüğünüzdeki kısıtlamalar gibi kendi karmaşıklıklarını ortaya çıkaran ekstra birleşme olacaktır.