Mikro hizmet mimarisi stili
Mikro hizmetler mimarisi küçük, otonom bir hizmetler koleksiyonundan oluşur. Her hizmet kendi içindedir ve sınırlanmış bir bağlam içinde tek bir iş özelliği uygulamalıdır. Sınırlanmış bağlam, işletme içindeki doğal bir bölümdür ve etki alanı modelinin bulunduğu açık bir sınır sağlar.
Mikro hizmetler nedir?
Mikro hizmetler küçük ve bağımsızdır ve gevşek bir şekilde eşlenmiştir. Küçük bir geliştirici takımı bir hizmet yazıp bakımını yapabilir.
Her hizmet küçük bir geliştirme ekibi tarafından yönetilebilen ayrı bir kod temelidir.
Hizmetler bağımsız olarak dağıtılabilir. Bir takım, tüm uygulamayı yeniden oluşturup yeniden dağıtmak zorunda kalmadan mevcut bir hizmeti güncelleştirebilir.
Hizmetler kendi verilerini veya dış durumlarını kalıcı hale getirmekten sorumludur. Bu, kalıcılığın ayrı bir veri katmanı tarafından işlendiği geleneksel modelden farklıdır.
Hizmetler iyi tanımlanmış API’leri kullanarak birbiriyle iletişim kurar. Her bir hizmetin iç uygulama ayrıntıları diğer hizmetlerden gizlidir.
Polyglot programlamayı destekler. Örneğin, hizmetlerin aynı teknoloji yığınını, kitaplıkları veya çerçeveleri paylaşması gerekmez.
Tipik bir mikro hizmet mimarisinde hizmetlerin yanı sıra bazı diğer bileşenler bulunur:
Dağıtım/düzenleme. Bu bileşen, hizmetleri düğümlere yerleştirmekten, hataları belirlemekten, düğümler arasında hizmetleri yeniden dengelemekten ve benzeri görevlerden sorumludur. Genellikle bu bileşen, özel derlenmiş bir teknoloji değil, Kubernetes gibi hazır bir teknolojidir.
API Ağ Geçidi. API ağ geçidi, istemciler için giriş noktasıdır. İstemciler hizmetleri doğrudan çağırmak yerine, çağrıyı arka uçta uygun hizmetlere ileten API ağ geçidini çağırırlar.
Bir API ağ geçidi kullanmanın avantajları aşağıdakileri içerir:
İstemcileri hizmetlerden ayırır. Tüm istemcilerin güncelleştirilmesine gerek kalmadan hizmetler için sürüm oluşturulabilir veya hizmetler yeniden düzenlenebilir.
Hizmetler AMQP gibi web ile kullanımı kolay olmayan mesajlaşma protokollerini kullanabilir.
API Ağ Geçidi kimlik doğrulaması, günlüğe kaydetme, SSL sonlandırma ve yük dengeleme gibi diğer çapraz kesme işlevlerini gerçekleştirebilir.
Azaltma, önbelleğe alma, dönüştürme veya doğrulama gibi hazır ilkeler.
Fayda -ları
Çeviklik. Mikro hizmetler bağımsız olarak dağıtıldığından, hata düzeltmelerini ve özellik sürümlerini yönetmek daha kolaydır. Bir hizmeti, uygulamayı tamamen yeniden dağıtmadan güncelleştirebilir ve bir sorun olduğunda güncelleştirmeyi geri alabilirsiniz. Birçok geleneksel uygulamada, uygulamanın bir bölümünde bir hata bulunursa, yayın işleminin tamamını engelleyebilir. Yeni özellikler, bir hata düzeltmenin tümleştirilmesi, test edilmesi ve yayımlanması için bekletilebilir.
Küçük, odaklanmış takımlar. Mikro hizmet, tek bir özellik takımının oluşturabileceği, test edip dağıtabileceği kadar küçük olmalıdır. Takım boyutunun küçük olması çevikliği artırır. Büyük takımlarda iletişimin daha yavaş, yönetim ek yükünün fazla ve çevikliğin az olması genellikle daha az üretken olmalarına neden olur.
Küçük kod tabanı. Monolitik bir uygulamada, zaman içinde kod bağımlılıklarının karmaşık hale gelmesi eğilimi vardır. Yeni bir özellik eklemek için birçok yerde koda dokunmak gerekir. Ortak kod veya veri deposunun kullanılmadığı mikro hizmet mimarisinde bağımlılıklar en aza indirilir ve bu da yeni özellik eklenmesini kolaylaştırır.
Teknoloji harmanı. Takımlar teknoloji yığınlarının bir karışımını kullanarak hizmetleri için en uygun teknolojiyi seçebilir.
Hata yalıtımı. Tek bir mikro hizmet kullanılamaz duruma gelirse, herhangi bir yukarı akış mikro hizmeti hataları doğru şekilde işleyecek şekilde tasarlandığı sürece uygulamanın tamamını kesintiye uğratmaz. Örneğin, Devre Kesici düzenini uygulayabilir veya mikro hizmetlerin zaman uyumsuz mesajlaşma düzenlerini kullanarak birbirleriyle iletişim kurabilmesi için çözümünüzü tasarlayabilirsiniz.
Ölçeklenebilirlik. Hizmetler birbirinden bağımsız olarak ölçeklendirilebilir ve bu sayede, daha fazla kaynak gerektiren alt sistemleri uygulamanın tamamını ölçeklendirmenize gerek kalmadan ölçeklendirebilirsiniz. Kubernetes gibi bir düzenleyici kullanarak, kaynakların daha verimli kullanılmasını sağlayan daha yüksek bir hizmet yoğunluğu tek bir konakta paketleyebilirsiniz.
Veri yalıtımı. Tek bir mikro hizmet etkilendiğinden, şema güncelleştirmeleri gerçekleştirmek çok daha kolaydır. Monolitik bir uygulamada, şema güncelleştirmeleri çok zor olabilir çünkü uygulamanın farklı bölümleri aynı verilere dokunarak şemada herhangi bir değişiklik yapılması riskli olabilir.
Zorluklar
Mikro hizmetlerin avantajları ücretsiz olarak sunulmaz. Mikro hizmet mimarisine başlamadan önce göz önünde bulundurmanız gereken bazı güçlükler aşağıda verilmiştir.
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.
Geliştirme ve test. Diğer bağımlı hizmetlere dayalı küçük bir hizmet yazmak, geleneksel monolitik veya katmanlı bir uygulama yazmaktan farklı bir yaklaşım gerektirir. Mevcut araçlar her zaman hizmet bağımlılıkları ile birlikte çalışmaya uygun olmayabilir. 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 güç olabilir.
İ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. Bu özellikle günlüğe kaydetme gibi çapraz kesme işlevleri için geçerlidir.
Ağ tıkanıklığı ve gecikmesi. Çok sayıda küçük, ayrıntılı hizmetin kullanılması, hizmetler arası iletişimin daha fazla kullanılmasına neden olabilir. Ayrıca, hizmet bağımlılıkları zinciri çok uzun olursa (A hizmeti B hizmetini, B hizmeti C hizmetini vb. çağırıyorsa), ek gecikme sorunlara yol açabilir. API’leri dikkatli bir şekilde tasarlamanız gerekir. Aşırı geveze API'lerden kaçının, serileştirme biçimlerini düşünün ve kuyruk tabanlı yük dengeleme gibi zaman uyumsuz iletişim desenlerinin kullanılacağı yerleri arayın.
Veri bütünlüğü. Her mikro hizmet kendi veri kalıcılığından sorumludur. Sonuç olarak, birden çok hizmette veri tutarlılığı zor olabilir. Farklı hizmetler verileri farklı zamanlarda, farklı teknoloji kullanarak ve potansiyel olarak farklı başarı düzeylerinde kalıcı hale getirmektedir. Yeni veya değiştirilmiş tarihi kalıcı hale getiren birden fazla mikro hizmet söz konusu olduğunda, veri değişikliğinin tamamının ACID işlemi olarak kabul edilmesi pek olası değildir. Bunun yerine, teknik BASE (Temel Olarak Kullanılabilir, Geçici durum ve Nihai tutarlılık) ile daha uyumlu olur. Mümkün olduğunda nihai tutarlılığı benimseyin.
Yönetim. Mikro hizmetleri başarılı bir şekilde kullanmak için olgun bir DevOps kültürü gerekir. Hizmetler arasında bağıntılı günlük kaydı zorlayıcı olabilir. Genellikle, günlüğe kaydetmenin tek bir kullanıcı işlemi için birden çok hizmet çağrısıyla bağıntılı olması gerekir.
Versiyonlama. Bir hizmet güncelleştirmeleri, hizmete bağlı hizmetleri bozmamalıdır. Herhangi bir zamanda birden çok hizmet güncelleştirilebilir, bu nedenle dikkatli bir tasarım olmadan geriye veya ileriye dönük uyumlulukla ilgili sorunlarla karşılaşabilirsiniz.
Beceriler. Mikro hizmetler yüksek oranda dağıtılmış sistemlerdir. Ekibin başarılı olacak becerilere ve deneyime sahip olup olmadığını dikkatlice değerlendirin.
En iyi yöntemler
İş etki alanı çevresinde hizmetleri modelleme.
Her şeyi merkeziyetsizleştirin. Hizmetleri tasarlamak ve oluşturmak tek tek ekipler tarafından sorumludur. Kod veya veri şemalarını paylaşmaktan kaçının.
Veri depolama, verilerin sahibi olan hizmete özel olmalıdır. Her hizmet ve veri türü için en iyi depolama alanını kullanın.
Hizmetler iyi tasarlanmış API'ler aracılığıyla iletişim kurar. Uygulama ayrıntılarını sızdırmaktan kaçının. API'ler hizmetin iç uygulamasını değil etki alanını modellemelidir.
Hizmetler arasında bağlantı kullanmaktan kaçının. Bağlantının nedenleri arasında paylaşılan veritabanı şemaları ve katı iletişim protokolleri yer alır.
Kimlik doğrulaması ve SSL sonlandırma gibi çapraz kesme sorunlarını ağ geçidine boşaltın.
Etki alanı bilgilerini ağ geçidinden uzak tutun. Ağ geçidi, iş kuralları veya etki alanı mantığı hakkında herhangi bir bilgi olmadan istemci isteklerini işlemeli ve yönlendirmelidir. Aksi takdirde ağ geçidi bir bağımlılık haline gelir ve hizmetler arasında bağlamaya neden olabilir.
Hizmetlerin gevşek kavraması ve yüksek işlevsel uyumu olmalıdır. Birlikte değişme olasılığı olan işlevler birlikte paketlenmeli ve dağıtılmalıdır. Ayrı hizmetlerde yer alırsa, bir hizmetteki bir değişiklik diğer hizmetin güncelleştirilmesini gerektireceği için bu hizmetler sıkı bir şekilde birbirine bağlanmış olur. İki hizmet arasındaki aşırı gevendekli iletişim, sıkı bağlantı ve düşük uyum belirtisi olabilir.
Hataları yalıtın. Bir hizmet içindeki hataların basamaklı olmasını önlemek için dayanıklılık stratejilerini kullanın. Bkz. Dayanıklılık desenleri ve Güvenilir uygulamalar tasarlama.
Sonraki Adımlar
Azure'da mikro hizmet mimarisi oluşturma hakkında ayrıntılı yönergeler için bkz. Azure'da mikro hizmetler tasarlama, oluşturma ve çalıştırma.