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.
Sosyal haklar
Çeviklik. Mikro hizmetler bağımsız olarak dağıtıldığından, hata düzeltmelerinin ve özellik yayınlarının yönetimi 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 bu hata tüm yayın sürecini engelleyebilir. Yeni özellikler, bir hata düzeltmenin tümleştirilmesi, test edilmesi ve yayımlanması için bekletilebilir.
Küçük, odaklanmış takımlar. Bir mikro hizmet, tek bir özellik takımının oluşturabileceği, test edebileceği ve 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. Bir mikro hizmet uygulamasında eşdeğer monolitik uygulamadan daha fazla hareketli parça vardır. Her bir hizmet daha basittir ancak tüm sistem bir bütün olarak 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üzenlemek zor olabilir. Özellikle uygulama hızla gelişirken hizmet bağımlılıklarını test etmek de güç olabilir.
İdare eksikliği. Mikro hizmetleri oluşturmaya yönelik merkezi olmayan yaklaşımın avantajları vardır ancak aynı zamanda sorunlara yola açabilir. Uygulamanın bakımını yapmayı zorlaştıracak kadar fazla dil ve çerçeve kullanmak zorunda kalabilirsiniz. Takımların esnekliğini aşırı kısıtlamadan proje geneline yönelik bazı standartlar oluşturmak 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ında daha fazla iletişime yol açabilir. 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 bir mikro hizmet kendi veri kalıcılığından sorumludur. Sonuç olarak, veri tutarlılığını sağlamak zor olabilir. Mümkün olduğunda nihai tutarlılık yaklaşımını 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üğe kaydetme zor olabilir. Genellikle, günlüğe kaydetme tek bir kullanıcı işlemi için birden çok hizmet çağrısını bağıntılı hale getirmelidir.
Sürüm oluşturma. Hizmette yapılan güncelleştirmeler bu hizmete bağımlı diğer 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. Takımın başarılı olmak için gereken becerilere ve deneyime sahip olup olmadığını dikkatlice değerlendirin.
En iyi yöntemler
Hizmetleri iş etki alanı etrafında şekillendirin.
Her şeyi merkezi durumdan çıkarın. Hizmetleri tasarlamaktan ve oluşturmaktan ayrı takımlar sorumludur. Kod veya veri şemalarını paylaşmaktan kaçının.
Veri depolama, verilerin sahibi olan hizmete özel olmalıdır. Her bir hizmet ve veri türü için en iyi depolamayı kullanın.
Hizmetler iyi tasarlanmış API’ler üzerinden iletişim kurar. Uygulama ayrıntılarının sızmasını önleyin. API’lerin iç hizmet uygulamasının değil etki alanının modelini oluşturması gerekir.
Hizmetler arasında eşleştirme yapmaktan kaçının. Paylaşılan veritabanı şemaları ve katı iletişim protokolleri eşleştirmeye neden olabilir.
Kimlik doğrulaması ve SSL sonlandırma gibi çapraz kesme konuları için ağ geçidine yük boşaltın.
Etki alanı bilgilerini ağ geçidi dışında tutun. Ağ geçidi, istemci isteklerini iş kuralları veya etki alanı mantığı bilgileri olmadan işlemeli ve yönlendirmelidir. Aksi takdirde, ağ geçidi bir bağımlılık olur ve hizmetler arasında eşleştirmeye neden olabilir.
Hizmetlerin gevşek eşleştirme ve yüksek işlevsel uyuma sahip olması gerekir. Birlikte değiştirilme olasılığı olan işlevler birlikte paketlenmeli ve dağıtılmalıdır. Ayrı hizmetlerde bulunuyorlarsa, bir hizmette yapılan değişiklik diğer hizmetin de güncelleştirilmesini gerektireceğinden bu hizmetler sıkı bir şekilde eşleştirilmiş olur. İki hizmet arasında aşırı sık iletişim kurulması bu hizmetler arasında sıkı eşleştirme ve düşük uyum olduğunun belirtisi olabilir.
Hataları yalıtın. Bir hizmet içindeki hataların art arda oluşmasını önlemek için dayanıklılık stratejileri kullanın. Bkz . Dayanıklılık desenleri ve Güvenilir uygulamalar tasarlama.
Sonraki adımlar
Azure üzerinde bir mikro hizmetler mimarisi oluşturma hakkında ayrıntılı yönergeler için, bkz. Azure’da mikro hizmetler tasarlama, oluşturma ve çalıştırma.