Merhaba Habr. OTUS'ta yeni kurs akışına kayıtlar şu anda açık . Kursun başlamasının arifesinde sizlerle orijinal makalemi paylaşmak istiyorum.
Giriş
Mimari tarzın seçimi, bir bilgi sistemi oluştururken temel teknik kararlardan biridir. Bu yazı dizisinde, bina uygulamaları için en popüler mimari tarzları analiz etmeyi ve hangi mimari tarzın en çok tercih edildiği sorusuna cevap vermeyi öneriyorum. Sunum sürecinde mimari tarzların monolitlerden mikro hizmetlere kadar gelişimini açıklayan mantıksal bir zincir çizmeye çalışacağım.
Biraz tarih
Geliştiricilere "Neden mikro hizmetlere ihtiyacımız var?" diye sormaya çalışırsanız çeşitli yanıtlar alırsınız. Mikro hizmetlerin ölçeklenebilirliği iyileştirdiğini, kodun anlaşılmasını kolaylaştırdığını, hata toleransını iyileştirdiğini ve bazen "kodunuzu temizlemenize" olanak sağladığını duyacaksınız. Mikro hizmetlerin ortaya çıkışının ardındaki amacı anlamak için tarihe bakalım.
Kısaca, mevcut anlayışımızdaki mikro hizmetler şu şekilde ortaya çıktı: 2011 yılında çeşitli şirketlerin çalışmalarını analiz eden James Lewis, SOA'nın dağıtımını hızlandırma açısından optimize eden yeni bir "mikro uygulama" modelinin ortaya çıkmasına dikkat çekti. Hizmetler. Bir süre sonra, 2012'de bir mimari zirvesinde modelin adı mikro hizmet olarak değiştirildi. Bu nedenle, mikro hizmetleri tanıtmanın ilk amacı kötü şöhretli hizmetleri geliştirmekti. pazara zamanı.
Mikro hizmetler 2015'te heyecan dalgasındaydı. Bazı araştırmalara göre mikro hizmetler konusuyla ilgili bir rapor olmadan tek bir konferans bile tamamlanmadı. Üstelik bazı konferanslar yalnızca mikro hizmetlere ayrılmıştı. Günümüzde birçok proje bu mimari tarzı kullanmaya başlıyor ve eğer proje tonlarca eski kod içeriyorsa, mikro hizmetlere geçiş muhtemelen aktif olarak gerçekleştiriliyor demektir.
Yukarıdakilerin hepsine rağmen oldukça az sayıda geliştirici hala “mikro hizmet” kavramını tanımlayabilmektedir. Ama bu konuya biraz sonra değineceğiz...
yekpare
Mikro hizmetlerin zıttı olan mimari tarz monolittir (veya hepsi bir arada). Bir monolitin ne olduğunu söylemek muhtemelen mantıklı değil, bu yüzden mimari tarzların daha da gelişmesini başlatan bu mimari tarzın dezavantajlarını hemen sıralayacağım: boyut, bağlantı, dağıtım, ölçeklenebilirlik, güvenilirlik ve sağlamlık. Aşağıda eksikliklerin her birine ayrı ayrı bakmayı öneriyorum.
boyut
Monolit çok büyüktür. Ve genellikle çok büyük bir veritabanıyla iletişim kurar. Uygulama bir geliştiricinin anlayamayacağı kadar büyük hale geliyor. Yalnızca bu kod üzerinde çalışmak için çok zaman harcamış olanlar monolitle iyi çalışabilirken, yeni başlayanlar monoliti anlamaya çalışırken çok zaman harcayacaklar ve çözeceklerinin garantisi yok. Genellikle, bir monolitle çalışırken, her zaman monoliti az çok iyi bilen ve bir buçuk yıl içinde diğer yeni geliştiricilerin ellerini geçen bazı "şartlı" kıdemliler vardır. Doğal olarak, böylesine şartlı bir kıdemli tek bir başarısızlık noktasıdır ve onun ayrılışı monolitin ölümüne yol açabilir.
Bağlantılılık
Monolit, öngörülemeyen sonuçlara yol açabilecek değişiklikler olan "büyük bir çamur topudur". Bir yerde değişiklik yaparak diğerindeki monolite zarar verebilirsiniz (aynı "kulağınızı kaşıdınız, *@ düştünüz"). Bunun nedeni monolitteki bileşenlerin çok karmaşık ve en önemlisi açık olmayan ilişkilere sahip olmasıdır.
yayılma
Bileşenleri arasındaki karmaşık ilişkiler nedeniyle bir monolitin konuşlandırılması, kendi ritüeli olan uzun bir süreçtir. Böyle bir ritüel genellikle tamamen standartlaştırılmaz ve "sözlü olarak" aktarılır.
ölçeklenebilirlik
Monolith modüllerin birbiriyle çelişen kaynak ihtiyaçları olabilir ve donanım açısından bir uzlaşmaya varılması gerekebilir. A ve B hizmetlerinden oluşan bir monolitinizin olduğunu hayal edin. A Hizmeti, sabit sürücünün boyutunu talep ederken, B hizmeti de RAM'i talep ediyor. Bu durumda, ya monolitin kurulu olduğu makinenin her iki hizmetin gereksinimlerini desteklemesi gerekir ya da hizmetlerden birini manuel olarak yapay olarak devre dışı bırakmanız gerekir.
Başka bir örnek (daha klasik): A hizmeti, B hizmetinden çok daha popülerdir, bu nedenle 100 A hizmeti ve 10 B hizmeti olmasını istersiniz. Yine iki seçenek: ya 100 tam teşekküllü monolit dağıtırız ya da daha sonra bazılarında B hizmetlerinin manuel olarak devre dışı bırakılması gerekecektir.
Güvenilirlik
Tüm hizmetler bir arada bulunduğundan monolit düşerse tüm hizmetler aynı anda düşer. Aslında bu o kadar da kötü olmayabilir, en azından dağıtılmış bir sistemde kısmi arızalar olmayacaktır, ancak diğer taraftan kullanıcıların %0.001'inin kullandığı işlevsellikteki bir hata nedeniyle tüm kullanıcıları kaybedebilirsiniz. sisteminizin.
Eylemsizlik
Monolitin boyutundan dolayı yeni teknolojilere geçiş zordur. Sonuç olarak aynı kıdemliyi korumak ayrı bir görevdir. Bir projenin başında seçilen teknoloji yığını, ürünün gelişimini engelleyen bir blok haline gelebilir.
Sonuç
Bir dahaki sefere insanların bu sorunları bileşenlere ve SOA'ya geçerek nasıl çözmeye çalıştıklarından bahsedeceğiz.
Daha fazla oku:
Kaynak: habr.com