Monolitlerin ölçeklenmesi ve mikro hizmetlerin ölçeklendirilmesi

Mikro hizmetlerin kullanımına ilişkin yaygın argümanlardan biri daha iyi ölçeklenebilirliktir. Ama bu argümanın gerçekten geçerli olup olmadığını merak ediyorum.

Diyelim ki 10 mikro hizmetten oluşan bir uygulamamız var, bunlardan 9'u her iki örneğe (yedeklilik için) ve bunlardan biri yükü (ölçeklenebilirlik) ele almak için 4 örneğe sahip. Mikroservis yanlısı argüman, o zaman bu miroserviyi diğer hizmetlerden bağımsız olarak ölçekleyebilmenizdir.

Bununla birlikte, 10 mikro hizmetin hepsinin tek bir monolit içindeki modüller olduğunu ve bu monolitin birkaç örneğinin (örneğin yukarıdaki toplam 22 gibi) konuşlandırıldığını varsayalım. Sistem, kritik bir parçanın yükünü kaldırabilmelidir, çünkü bunu yapmak için yeterli örnek vardır. Örnekler program mantığı gerekmiyorsa, tek dezavantajı, ikili ve gerekli RAM miktarının biraz daha büyük olması olacaktır. Ama sonra tekrar, fark çoğu durumda çok büyük olmamalıdır - en azından yığının geri kalanıyla karşılaştırılmamalıdır (Spring Boot'u düşünün). Ölçekli bir monlitin tepesi, dağıtılmış bir sistemin yanlışları (çoğu) olmadan daha basit bir sistem olacaktır.

Bir şey mi kaçırıyorum?

microservices

— deamon
kaynak

Ne kadar büyük bir yekpare konuşuyorsun? Çünkü bunun "biraz daha büyük" bir RAM miktarından daha fazla olabileceğini düşünüyorum. Dağıtım süresinden bahsetmemek gerekirse - bir hatayı düzeltmek 4 yerine 22 dağıtım gerektirebilir. Ama belki monolitiniz küçüktür ve dağıtımlar çok zaman almaz, veritabanı geçişleri çok zaman almaz vb.

— Thomas Owens

Sayılan kod satırlarını ortadan kaldırdım, ancak monolit birkaç bin satır koda sahip olacaktı (dev bir sistem değil). Benim gözümün başlangıç noktası, gerçek uygulama kodunun boyutunun Spring ve Hibernate gibi büyük çerçevelere kıyasla küçük olmasıydı. Dağıtımların sayısı aslında mikro hizmetlerle olduğundan daha az olabilir, çünkü 2 örneğiniz varsa zaten temel yedekliliğe sahip olacaksınız ve daha fazla örnek ölçeklenebilirlik için olacaktır.

— deamon

@deamon Monolit yaklaşımında, kodun her örnekte tamamen ölü olan hiçbir parçası olmadığını, nadiren kullanılan kodu unutmayın. Şimdi, kodun kendisi sadece az miktarda bellek tüketebilir, ancak bellekte zincirlenmiş çok fazla nesne kullanıyorsa, bu miktar önemli ölçüde büyüyebilir.

— Frank Hopkins

Temel "çalıştırma kodu alma" yükünün mutlaka tüm jvm hizmet görüntüsünün bir parçası olduğu Java uygulamalarınızdan bildiğiniz kadar büyük olmadığını unutmayın.

— Frank Hopkins

Yanıtlar:

Mikro hizmetlerin amacı işlemci yükünü azaltmak değildir. Aslında, genel şebeke kodu olarak kullanılan fonksiyonların iletişim ve tekrarlarının yükü nedeniyle, genellikle işlemci yükünü bir miktar arttırır .

Monolit kaldırılması noktası çok daha korumak dağıtmak ve işlevsellik karmaşık bir sistemi çalıştırmak için muktedir olduğunu hiç . Sisteminiz belirli bir boyuta ulaştığında, derleme, test etme, dağıtma vb. Mikro hizmetlerle, bir sistem parça parçasını yükseltebilir, yeniden başlatabilir veya geri alabilirsiniz.

Hata yapmayın, mikro hizmetler yazmıyoruz, çünkü şeyleri uzak arabirimler üzerinde gevşek bir şekilde birleştirmek için doğal olarak daha iyi bir çözümdür . Aslında, bir monolitin sağlayabileceği güçlü tip ve tutarlılık kontrolünün kaybı genellikle büyük bir dezavantajdır. Biz çünkü bunu biz gereken karmaşıklık daha bizi aldı çünkü ve optimum altı durumun iyi yapıyoruz.

— Kilian Foth
kaynak

Kabul. Bir mikro hizmet mimarisine geçmenin nedeni çoğunlukla politiktir. Dağıtılmış yük, ayırma, nedenler değil sonuçlardır. Mikro hizmetlerin gerçek yararı SDLC ve Yönetişimdir. Bunun da ötesinde, mimari, çoğu durumda şirketin pazar stratejisinden gelen bir ihtiyaca mantıklı bir yanıttır. Pazara çıkış süresi monolit mimarilerden daha kısadır, bu nedenle şirketin yeni stratejiler benimsemesine, birinden diğerine sorunsuz ve hızlı bir şekilde geçmesine izin verilir

— Laiv

Bu yüzden birisi orta ve küçük uygulamalar için doğrudan mikro hizmetlere gitmemelidir. Sisteme genel ve karmaşıklık eklenmesi, bu ölçeklerde monolitik bir sistemden daha fazla zaman, para ve kalite maliyetine neden olabilir.

— T. Sar

»Bunu yapıyoruz çünkü yapmak zorundayız çünkü karmaşıklık bizleri daha iyi hale getirdi ve yetersiz bir durumdan en iyi şekilde yararlanıyoruz.« Evet. Benim için bu çivi!

— Thomas Junk

Cevabın son kısmına katılmıyorum. mikro-hizmetler doğal olarak monolitten daha iyidir, çünkü birden fazla bilgisayar kullanırlar

— Ewan

@ewan Monolitli birden fazla bilgisayar da kullanabilirsiniz.

— deamon

Çoğunlukla haklısın. Eşit olarak yüklenen hızlı servisleriniz varsa, hepsini tüm kutulara da yükleyebilirsiniz. Hizmet başına bir kutuya sahip olmak 'güzel' değildir, ancak paradan tasarruf sağlar.

Ancak. Dengesizlik olur olmaz, servis 5'in 2 dakika için cpu'nun% 100'ünü aldığını varsayarsak, bu hizmeti kendi kutusuna taşımak istersiniz, böylece çalışırsa diğer tüm hizmetleri engellemez.

Yük nedeniyle servis çağrısı 5 zaman aşımına uğrarsa, uygulamanızın yerine bazı işlevler başarısız olur.

Şimdi aynı şeyi iyi modüler bir monolit ile yapabilirsiniz. Tüm hizmetleri yükleyin, ancak yalnızca 5 trafiği bunlardan birine yönlendirin. Servis 5 trafiği diğer kutulara yönlendirmese de.

Ancak genellikle doğaları gereği monolitler, aynı kutuya kurulan gevşek bir hizmet koleksiyonu değildir. Modüller arasında uygulamanın başarısız olmasına neden olacak bellek çağrıları olacaktır.

— Ewan
kaynak

Mikro hizmetlerin noktası 1) endişelerin ayrılması ve 2) yükün dağıtılmasıdır. Temelde bu, bu göreve özgü teknolojilerle yapabileceğimiz en iyi kara kutulu hizmeti yapmak için bizi özgürleştirir. Hizmetlerimiz, farklı programlama dillerinde farklı yığınlarda yazılmış çok dilli olabilir. Farklı ekipler, diğerlerinin API'lerinin sözleşmesinin ötesinde nasıl çalıştığına dair hiçbir bilgi sahibi olmadan her bir hizmet üzerinde çalışabilir. Bu, bir bütün olarak ele alındığında, performans için hata ayıklaması, anlaşılması ve ayarlanması daha kolay olan her hizmet için çok daha basit bir kod tabanına izin verir.

— Lewis A Satıcıları
kaynak

Kısmen katılıyorum. Demek istediğim, genel olarak mikro hizmetlerin argümanları değil, ölçeklenebilirlikti. Benim özel durumumda, mikro hizmetlerin hepsi aynı teknolojide yazılıyor. Dolayısıyla, her biri için farklı bir teknoloji kullanmak mümkün olsa da, burada durum böyle değil. Ölçeklenebilirlik konusunda önemli bir noktayı kaçırmadığımı doğrulamak istedim.

— deamon