Mikro servisler ve veri depolama

Monolitik bir REST API'sini bir mikro hizmet mimarisine taşımayı düşünüyorum ve veri depolama konusunda biraz kafam karıştı. Gördüğüm gibi, mikro hizmetlerin faydalarından bazıları şunlar olabilir:

• Yatay olarak ölçeklenebilir - Yük ve / veya aşağıya inen bir sunucu ile başa çıkmak için bir mikro hizmetin birden çok yedek kopyasını çalıştırabilirim.
• Gevşek bir şekilde birleştiğinde - Diğerlerini değiştirmek zorunda kalmadan mikro servislerin iç uygulamalarını değiştirebilirim ve bunları bağımsız olarak konuşlandırıp değiştirebilirim ...

Benim sorunum veri depolama ile ilgili. Gördüğüm gibi birkaç seçenek var:

1. Tüm mikro servisler tarafından paylaşılan tek bir Veri Tabanı servisi - bu durum, gevşek kuplajın herhangi bir yararını tamamen ortadan kaldıracak gibi görünmektedir.
2. Her mikro hizmette yerel olarak kurulu bir veritabanı örneği - Bunu yatay ölçeklemenin bir yolunu göremiyorum, bu yüzden bunun bir seçenek olacağını düşünmüyorum.
3. Her mikro hizmetin kendine ait bir veritabanı servisi vardır - bu, en çok ümit verici görünüyor, çünkü gevşek bağlanma ve yatay ölçeklemenin faydalarını koruyor (gereksiz veritabanı kopyalarını kullanarak ve / veya birden fazla yerde paylaşarak)

Bana göre, üçüncü seçenek tek seçenek gibi görünüyor, ancak bana inanılmaz derecede ağır geliyor ve çok ince bir çözüm. Eğer doğru anlıyorsam, o zaman 4-5 mikroservisti olan basit bir uygulama için, 16-20 sunucuyu çalıştırmak zorunda kaldım - mikro servis başına iki gerçek mikro servis örneği (sunucu arızası durumunda ve aksama süresi olmadan devreye alma için) ve mikro hizmet başına iki veritabanı hizmeti örneği (sunucu arızası durumunda vb.).

Açıkçası bu, biraz saçma görünüyor. Gerçekçi bir projenin muhtemelen 4-5'ten fazla hizmete sahip olacağını akılda tutarak, basit bir API çalıştırmak için 16-20 sunucu? Bunu açıklayacağım eksik olan bazı temel kavramlar var mı?

Cevap verirken yardımcı olabilecek bazı şeyler:

• Bu projenin tek geliştiricisiyim ve öngörülebilir gelecek için olacak.
• Node.js ve MongoDB kullanıyorum, ancak dille-agnostik cevaplarla ilgilenirim - bir cevap sadece yanlış teknolojileri kullanıyorum olabilir!

Üç seçeneğinizden ilki (tek, paylaşılan veritabanı) ve üçüncüsü ("veritabanı hizmeti") en yaygın olanıdır.

İlk entegrasyon veritabanı denir . Bu genellikle bir mikro servis mimarisinde iyi bir çözüm olarak görülmemektedir. Hizmetlerinize kuplaj ekler. Ayrıca bir servisin diğer servisleri atlayıp doğrudan veritabanına sorgulamasını çok kolaylaştırır. Veri tabanı düzeyinde uygulanmayan uygulama seviyesinin sağladığı her türlü veri bütünlüğünü veya doğrulamasını kaybedebilirsiniz.

Üçüncü fikrinize uygulama veritabanı denir . Ve haklısınız - API arasındaki gevşek bağlantıyı servisler arasında zorlamanıza olanak tanır ve servisleri veri tabanı seviyesinde daha kolay ölçeklendirmenize izin verir. Ayrıca, her bir hizmetin teknolojisini veya diğer uygulama ayrıntılarını değiştirebildiğiniz gibi, temeldeki veritabanı teknolojisinin her hizmet için uygun bir şeyle değiştirilmesini kolaylaştırır. Çok esnek.

Ancak, bir ara çözüm öneriyorum.

Her mikro servis için bir veritabanı servisini ayağa kaldırmak yerine, her servis için bir şema hazırlayın. Birden fazla veritabanı teknolojisi kullanıyorsanız, biraz farklı şekilde bölmeniz gerekebilir, ancak fikir, çalıştırmakta olduğunuz veritabanı sunucusu sayısını en aza indirgemek olabilir; ancak, bir hizmeti kendi veritabanı sunucusuna ayırmayı çok kolaylaştıracaktır. gerekli olduğunda. Bir veritabanının yalnızca kendi şemasına erişmesine izin verdiğiniz sürece, bir uygulama veritabanının avantajlarına sahip olursunuz, ancak her uygulama veya hizmet için mevcut veritabanı sunucularının ek yükü yoktur.

Bununla birlikte, bir solo geliştirici olarak, bu noktada tüm mikro hizmet anlayışına meydan okuyacağım - Martin Fowler , Monolith First ve Microservice Premium hakkında yazıyor , Simon Brown modüler monolitler hakkında konuşuyor ve DHH Majestic Monolith hakkında konuşuyor. Monolith'inizin ne kadar iyi organize edildiğinden emin değilim, ancak yeniden düzenleyip düzenleyin. Parçaları bir servise kolayca çıkarmak için bileşenleri tanımlayın ve aralarında temiz ayrımlar yapın. Aynı veritabanı yapısı için de geçerli. Hizmetlere yeniden yerleştirmeyi destekleyebilecek iyi, temiz, bileşen tabanlı mimariye odaklanın. Mikro servisler, tek bir geliştiricinin işlemlerde inşa etmesi ve desteklemesi için çok fazla ek yük ekler. Ancak, gerçekte sistemin bir bölümünü ölçeklendirme gereksiniminiz olduğunda, darboğazları tanımlamak, bir hizmete ayıklamak ve gerektiği gibi ölçeklendirmek için izleme ve raporlama sistemlerinizi kullanın.

Her mikro hizmetin kendine ait bir veritabanı servisi vardır - bu, en çok ümit verici görünüyor, çünkü gevşek bağlanma ve yatay ölçeklemenin faydalarını koruyor (gereksiz veritabanı kopyalarını kullanarak ve / veya birden fazla yerde paylaşarak)

Anlaşmak. Üçüncü seçenek mikro hizmetler için doğal bir seçimdir. Mikro hizmetin gerçekten bağımsız olması (ve dağıtılmış bir monolitin parçası değil ) olması durumunda, her birinin bir veritabanına sahip olması normaldir.

[...] mikro hizmet başına iki gerçek mikro hizmet örneği (sunucu arızası durumunda ve kapalı kalma süresi olmadan dağıtma için) ve mikro hizmet başına iki veritabanı hizmeti örneği (sunucu arızası durumunda ...).

Yük dengesi almak istiyorsanız, çalışan mikro hizmetlerin sayısı konusunda haklısınız. 4 mikro servise sahip olmayı planlıyorsanız, zaten açıkladığınız gibi her mikro servisten en az 2 örnek (toplam 8) hazırlamanız gerekir.

Ancak mikro hizmet başına iki veritabanı? Bu gerçekten sorgulanabilir. Mikro hizmetlerinizin katılacağı iş problemiyle ilgili ayrıntıları bilmiyorum, ancak veri tabanı fazlalığına sahip olmak çoğu ürün / proje için oldukça fazla. Tek bir veritabanında iyi bir yedekleme ile başlamanızı ve altyapınızın karmaşıklığını en aza indirmeyi (en azından başlangıçta) önereceğim.

Açıkçası bu, biraz saçma görünüyor. Gerçekçi bir projenin muhtemelen 4-5'ten fazla hizmete sahip olacağını akılda tutarak, basit bir API çalıştırmak için 16-20 sunucu? Bunu açıklayacağım eksik olan bazı temel kavramlar var mı?

Bir İçin Basit API bu numaralar eşleşmiyor. "Microservice First" tuzaklarından birine girmiyorsanız dikkat edin .

Mikro hizmetler, belki de en uç noktalarda bulunan Servis Odaklı Mimari formudur. Genel amaçları, eşleşmeyi azaltmak ve bağımsız gelişme ve konuşlandırmaya izin vermektir.

Mimari açıdan çok kaba konuşursak, mikro servisler, diyelim ki mantıklı bir düzeyde uygulanan bir terimdir. Mikro servisler mantıksal olarak birbirlerinden ayrılır. Bu açıdan bakıldığında, mikro servislerin her birinin kendilerine ait olması ve diğer mikro servislerin depolanmasından ayrılması gereken kendi depolanmasını sağlaması gerekir. Mikro-servisler için, bu depolamanın bağımsızlığı, modülerlik ve gevşek bağlantı hedefleri için anahtardır.

Mimari açıdan bakıldığında, yatay ölçeklendirme daha düşük bir düzeyde uygulanır, uygulamaya daha yakın, fiziksel bir seviyede diyelim. Bu seviyede, bir mikro hizmet uyguluyoruz ve bu tek mikro hizmeti dahili olarak, yatay olarak ölçeklenebilir bir vatansız bileşenine ve tüm vatansız bileşenlerle paylaşılan durum bilgisi olan bir bileşene ayırabiliriz.  Ancak, sadece vatansız kısmı yalnız mikro servisin kendisi ile karıştırmayalım.

Dolayısıyla, bireysel mikro hizmetlerden bahsederken, API'ler ve ayrık sorumluluklar ve ayrılan geliştirme / dağıtım döngüleri hakkında konuşma konusunda mantıklı bir seviyedeyiz. Ve yatay ölçeklendirme hakkında konuşurken, fiziksel düzeyde bir (tek) mikro hizmetin uygulanması ve vatansız ve durumsal bileşenlere ayrışmasından bahsediyoruz.

Birden fazla mikro hizmet uygularken, durum bilgisi olan bileşenler için veritabanı teknolojisini yeniden kullanma seçeneklerimiz vardır:

• mikro hizmet başına ayrı veritabanı
• ile paylaşılan veritabanı:
  • mikro hizmet başına ayrı / özel şema
  • mikro hizmet başına ayrı / özel tablolar

Daha fazlasını burada görün .

Tüm mikro servisler tarafından paylaşılan tek bir Veri Tabanı servisi - bu durum, gevşek kuplajın herhangi bir yararını tamamen ortadan kaldıracak gibi görünmektedir.

Kabul edersiniz, tablo satırlarını ve sütunlarını paylaşmayı kastediyorsanız, bu gerçekten mikro hizmetler olmaz.

Düşünce süreçlerimizde - bir mikro hizmetin durumsuz ve vatansız bileşenleri hakkında daha fiziksel bir kavram olan mikro hizmetlerin mantıksal kavramı ayrılabilirse, paylaşılanın etkinliğini koruyarak, mikro hizmetlerin sunduğu gevşek eşleşmeyi elde etmeyi daha kolay bulabiliriz. veritabanları.

Genellikle microservices ve durum bilgisi sürdürme hakkında yazılı adil bir miktar var, ayrıca bkz burada .

Pekala, bu konudaki tüm yazıları okudum ve şu soruya karıştığımı söyleyebilirim: mikro servis (MS) ile veri erişim servisi (DB servisi) veri tabanları ve sunucuları olan servislerle karıştırır ...

MS, en basit bir görevi vatansız bir şekilde çözen bağımsız (konuşlandırılabilir) bir bileşen ise, NE veritabanına ihtiyacı var? Çözülmesi gereken daha karmaşık bir görev varsa, birden fazla en basit alt görevin (MS?) Birlikte çözülmesini gerektirir, hala bir MS mi? SOA'da Orkestrasyon Hizmeti olarak adlandırılır. "Süreci" uygular ve MS davetini koordine eder, bu yüzden kendi durumunu sürdürmesi gerekir (tüm orkestrasyonlar / organizatörler / besteciler / vb. Durumludur) ve kişisel bir veri deposuna ihtiyaç duyar: başka hiç kimse orkestratörün durumunu tavlayamaz.

Ancak, veritabanı hakkında değil, Veritabanı Erişimi MS / Hizmeti hakkında konuşuyoruz ve bu tamamen farklı bir konu. Bir Üye Devlet, şirkette toplanan bazı verilere ihtiyaç duyabilir (içinde çalıştığı Uygulamada değil) ve veriler için API / arayüzü üzerinden başka bir Üye isteyemez. Bu en yaygın ve gerçekçi senaryodur. Aynı veya farklı bir Uygulamadan başka bir MS bu verilere ihtiyaç duyabilir veya hatta onu değiştirebilir. Evet, MS ortaya çıkmadan önce olduğu gibi veriler için rekabet ederler.

Neden iyi bilinen ve açık olan 'kapıyı' çarpıyoruz? Bir MS ile normal bir kendi kendine ısrar eden nesne arasındaki bu konudaki fark nedir? (Erişim esnekliği ve birleştirilebilir amaçlar için) yine de Veri Erişim Hizmetini (DAS) kullanması gerekiyorsa, neden MS için ayrı bir veri tabanına ihtiyaç duyuyoruz? Unutmayın, DAS, MS'i bir iş görevi ile veritabanına fiziksel bağlantı konusundaki farkındalıktan korur. Bu gevşek bağlanma ve esneklik, MS'in üzerinde veritabanı bağlantısı olmayan çoklu Uygulamalara özgürce katılmak için korumasını sağlamalıdır.