Mikro hizmetler: MonolithFirst?

Tüm artıları ve eksileri, nedenleri ve nedenleri, vb.Yüksek düzeyde bir genel bakış elde etmeye çalışan mikro hizmet mimarilerini araştırıyorum. Okuduğum / izlediğim bilgilerin çoğu ThoughtWorks'ten geliyor (Martin Fowler, Neal Ford, et ark).

Martin Fowler'in konuyla ilgili çalışmalarının çoğu, Microservices (programlamada bir ev ismi olarak, genel pratikte olmasa bile) hala gençken birkaç yaşındadır, bu yüzden çoğunu bir tuz tanesi ile alıyorum.

Özellikle bir şey şudur:

Bir mikro hizmet mimarisi kullanan ekiplerle ilgili hikayeler duyduğumda, ortak bir kalıp fark ettim.

• Hemen hemen tüm başarılı mikro servis hikayeleri, çok büyük ve parçalanmış bir monolit ile başladı
• Sıfırdan bir mikro hizmet sistemi olarak inşa edilmiş bir sistemi duyduğum neredeyse tüm vakalar, ciddi bir sorunla sonuçlandı.

Bu kalıp, çalışma arkadaşımın çoğunun, uygulamanızın değerli hale getirecek kadar büyük olacağından emin olsanız bile, mikro hizmetlerle yeni bir projeye başlamamanız gerektiğini savunmasına neden oldu. .

(ref: https://martinfowler.com/bliki/MonolithFirst.html - vurgulama onların)

Şimdi, 3 yıl sonra ve mikro hizmetler ile daha yaygın bir terim, genellikle yeni bir sistemin, başlamak için daha büyük (-tro-mikro-hizmet-ancak-monolitten daha küçük) servis parçalarına sahip olması ve onları evrimsel bir önlemin parçası olarak daha ayrıntılı?

Veya yukarıdaki ifadelerin aksine, bir projeyi granüler bir mikro hizmet mimarisiyle sıfırdan başlatmak için bir norm var mı?

Mantıklı bir genel yaklaşım gibi görünüyor, ancak topluluğun düşüncelerini merak ediyor.

Şirketiniz bir süredir mikroservisler yapıyorsa, bazı parçalar zaten inşa edilmiş olabilir ve bunları dahil etmeniz yeterlidir. Muhtemelen örnekler bir hizmet olarak kimlik doğrulaması veya blob verilerinin depolanması olabilir. Bu durumda, sınırları zaten tanımladınız ve kodu yeni bir uygulamada yeniden kullanıyorsunuz. Bu iyi birşey.

Sınırın nerede olması gerektiğinden emin olmadığınız yeni kodlar için tek bir hizmette oluşturun. Modüler tutarsanız, mikro hizmetleri gerektiği gibi ayırabilirsiniz. Özellikle hizmetinizin geri kalanından farklı ölçeklenmesi gereken parçalar bulduğunuzda.

Mikro hizmetlerin yararı, talep üzerine yapılan işi ölçeklendirmek için örnekler ekleyebilmenizdir. Eğer bazı çalışmalarınız patlarsa, bunu kendi mikro hizmetine ayırmak mantıklı olabilir.

Genel olarak:

• Önceden oluşturulmuş mikro hizmetleriniz varsa, bunları yeniden kullanın
• Yeni bir şey inşa ediyorsanız, önce fikrin çalışmasını sağlayın
• İnşa ederken, bazı servislerin kolayca dağılabilmesi için işleri modüler tutmaya çalışın
• İnşa ederken, hizmetinizin bir kısmının talep üzerine farklı bir oranda ölçeklendirilmesi gerekiyorsa, bunu kendi hizmetine ayırın

Çoğu zaman, Martin Fowler gibi iyi şöhretleri olan akıllı insanlardan faydalı yönergeler duyuyoruz ve daha sonra hiçbir şekilde atlanamayan sert bir doktrine dönüştürüyoruz.

Böyle ifadeleri almak zorunda ruhu içinde onlar içindir nasıl. Martin Fowler insanları analizle felçten kurtarmaya çalışıyor ve önce işe yarayan bir şey inşa etmelerini söylüyor. Uygulamanızın gerçekten nasıl çalıştığı hakkında daha fazla bilgi sahibi olduğunuzda, daha sonra her zaman ayırabilirsiniz.

Mikro hizmetlerin en değerli faydaları basit kod modülerleştirmesi ile elde edilebilir. Sahip olduğunuz modül sistemini (özellik, npm, nuget, ne olursa olsun) kullanarak özellik gruplarını modüller halinde izole edebilirsiniz. Her modül tek bir amaca hizmet edebilir, kendi repo'sunu kullanabilir, kendi DB şemasını kullanabilir, kendi yapılandırmasını yönetebilir, kendi özellik biriktirme ve yayın zamanlamasına sahip olabilir. Yine de birlikte bir monolit üzerine yerleştirilebilirler. Bu çok yönetilebilir bir ek yüktür ve bazı iyi faydalar sağlar. Daha büyük yük, dağıtımları ayırmaktan gelir; bu, yalnızca gerekli olan ölçeğe sahip olduğunuzda gerçekten değerlidir. Kodunuz zaten modüler ise, zaman geldiğinde daha kolay bir geçiş olacaktır.

Kanımca, önce bir monolit geliştirmek (veya daha iyisi: uygulamanızın bir bölümünü monolit olarak geliştirmek) yararlı olabilir.

Sorununuzun etki alanı ve sınırları hakkında emin olmadığınız durumlar vardır (örneğin, bir gemi yönetim sitesi inşa ediyorum, bir gemi hizmetine VE bir filo hizmetine ihtiyacım var mı, yoksa bir gemi hizmeti yeterli mi?) Ve bu gibi durumlarda monolitin geliştirilmesi daha kolay olabilir.

Karışıma farklı teknolojiler getirmeniz gerekiyorsa bunu yapmayı bırakmalısınız (örneğin, mevcut parçalarınız C # ile yazılır, ancak yeni sorununuz makine öğrenimi gerektirir, en iyi şekilde python ile yapılır), alanınızdaki alanlar hakkında iyi bir anlayışa sahip olun. projeniz veya monolitiniz galvanize olur, örneğin herkes sadece bu monoliti inşa eder ve ayrı hizmetler kavramını ezer.

MF'nin bu makalesinde birkaç soru olduğundan eminim.

Benim almak budur:

Bakım veya ölçeklenebilirlik sorunları olan bir Monolith, mikro servislere bölünerek geliştirilir. Böyle bir proje neredeyse her zaman 'başarılı' olacaktır, çünkü küçük bir bölümün parçalanması bile ölçülebilir kazançlara neden olabilir ve mutlu olduğunuzda altına bir çizgi çizebilirsiniz.

Üvey monolit + bir mesaj kuyruğuna ve 'Microservice Mimarlık' olarak çalışan işlemler sayar bir çift olsun pub aşağı olması bir argüman, ancak kesinlikle olacak çağıran Proje bahsederken o kadar.

Öte yandan, seçilen mimariden bağımsız olarak herhangi bir yeni proje beklentileri karşılamama riski taşır, bu yüzden doğal olarak daha düşük bir başarı oranı beklersiniz. Ayrıca, her şeyi 'En İyi Uygulama Mikro Hizmet Mimarisi' ni baştan aşağı yapmaya hedeflediyseniz, yeni teknolojilere ve mikro hizmetlerin daha zor parçalarına giriyor olabilirsiniz.

Ayrıca MF'nin büyük bir OOP perspektifinden yazdığını da hatırlamalıyız. Doğal olarak daha modern bir dağıtılmış yaklaşıma kuşkuyla bakıyor.

Bu gün ve yaşta, herhangi bir büyük iş çözümünün bir mikro hizmet unsurunu içermesini beklerdim ve tek bir masaüstü tarzı uygulama dağıtmadığınız sürece sadece bir aptal tek bir dev monolit uygulaması yapmanızı önerir.

Tecrübelerime göre, insanların problemleri nedeniyle teknoloji problemlerinden çok daha fazla projenin başarısız olduğuna tanık oldum. Ne yazık ki, insanlar başarısızlığı sevmezler ve bu nedenle başarısızlığın nedenlerini yanlış bildirme ve teknolojiyi suçlama eğilimi gösterirler.

Alanımda, finans alanında, yeni projelerin çoğu bugünlerde mikro hizmet mimarilerini takip ediyor ve TCO (toplam sahip olma maliyeti) perspektifinden kazanan bir mimari gibi görünüyor. Bu projeler sık ​​sık başarısız gibi görünmüyor ve verilen nedenler uygulama mimarisini sık sık sorun olarak listelemiyor.