Dağıtılmış Veri Yönetimi - veritabanlarını mikro hizmetlere yerleştirme [kapalı]

Kısa bir süre önce Yazılım tasarımı üzerine bir ders alıyorum ve bir hizmetin bileşenlerinin mümkün olduğu kadar bağımsız olan mikro hizmet alt bileşenlerine ayrıldığı bir 'mikro hizmet modeli' kullanma hakkında yeni bir tartışma / öneri vardı.

Bahsedilen bölümlerden biri, tüm mikro servislerin konuştuğu tek bir veri tabanına sahip olmanın sık görülen modelini takip etmek yerine, her mikro hizmet için ayrı bir veri tabanına sahip olmanızdı.

Bunun daha iyi ifadeli ve daha ayrıntılı bir açıklaması burada bulunabilir: Merkezi Olmayan Veri Yönetimi bölümü altında http://martinfowler.com/articles/microservices.html.

Bunu söyleyen en göze çarpan kısım:

Mikro hizmetler, her bir hizmetin kendi veritabanını, aynı veritabanı teknolojisinin farklı örneklerini veya tamamen farklı veritabanı sistemlerini (Polyglot Kalıcılık adı verilen) yönetmesini sağlamayı tercih eder. Çokgrup kalıcılığını monolitte kullanabilirsiniz, ancak mikroservislerde daha sık görülür.

Şekil 4

Bu konsepti sevdim ve diğer pek çok şey arasında, bakım konusunda güçlü bir gelişme ve üzerinde çalışan birden fazla insanla projelere sahip olmak olarak görüyorum. Bu, hiçbir şekilde bir deneyim yazılımı mimarı olmadığımı söyledi. Hiç kimse bunu uygulamaya çalıştı mı? Hangi avantajlara ve engellere maruz kaldınız?

Mikro hizmet yaklaşımının olumlu ve olumsuz yönlerini konuşalım.

İlk olumsuzluklar. Mikro hizmetleri oluştururken, kodunuza doğal bir karmaşıklık eklersiniz. Tepegöz ekliyorsun. Çevreyi çoğaltmayı zorlaştırıyorsunuz (örneğin, geliştiriciler için). Hata ayıklamayı aralıklı sorunları daha da zorlaştırıyorsunuz.

Bana bir dezavantajı göstereyim. Bir sayfa oluştururken çağrılan 100 mikro-servisin olduğu ve her birinin zamanın% 99.9'unu doğru olanı yaptığı varsayımsal olarak düşünün. Fakat zamanın% 0,05'i yanlış sonuç veriyor. Ve zamanın% 0,05'i, bağlanmak için bir TCP / IP zaman aşımına ihtiyaç duyulan ve 5 saniye süren yavaş bir bağlantı isteği vardır. İsteğinizin yaklaşık% 90,5'i mükemmel çalışıyor. Ancak, zamanın% 5'i yanlış sonuçlara ulaştı ve sayfanızın% 5'i yavaş. Ve her tekrarlanamayan başarısızlığın farklı bir nedeni var.

İzleme, çoğaltma ve benzeri işlemler için araç gereçler üzerine çok fazla düşünce yapmazsanız, bu bir karmaşaya dönüşecektir. Özellikle bir mikro servis diğerini birkaç katman derinliğinde diğeriyle çağırdığında. Ve bir kez sorunlarınız olduğunda, zamanla daha da kötüye gidecek.

Tamam, bu bir kabus gibi geliyor (ve birden fazla şirket bu yola girerek kendileri için büyük sorunlar yarattı). Başarı sadece olası olumsuz tarafların açıkça farkında olmanız ve bunu çözmek için sürekli çalışmanız mümkündür.

Peki ya bu monolitik yaklaşım?

Monolitik bir uygulamanın mikro servisler kadar modüler hale getirilmesinin de kolay olduğu ortaya çıktı. Ve bir işlev çağrısı, pratikte bir RPC çağrısından daha ucuz ve daha güvenilirdir. Böylece aynı şeyi, daha güvenilir olması, daha hızlı çalışması ve daha az kod içermesi dışında geliştirebilirsiniz.

Tamam, peki şirketler neden mikro hizmetler yaklaşımına gidiyor?

Bunun cevabı, ölçeklenirken, yekpare bir uygulama ile yapabilecekleriniz için bir sınırın olmasıdır. Çok fazla kullanıcı, çok fazla istek ve daha sonra, veritabanlarının ölçeklenmediği bir noktaya ulaşırsınız, web sunucuları kodunuzu bellekte tutamazlar vb. Ayrıca, mikro hizmet yaklaşımları, uygulamanızın bağımsız ve artımlı yükseltmelerine izin verir. Bu nedenle, bir mikro hizmet mimarisi, uygulamanızı ölçeklendirmek için bir çözümdür.

Kişisel kurallarım, kodlama dilindeki (örneğin Python) koddan optimize edilmiş C ++ 'a gitmek genellikle performans ve bellek kullanımında 1-2 büyüklük sırasını iyileştirebilir. Dağıtılmış bir mimariye diğer yoldan gitmek, kaynak gereksinimlerine büyük bir katkı sağlar ancak süresiz olarak ölçeklendirmenize izin verir. Dağınık bir mimarinin çalışmasını sağlayabilirsiniz, ancak bunu yapmak daha zordur.

Bu nedenle, eğer kişisel bir projeye başlıyorsanız, yekpare olmak gerektiğini söyleyebilirim. Bunu iyi yapmayı öğren. Dağıtılmayın çünkü (Google | eBay | Amazon | etc). Dağıtılmış büyük bir şirkete giriyorsanız, nasıl çalıştıklarına dikkat edin ve onları mahvetmeyin. Ve geçişi yapmak zorunda kalırsanız çok dikkatli olun, çünkü çok, çok yanlış bir şekilde yapması kolay bir şey yapıyorsunuzdur.

Açıklama, her büyüklükteki şirkette 20 yıla yakın bir deneyime sahibim. Ve evet, hem monolitik hem de dağıtık mimarileri yakından ve kişisel olarak gördüm. Size dağıtılmış bir mikro hizmet mimarisinin gerçekten yapmanız gereken bir şey olduğunu söyledim, çünkü bir şekilde daha temiz ve daha iyi olduğu için değil.

Btilly'nin cevabına gönülden katılıyorum, ancak sadece arkasındaki özgün bir ilham kaynağı olduğunu düşündüğüm Mikroservisler için bir pozitif daha eklemek istedim.

Bir Microservices dünyasında, servisler alanlara hizalanır ve ayrı ekipler tarafından yönetilir (bir ekip birden fazla servisi yönetebilir). Bu, her ekibin hizmetleri tamamen ayrı ayrı ve diğer hizmetlerden bağımsız olarak (doğru sürümler varsayarak vb.) Serbest bırakabileceği anlamına gelir.

Bu önemsiz bir avantaj gibi görünse de, Monolitik bir dünyada bunun aksini düşünün. Burada, başvurunun bir kısmının sık sık güncellenmesi gerektiğinde, tüm projeyi ve üzerinde çalışan diğer ekipleri etkileyecektir. Daha sonra zamanlamayı, incelemeleri vb. Tanıtmanız gerekecektir ve tüm süreç yavaşlar.

Seçiminize göre, ölçeklendirme gereksinimlerinizi göz önünde bulundurmanın yanı sıra, gerekli takım yapılarını da göz önünde bulundurun. Btilly'nin Monolitik'i başlatıp daha sonra Mikroservices'in yararlı olabileceği yerleri belirleme önerisi ile aynı fikirdeyim, ancak ölçeklendirilebilirliğin tek yararı olmadığının farkında olun.

Adil miktarda bağımsız veri kaynağına sahip bir yerde çalıştım. Hepsini tek bir veritabanına, ancak web servislerinin erişebildiği farklı şemalara koydular. Buradaki fikir, her bir hizmetin, işlerini yürütmek için gereken minimum veri miktarına erişebilmesi idi.

Monolitik bir veri tabanına kıyasla pek fazla bir yükü yoktu, ama sanırım bu çoğunlukla zaten izole edilmiş gruplardaki verilerin niteliğinden kaynaklanıyordu.

Web hizmetleri, bir sayfa oluşturan web sunucusu kodundan çağrıldı, bu nedenle, bu, muhtemelen, belki de önerildiği gibi dağıtılmamış ve dağıtılmamış olmasına rağmen, bir mikropun çağırdığı kadar mikro olmasa da, mikroservisler mimariniz gibi. 3. taraf hizmetinden veri almak için, orada 1 dağıtılmış veri hizmeti örneği vardı). Bunu yapan şirket, ölçekten daha fazla güvenlikle ilgileniyordu, ancak bu hizmetler ve veri hizmetleri, birindeki sömürülebilir bir kusurun tüm sisteme tam erişim sağlamayacağı için daha güvenli bir saldırı yüzeyi sağladı.

Mükemmel Objectwatch bültenlerinde Roger Sessions, Software Fortresses konseptine benzer bir şey tarif etti (ne yazık ki bültenler artık çevrimiçi değil, ancak kitabını satın alabilirsiniz).