Bir mikro hizmet mimarisi, mikro hizmet başına ayrı bir veritabanına ihtiyaç duyuyorsa, çok maliyetli ve yönetilemez. Neden ihtiyacımız var?

Mikro hizmetler hakkında okudum ve sadece izolasyon elde etmek için hizmet başına ayrı bir DB oluşturmak benim için mantıksız görünüyor. Ben sadece web hizmetleri ve tek bir veritabanı kullanarak aynı elde edebilirsiniz. Neden ihtiyacımız var? Ayrı bir veritabanı tartışmanın ötesinde bir şey. Yoksa ben yanlış mıyım? Bana bu konuda rehberlik edebilir misin?

Neden ihtiyacımız var?

Yapmazsın.

Her hizmet için ayrı bir veritabanı oluşturmak, etki alanı sınırlarının uygulanmasına yardımcı olur, ancak bu yalnızca bir yaklaşımdır. Tüm hizmetlerinizin aynı veritabanını paylaşmasını engelleyen hiçbir şey yok.

Hizmetleriniz diğer hizmetlerin sahip olduğu verilere beklenmedik şeyler yapmadığı ve beklemediğiniz sürece, iyi olacaksınız.

Ne okuduğunuzu bilmiyorum, ancak mikro hizmet mimarisi hakkında birçok farklı görüşün olduğunun farkında olmalısınız. İşte konuyla ilgili güzel bir blog yazısı.

İnsanların bu fikre kısmen önemsiz bir şekilde atıfta bulunduğunu gördüm. Fikir sağlam: hizmetler arasında tek bir veritabanını paylaşmayın, çünkü o zaman rakip okuma / yazma kalıpları, veri modeli çakışmaları, koordinasyon zorlukları vb.

Ancak tek bir veritabanı bize çok fazla güvenlik ve kolaylık sağlar: ASİT işlemleri, bakmak için tek yer, iyi anlaşılmış (tür?), Yönetilecek tek yer, vb.

Mikro hizmetlere yolculuk sadece budur: bir yolculuk . Her şirket için farklı olacaktır. Zor ve hızlı kurallar yoktur, sadece ödünleşimler vardır.

Mikro Hizmetler Hakkında En Zor Bölüm: Verileriniz

Dan Wilson'ın yanıtladığı gibi, gerçekten buna ihtiyacınız yok. Mikro hizmetler yeni sıcak şeydir ve tüm yeni sıcak şeyler gibi, insanlar çok fazla değer sağlamadıklarında bile onları birçok yerde kullanırlar.

Mikro hizmetler, işleri "mikro" düzeyde bağımsız olarak dağıtmanıza ve ölçeklendirmenize olanak tanır. Bu ayrıntı düzeyi, geliştirme ekiplerini daha iyi ayırmanıza, büyük bir sürümden ziyade gerektiği gibi salıvermenize, yeni teknolojileri veya süreçleri tek başına denemenize vb. DB bağımlılığı nedeniyle bu çok. Hizmetinizi diğer hizmetlerin verileri hakkında endişelenmeden dağıtamazsanız, kaybettiniz.

Ayrı bir veritabanı tartışmanın ötesinde bir şey. Yoksa ben yanlış mıyım?

Dedi ki, sen de yanılıyorsun.

Bulutta çalışırken, veritabanları ucuzdur. Genellikle ücretsiz! Tabii, sunucunun maliyeti var, ancak mikro hizmet başına ayrı bir sunucudan bahsetmiyoruz (en azından ilk başta değil). Bir grup (mantıksal) veritabanına sahip tek bir sunucu, çapraz veritabanı sorgularından ("bağımsız olarak konuşlandırılabilir ve ölçeklenebilir" zarar veren bağımlılıklar getiren) kaçınmaya çalıştığınız sürece iyidir. Azure SQL gibi bazı bulut veritabanı hizmetlerinde, çapraz DB sorguları mümkün değildir. Orada gayretli olmanıza bile gerek yok ...

Ve hatta bir veritabanını paylaştıkları mikro hizmetler gördüm, ancak her hizmetin kendi şeması var. Yine, veri sınırlarını aşan sorgulardan kaçınmaya özen göstermelisiniz.

Birçok yer o kadar çalışkan değil. Giriş seviyesi geliştiricileri veya mikro hizmet yaklaşımına değer vermeyen veya kötü takım liderleri olan veya insanların kısayol almasına neden olan zaman çizelgesi baskısı olan kişiler var.

Ayrı bir veritabanına sahip olmak, hizmet bağımsızlığına izin veren ayırmayı zorlamanın en temiz yoludur, ancak tek yol bu değildir. Ve bu o kadar da pahalı değil - özellikle paylaşılan bir veritabanında veri sınırlarını zorlamak için harcanan zaman / maaş ile karşılaştırdığınızda.

Neden ihtiyacımız var?

Mikro hizmetlerin muazzam yararı - ve daha çok, SOA - içsellerin soyutlama seviyesidir - sadece uygulama değil, aynı zamanda kullanılan teknolojilerdir. Örneğin, bir sistem beş ekip tarafından beş mikro hizmet şeklinde geliştirilirse, bir ekip diğer ekiplerden fikirlerini bile sormadan tamamen farklı bir teknolojik yıla (örneğin Microsoft yığınından LAMP'a) geçmeye karar verebilir.

Amazon AWS veya Twilio'ya bakın. Hizmetlerinin Java veya Ruby'de uygulanıp uygulanmadığını biliyor musunuz? Oracle veya PostgreSQL veya Cassandra veya MongoDB kullanıyorlar mı? Kaç makine kullanıyorlar? Bunu önemsiyor musun bile; diğer bir deyişle, bu teknolojik tercihler bu hizmetleri kullanma şeklinizi etkiliyor mu? Ve daha da önemlisi, farklı bir veritabanına geçmeleri halinde, istemci uygulamanızı buna göre değiştirmeniz gerekir mi?

Şimdi, iki hizmet aynı veritabanını kullanırsa ne olur? Ortaya çıkabilecek sorunların küçük bir kısmı:

• Takım geliştirme hizmeti 1, SQL Server 2012'den SQL Server 2016'ya geçmek istiyor. Ancak, takım 2, SQL Server 2016'da kaldırılan kullanımdan kaldırılmış bir özelliğe dayanıyor.

• Hizmet 1 büyük bir başarı. Veritabanını iki makinede (ana ve yük devretme) barındırmak artık bir seçenek değil. Ancak kümeyi birden çok makineye ölçeklemek, parçalama gibi stratejiler gerektirir. Bu arada, takım 2 mevcut skaladan memnun ve başka bir şeye geçmek için hiçbir neden görmüyor.

• Hizmet 1, varsayılan kodlaması olarak UTF-8'e taşınmalıdır. Ancak Service 2, Windows Latin 1 Kodunu kullanmaktan mutluluk duyar.

• Hizmet 1, belirli bir ada sahip bir kullanıcı eklemeye karar verir. Ancak, bu kullanıcı birkaç ay önce ikinci ekip tarafından oluşturulmuş durumda.

• Hizmet 1, birçok farklı özelliğe ihtiyaç duyar. Hizmet 2 son derece kritik bir bileşendir ve saldırı riskini azaltmak için veritabanı özelliklerini minimumda tutmalıdır.

• Hizmet 1 için 15 TB disk alanı gerekir; hız önemli değil, bu yüzden sıradan sabit diskler gayet iyi. Hizmet 2 en fazla 50 GB gerektirir, ancak mümkün olduğunca hızlı bir şekilde erişmesi gerekir, yani veriler bir SSD'de depolanmalıdır.

• ...

Her küçük seçim herkesi etkiler. Her kararın, her takımdan insanlar tarafından işbirliği içinde alınması gerekir. Ödün verilmelidir. Bunu, SOA bağlamında istediğiniz her şeyi yapma özgürlüğü ile karşılaştırın.

çok [...] yönetilemez.

O zaman yanlış yapıyorsun. Sanırım elle konuşlandırıyorsunuz .

İşlerin böyle yapılması gerekmiyor. Veritabanını çalıştıran sanal makinelerin (veya Docker kapsayıcılarının) dağıtımını otomatikleştirmeniz gerekir. Bunları otomatikleştirdikten sonra, iki sunucu veya yirmi sunucu veya iki bin sunucu dağıtmak çok farklı değildir.

Yalıtılmış veritabanlarıyla ilgili sihirli şey, son derece yönetilebilir olmasıdır . Düzinelerce ekip tarafından kullanılan devasa bir veritabanını yönetmeyi denediniz mi? Bu bir kabus. Her takımın belirli istekleri vardır ve bir şeye dokunduğunuzda birisini etkiler. Bir uygulama ile eşleştirilmiş bir veritabanı ile kapsam çok dar hale gelir, yani düşünülecek çok daha az şey vardır.

Büyük bir veritabanı özel sistem yöneticileri gerektiriyorsa , yalnızca bir ekip tarafından kullanılan veritabanları bu ekip tarafından yönetilebilir (DevOps da bu konuda) ve sistem yöneticilerinin zamanını serbest bırakır.

çok pahalı

Maliyeti tanımlayın.

Lisanslama maliyetleri veritabanına bağlıdır. Bulut bilişim döneminde, tüm büyük oyuncuların lisanslarını, büyük bir veritabanı yerine çok sayıda küçük veritabanının bulunduğu içeriğe uyacak şekilde yeniden tasarladıklarından eminim. Değilse, farklı bir veritabanına geçmeyi düşünebilirsiniz. Bu arada birçok açık kaynak var.

İşlem gücü hakkında konuşuyorsanız, hem sanal makineler hem de kaplar CPU uyumludur ve büyük bir veritabanının aynı işi yapan çok sayıda küçük veritabanından daha az CPU tüketeceğinden çok olumlu olmayacağım.

Sorununuz bellekse, sanal makineler sizin için iyi bir seçim değildir. Konteynerler vardır. İhtiyaçtan daha fazla RAM tüketmeyeceklerini bilerek, istediğiniz kadar kapsama alanı sağlayabileceksiniz. Toplam bellek tüketimi, çok sayıda küçük veritabanı için büyük bir veritabanına kıyasla daha yüksek olsa da, farkın çok önemli olmayacağını düşünüyorum. YMMV.

“Pahalı” olarak düşündüğünüz şeye bağlı.

Bir veritabanı mutlaka pahalı bir ticari veritabanı sunucusu olmak zorunda değildir (Oracle'ı düşünün), mutlaka bir kaynak aç ilişkisi olması gerekmez. Gereksinimlerinize bağlı olarak, SQLite veritabanını veya hatta dosya sistemini kalıcı bir veri depolama alanı olarak kullanabilirsiniz.

Tüm bu hizmetler tek bir veritabanı örneğini / sunucusunu da paylaşabilir ve hizmet başına yalnızca yalıtılmış şemalara sahip olabilir.

Buradaki temel argüman, hizmetin verilerine sahip olması ve kontrol etmesi gerektiğidir. Bunu nasıl başarıyor, bir seçim ve teknik detaylar meselesidir.

Bir hizmetin verilerini edinmesinin ve denetlemesinin en iyi yolu, kendi “kişisel” veritabanına sahip olmaktır. Bu, teknoloji ve veri şeması evriminde tam bir seçim özgürlüğü sağlar. Başka bir hizmetin bir hizmete ait verilere erişebilmesinin tek yolu, bir hizmetten veri istemektir. Bu şekilde, dahili veri sunumunun değiştirilmesi gerekirse, kolayca değiştirilebilir ve başka hiçbir hizmet kırılmaz.

Yani, özetlemek gerekirse. Hizmet başına bir veri tabanına sahip olmak pahalı değildir ve gerekli değildir. Bu, mikro hizmetler geliştirirken bir noktada vermeniz gereken bir karardır. Seçeneklerin her birinin sonuçları ve sınırlamaları vardır. Bunları inceleyin ve kendi seçiminizi yapın.