Mikro hizmetler mimari stili
Mikro hizmetler mimarisi küçük, otonom bir hizmetler koleksiyonundan oluşur. Her hizmet kendi içindedir ve sınırlayıcı bir bağlamda tek bir iş özelliği uygulamalı. Sınırlayıcı bağlam, bir işletme içinde doğal bir bölmedir ve etki alanı modelinin mevcut olduğ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.
Çokglot programlamayı destekler. Örneğin hizmetlerin aynı teknoloji yığınını, kitaplıkları veya çerçeveleri paylaşması gerekmektedir.
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 Gateway. 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.
Avantajlar
Ç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üzeltmesinin tümleştirilmesi, sınanması 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, kod bağımlılıkları zaman içinde karışıklığa yol akar. Yeni bir özellik eklemek için birçok farklı 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.
Teknolojilerin karışımı. Takımlar teknoloji yığınlarının bir karışımını kullanarak hizmetleri için en uygun teknolojiyi seçebilir.
Hata yalıtımı. Yukarı akış mikro hizmetleri hataları doğru işleyecek şekilde (örneğin, bağlantı hattı kesme uygulayarak) tasarlandığı sürece, bir mikro hizmet kullanılamaz hale gelirse uygulamanın tamamı kesintiye uğramaz.
Ö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 veya Service Fabric gibi bir düzenleyici kullanarak, hizmetleri daha yoğun bir şekilde tek bir konağa sığdırabilir ve kaynak kullanımını daha verimli bir hale getirebilirsiniz.
Veri yalıtımı. Tek bir mikro hizmet etkilendiğinden, şema güncelleştirmeleri gerçekleştirmek çok daha kolaydır. Tek parçalı bir uygulamada, uygulamanın farklı bölümleri aynı verilere bağlanabileceğinden şemada değişiklik yapılması riskli olabilir ve şema güncelleştirmeleri zorlaşabilir.
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 testetme. Diğer bağımlı hizmetleri kullanan küçük bir hizmet yazmak, geleneksel tek parçalı veya katmanlı bir uygulama yazmaktan farklı bir yaklaşım gerektirir. Mevcut araçlar hizmet bağımlılıkları ile birlikte çalışmak için tasarlanmış 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 gecikme süresi. Ç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ı sohbet eden API'lerden kaçının, serileştirme biçimlerini göz önünde bulundurun ve kuyruk tabanlı yük dengeleme gibi zaman uyumsuz iletişim desenlerini kullanabileceğiniz yerleri arama.
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.
Beceri kümesi. 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 veGü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.