Monolitik ve mikro hizmet mimarileri
Fabrikam, yeni insansız hava aracı hizmetini mevcut uygulamasına entegre etti. Bu çözümün, uygulamaları için iyi bir uzun vadeli plan olmadığını fark ettiler. Mevcut sistem monolitik bir mimaridir, ancak bu tam olarak ne anlama gelir?
Monolitik mimari nedir?
Monolitik mimari, bir uygulamanın tüm bileşenlerinin tek bir ünitede bir arada bulunduğu bir mimaridir. Bu ünite genellikle uygulamanın tek bir çalışma zamanı örneğinde kısıtlanır. Geleneksel uygulamalar genellikle web arabiriminden, hizmet katmanından ve veri katmanından oluşur. Monolitik mimaride, bu katmanlar uygulamanın bir örneğinde birleştirilir.
Monolitik mimariler genellikle küçük uygulamalar için uygun çözümlerdir, ancak uygulama büyüdükçe verimsiz hale gelebilirler. Başlangıçta küçük bir uygulama hızla ölçeklendirmesi zor, dağıtımı zor ve yenilik yapmak zor olan karmaşık bir sistem haline gelebilir.
Tüm hizmetler tek bir ünitede yer alır. Bu düzenleme, işletmeleri ve sonraki sistem yükü büyüdükçe zorluklar getirir. Bu zorluklardan bazıları şunlardır:
- Hizmetleri bağımsız olarak ölçeklendirmek zordur.
- Kod tabanı büyüdükçe dağıtımları geliştirmek ve yönetmek karmaşıktır ve bu da yayınları ve yeni özellik uygulamasını yavaşlatıyor.
- Mimari, yeni platformlarda ve SDK'larda yenilikleri sınırlayan tek bir teknoloji yığınına bağlıdır.
- Veri şeması güncelleştirmeleri giderek daha zor olabilir.
Bu zorluklar, mikro hizmet mimarisi gibi alternatif mimarilere bakılarak ele alınabilir.
Mikro hizmetler mimarisi nedir?
Mikro hizmetler mimarisi küçük, bağımsız ve gevşek bir şekilde bağlanmış hizmetlerden oluşur. Her hizmet bağımsız olarak dağıtılabilir ve ölçeklendirilebilir.
Mikro hizmet, tek bir küçük geliştirici ekibinin yazabileceği ve bakımını yapabilecek kadar küçüktür. Hizmetler bağımsız olarak dağıtılabildiği için, bir ekip tüm uygulamayı yeniden derlemeden ve yeniden dağıtmadan mevcut bir hizmeti güncelleştirebilir.
Her hizmet genellikle kendi verilerinden sorumludur. Veri yapısı yalıtılmış olduğundan, şemaya yapılan yükseltmeler veya değişiklikler diğer hizmetlere bağımlı değildir. Veri istekleri genellikle API'ler aracılığıyla işlenir ve iyi tanımlanmış ve tutarlı bir erişim modeli sağlar. İç uygulama ayrıntıları hizmet tüketicilerinden gizlenir.
Her hizmet bağımsız olduğundan farklı teknoloji yığınları, çerçeveler ve SDK'lar kullanabilir. Hizmetlerin, uzaktan yordam çağrıları (RPC' ler) veya diğer özel iletişim yöntemleri yerine iyi tanımlanmış API'ler kullanarak hizmet-hizmet iletişimi için REST çağrılarını kullandığını görmek yaygın bir durumdur.
Mikro hizmet mimarileri teknolojiden bağımsızdır, ancak genellikle kapsayıcıların veya sunucusuz teknolojilerin bunların uygulanması için kullanıldığını görürsünüz. Sürekli dağıtım ve sürekli tümleştirme (CI/CD), geliştirme etkinliklerinin hızını ve kalitesini artırmak için sıklıkla kullanılır.
Mikro hizmet mimarisinin avantajları
Neden bir mikro hizmet mimarisi seçesiniz? Mikro hizmet mimarisinin çeşitli birincil avantajları vardır:
- Çeviklik
- Küçük kod, küçük ekipler
- Teknolojilerin karışımı
- Esnek -lik
- Ölçeklenebilirlik
- Veri yalıtımı
Çeviklik
Mikro hizmetler bağımsız olarak dağıtıldığından, hata düzeltmelerini ve özellik sürümlerini yönetmek daha kolaydır. Uygulamanın tamamını yeniden dağıtmadan bir hizmeti güncelleyebilir ve bir sorun çıkarsa güncellemeyi geri alabilirsiniz. Birçok geleneksel uygulamada, uygulamanın bir bölümünde bir hata bulunursa, yayın işleminin tamamını engelleyebilir. Sonuç olarak, yeni özellikler bir hata düzeltmenin tümleştirilmesi, test edilmesi ve yayımlanması için bekletilebilir.
Küçük kod, küçük ekipler
Mikro hizmet, tek bir özellik takımının oluşturabileceği, test edip dağıtabileceği kadar küçük olmalıdır. Küçük kod tabanlarını anlamak daha kolaydır. Büyük bir monolitik uygulamada kod bağımlılıkları zaman içinde karışabilir. Yeni bir özellik eklemek için birçok yerde koda dokunmak gerekir. Mikro hizmetler mimarisi, kod veya veri depolarını paylaşmayarak bağımlılıkları en aza indirir. Bu, yeni özellikler eklemeyi kolaylaştırır.
Küçük ekip boyutları daha fazla çevikliği de artırır. "İki pizza kuralı", bir ekibin iki pizzanın ekibi besleyebileceği kadar küçük olması gerektiğini söylüyor. Açıkçası, bu tam bir ölçüm değildir ve takım iştahlarına bağlıdır! Ancak önemli olan, iletişimin yavaş olması, yönetim ek yükünün yukarı çıkması ve çeviklik azaldığı için büyük grupların daha az üretken olma eğiliminde olmasıdır.
Teknolojilerin karışımı
Ekipler, servislerine en uygun teknolojiyi seçebilir. Uygun teknoloji yığınlarının bir karışımını kullanabilirler. Her ekip, kendi hizmetini destekleyen teknolojileri bağımsız olarak geliştirebilir. Bu bağımsızlık nedeniyle hizmetler farklı geliştirme dillerini, bulut hizmetlerini, SDK'ları ve daha fazlasını kullanabilir. Ekipler, hizmetleri için en iyi seçenekleri belirlerken, hizmetin tüketicileri üzerindeki dış etkiyi en aza indirir.
Esnek -lik
Tek bir mikro hizmet kullanılamaz duruma gelirse, yukarı akış mikro hizmetleri hataları doğru şekilde işleyecek şekilde tasarlandığı sürece (örneğin, devre kesme uygulayarak) uygulamanın tamamını kesintiye uğratmaz. Kullanıcılarınızın veya hizmet tüketicilerinizin avantajı, uygulamanız için her zaman açık bir deneyimdir.
Ölçeklenebilirlik
Mikro hizmetler mimarisi, her mikro hizmetin diğerlerinden bağımsız olarak ölçeklendirilmesini sağlar. Uygulamanın tamamını genişletmeden daha fazla kaynak gerektiren alt sistemlerin ölçeğini genişletebilirsiniz. Bu düzenleme, uygulamanızın genel performansını artırır. Ayrıca maliyetleri en aza indirmeye yardımcı olur. Uygulamanızın tamamını ölçeklendirmek yerine yalnızca ihtiyacı olan hizmetlere daha fazla kaynak ekleyebilirsiniz.
Veri yalıtımı
Mikro hizmetler mimarisi, yalnızca tek bir mikro hizmet etkilendiğinden veri şeması güncelleştirmeleri gerçekleştirme özelliğini geliştirir. Monolitik bir uygulamada şema güncelleştirmeleri zor olabilir. Uygulamanın farklı bölümleri aynı verilere dokunabilir ve bu da şemada yapılan değişiklikleri riskli hale getirir. Mikro hizmetler mimarisiyle bir şemayı güncelleştirebilir ancak API yüzeyinizi olduğu gibi tutabilirsiniz. Hizmet tüketicileri, temel alınan veri mimarisinden bağımsız olarak aynı deneyime sahip olur.
Mikro hizmet mimarisinin olası zorlukları
Mikro hizmet mimarisinin birçok avantajı vardır, ancak her derde deva değildir. Mikro hizmet mimarisinin kendi zorlukları vardır:
- Karmaşıklık
- Geliştirme ve test etme
- İdare eksikliği
- Ağ tıkanıklığı ve gecikme süresi
- Veri bütünlüğü
- Yönetim
- Sürüm Oluşturma
- Beceri kümesi
Karmaşıklık
Mikro hizmetler uygulaması, eşdeğer monolitik uygulamadan daha hareketli parçalara sahiptir. Her hizmet daha basittir, ancak bir bütün olarak sistemin tamamı daha karmaşıktır. Hizmet bulma, düzenleme ve otomasyon araçlarıyla, genel uygulamada yönetilecek daha fazla parça olabilir.
Geliştirme ve test etme
Diğer bağımlı hizmetlere dayalı küçük bir hizmet yazmak, geleneksel monolitik veya katmanlı bir uygulama için yazmaktan farklı bir yaklaşım gerektirir. Mevcut araçlar her zaman hizmet bağımlılıklarıyla çalışacak şekilde tasarlanmamıştır. Hizmet sınırları arasında yeniden düzenleme zor olabilir. Özellikle uygulama hızla gelişirken hizmet bağımlılıklarını test etmek de zordur.
İdare eksikliği
Mikro hizmetler oluşturmanın merkezi olmayan yaklaşımının avantajları vardır, ancak sorunlara da yol açabilir. Uygulamanın bakımını yapmak zor olacak kadar çok farklı dil ve çerçeveye sahip olabilirsiniz. Ekiplerin esnekliğini aşırı kısıtlamadan proje genelinde bazı standartların uygulamaya alınması yararlı olabilir. Tekdüzen standartlara duyulan ihtiyaç, özellikle günlüğe kaydetme ve ölçümler gibi genel işlevsellik için geçerlidir.
Ağ tıkanıklığı ve gecikme süresi
Çok sayıda küçük, ayrıntılı hizmetin kullanılması, hizmetler arası iletişimin daha fazla kullanılmasına neden olabilir. Hizmet bağımlılıkları zinciri çok uzun olursa, örneğin, A hizmeti C... çağrısı yapan B'yi çağırırsa, bu ağ çağrılarının ek gecikme süresi sorun haline gelebilir. API'lerinizi dikkatli bir şekilde tasarlar. Aşırı konuşkan API'lerden kaçının, serileştirme biçimlerini düşünün ve eş zamansız iletişim desenlerini kullanmak için yer arayın.
Veri bütünlüğü
Her mikro hizmet kendi veri kalıcılığından sorumludur. Sonuç olarak veri tutarlılığı zor olabilir. Mümkün olduğunda nihai tutarlılığı benimseyin. Ayrıca yinelenen veriler ve yayılan bir veri mimarisiyle de sonuçlanabilir. Bu durum, hizmet ve veri çoğaltma ile ham depolama maliyetlerini ve veri platformu hizmet maliyetlerini artırabilir.
Yönetim
Mikro hizmetlerle başarılı olmak için olgun bir DevOps kültürü gerekir. Hizmetler arasında bağıntılı günlük kaydı zorlayıcı olabilir. Genellikle, loglamanın tek bir kullanıcı işlemi için birden çok hizmet çağrısıyla ilişkilendirilmesi gerekir.
Sürüm Oluşturma
Bir hizmet güncelleştirmeleri, hizmete bağlı hizmetleri bozmamalıdır. Herhangi bir zamanda birden çok hizmet güncelleştirilebilir. Dikkatli bir tasarım olmadan geriye veya ileriye dönük uyumluluk sorunları yaşayabilirsiniz. Yeni API sürümlerini benimseme konusunda gecikmeli olan hizmetler, eski API'ler için gereken kaynakları ve bakımı artırabilir.
Beceri kümesi
Mikro hizmetler yüksek oranda dağıtılmış sistemlerdir. Bu dağıtılmış sistemler genellikle düzgün bir şekilde geliştirmek, yönetmek ve bakımını yapmak için farklı bir beceri kümesi gerektirir. Ekibin başarılı olacak becerilere ve deneyime sahip olup olmadığını dikkatlice değerlendirin. Ekiplerinizin yeteneklerini geliştirmeleri için gereken zamana ve planlamaya izin verin.
Mikro hizmetler mimarisini ne zaman seçmelisiniz?
Bu arka plan bilgilerine dayanarak, mikro hizmet mimarisi hangi durumlar için en uygun?
- Yüksek yayın hızı gerektiren büyük uygulamalar.
- Yüksek oranda ölçeklenebilir olması gereken karmaşık uygulamalar.
- Zengin etki alanları veya birçok alt etki alanı olan uygulamalar.
- Küçük geliştirme ekiplerinden oluşan bir kuruluş.