Aracılığıyla paylaş

Mikro hizmetler mimarisi stili

Mikro hizmetler dayanıklı, yüksek oranda ölçeklenebilen, bağımsız bir şekilde dağıtılabilen ve hızla geliştirilebilen uygulamalar oluşturmak için popüler bir mimari stilidir. Başarılı bir mikro hizmet mimarisi oluşturmak için temel bir fikir değişikliği gerekir. Bir uygulamayı daha küçük hizmetlere ayırmanın ötesine geçer. Ayrıca sistemlerin nasıl tasarlandığını, dağıtılıp çalıştırılma şeklini de yeniden düşünmeniz gerekir.

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 mimarisi stilinin mantıksal diyagramı.

Mikro hizmetler nedir?

Mikro hizmetler, tek bir küçük geliştirici ekibinin yazıp koruyabileceği küçük, bağımsız ve gevşek bir şekilde bağlanmış bileşenlerdir. Her hizmet ayrı bir kod tabanı olarak yönetilir ve bu da küçük bir ekibin bunu verimli bir şekilde işlemesini sağlar. Hizmetler bağımsız olarak dağıtılabildiği için ekipler, uygulamanın tamamını yeniden oluşturmadan veya yeniden dağıtmadan mevcut hizmetleri güncelleştirebilir. Merkezi veri katmanına sahip geleneksel modellerden farklı olarak mikro hizmetler kendi verilerini veya dış durumlarını kalıcı hale getirmektedir. İyi tanımlanmış API'ler aracılığıyla iletişim kurarlar ve bu da iç uygulamaları diğer hizmetlerden gizler. Bu mimari ayrıca çok teknolojili programlamayı da destekler; bu da hizmetlerin aynı teknoloji yığınını, kitaplıkları veya çerçeveleri paylaşmasına gerek olmadığı anlamına gelir.

Bileşenler

Hizmetlerin kendilerine ek olarak, diğer bileşenler tipik bir mikro hizmet mimarisinde görünür:

  • Yönetim veya düzenleme: Bu yönetim bileşeni mikro hizmetleri düzenlemeyi işler. Hizmetleri düğümler arasında zamanlar ve dağıtır, hataları algılar, hatalardan sonra kurtarma işlemi yapar ve talebe bağlı olarak otomatik ölçeklendirmeyi etkinleştirir. Kubernetes gibi bir kapsayıcı düzenleme platformu genellikle bu işlevi sağlar. Bulutta yerel ortamlarda, Azure Container Apps gibi çözümler yönetilen düzenleme ve yerleşik ölçeklendirme sağlar. Bu araçlar dağıtım karmaşıklığını ve operasyonel ek yükü azaltır.

  • API ağ geçidi: API ağ geçidi, istemciler için giriş noktası görevi görür. İstemciler, hizmetleri doğrudan çağırmak yerine API ağ geçidine istek gönderir. Ağ geçidi bu istekleri uygun arka uç hizmetlerine iletir. Ayrıca kimlik doğrulaması, kaydedilmesi ve yük dengeleme gibi genel sorunları da ele alır. Bulutta yerel mikro hizmet mimarilerinde, Envoy ve Nginx gibi basit hizmet proxy'leri hizmetten hizmete iç iletişimi destekler. Doğu-batı trafiği olarak bilinen bu tür iç trafik, gelişmiş yönlendirme ve trafik denetimi sağlar.

  • İleti odaklı ara yazılım: Apache Kafka ve Azure Service Bus gibi mesajlaşma platformları, gevşek bağlamayı teşvik ederek ve yüksek ölçeklenebilirliği destekleyerek mikro hizmetlerde zaman uyumsuz iletişim sağlar. Olay odaklı mimarilerin temelini oluştururlar. Bu yaklaşım, hizmetlerin olaylara gerçek zamanlı olarak tepki vermesine ve zaman uyumsuz mesajlaşma aracılığıyla iletişim kurmasına olanak tanır.

  • Gözlemlenebilirlik: Etkili bir gözlemleme stratejisi, ekiplerin sistem güvenilirliğini korumasına ve sorunları hızla çözmelerine yardımcı olur. Merkezi günlüğe kaydetme, daha kolay tanılamayı desteklemek için günlükleri bir araya getirir. OpenTelemetry gibi uygulama performansı izleme aracıları ve çerçeveleriyle gerçek zamanlı izleme, sistem durumu ve performansı hakkında görünürlük sağlar. Dağıtılmış izleme, istekleri hizmet sınırları arasında izler. Ekiplerin performans sorunlarını bulmasına ve performansı geliştirmelerine yardımcı olur.

  • Veri yönetimi: İyi tasarlanmış bir veritabanı mimarisi, özerkliği ve ölçeklenebilirliği destekler. Mikro hizmetler genellikle her hizmetin özel ihtiyaçlarına göre SQL veya NoSQL gibi farklı veritabanı türlerini seçerek çok teknolojili kalıcılığı kullanır. Bu yaklaşım, etki alanı odaklı tasarım (DDD) ve sınırlanmış bağlam fikriyle uyumlu hale gelir. Her hizmetin kendi verileri ve şeması vardır. Bu sahiplik, hizmetler arası bağımlılıkları azaltır ve hizmetlerin bağımsız olarak gelişmesine olanak tanır. Bu merkezi olmayan model esnekliği, performansı ve sistem dayanıklılığını artırır.

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 uygulamanın tamamını yeniden dağıtmadan güncelleştirebilir ve bir sorun olursa güncelleştirmeyi geri alabilirsiniz. Birçok geleneksel uygulamada, uygulamanın bir bölümünde bir hata bulursanız, yayın işleminin tamamını engelleyebilir. Örneğin, bir hata düzeltmesini tümleştirmeniz, test etmeniz ve yayımlamanız gerekiyorsa bir hata yeni özellikleri geciktirebilir.

  • Küçük, odaklanmış ekipler: 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. İletişim daha yavaş olduğundan, yönetim ek yükü arttığından ve çeviklik azaldığından büyük takımlar daha az üretken olma eğilimindedir.

  • Küçük kod tabanı: Monolitik bir uygulamada kod bağımlılıkları genellikle zaman içinde karışabilir. Yeni bir özellik eklemek için kod tabanının birçok bölümünde değişiklik yapılması gerekebilir. Mikro hizmetler mimarisi, kod veya veri depolarını paylaşmayarak bu sorunu önler. Bu yaklaşım bağımlılıkları en aza indirir ve yeni özelliklerin tanıtılmasında kolaylık sağlar.

  • Teknolojilerin karışımı: Ekipler, uygun teknoloji yığınlarının bir karışımını kullanarak kendi hizmetine 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 bağımsız olarak ölçeklendirilebilir. Bu yaklaşım, uygulamanın tamamını genişletmeden daha fazla kaynak gerektiren alt sistemlerin ölçeğini genişletmenize olanak tanır. Kubernetes gibi bir düzenleyiciyi kullanarak tek bir konağa daha yüksek bir hizmet yoğunluğu ekleyerek daha verimli kaynak kullanımına olanak tanır.

  • Veri yalıtımı: Yalnızca bir mikro hizmet etkilendiği için mikro hizmetler mimarisinde şemayı güncelleştirmek daha kolaydır. Buna karşılık, birden çok bileşen genellikle aynı verilerle etkileşime geçeceğinden monolitik uygulamalar şema değişikliklerini karmaşıklaştırabilir. Bu paylaşılan erişim herhangi bir değişikliği riskli hale getirir.

Zorluklar

Mikro hizmetlerin avantajları, takaslarla birlikte gelir. Mikro hizmet mimarisi oluşturmadan önce aşağıdaki zorlukları göz önünde bulundurun:

  • 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. Uygulamanızı tasarlarken hizmet bulma, veri tutarlılığı, işlem yönetimi ve hizmetler arası iletişim gibi zorlukları göz önünde bulundurduğunuzdan emin olun.

  • 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ı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 sorunlarla da sonuçlanabilir. 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 yöntem özellikle loglama gibi kapsayıcı işlevler 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. Ayrıca, hizmet bağımlılıkları zinciri çok uzun olursa (A hizmeti B'yi, B hizmeti C'yi çağırırsa), ek gecikme süresi sorun haline gelebilir. API'leri dikkatle tasarlamanız gerekir. Aşırı geveze API'lerden kaçının, serileştirme biçimlerini düşünün ve Queue-Based Yük Dengeleme deseni gibi zaman uyumsuz 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, 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ş verileri kalıcı hale getiren birden fazla mikro hizmet söz konusu olduğunda, veri değişikliğinin tamamının atomik, tutarlı, yalıtılmış ve dayanıklı (ACID) bir işlem olarak kabul edilmesi pek olası değildir. Bunun yerine, teknik Temel Olarak Kullanılabilir, Geçici Durum, Nihai Tutarlılık (BASE) ile daha uyumlu olur. Mümkün olduğunda nihai tutarlılığı benimseyin.

  • Yönetim: Başarılı bir mikro hizmet mimarisi olgun bir DevOps kültürü gerektirir. 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, 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. Ekibin başarılı olacak becerilere ve deneyime sahip olup olmadığını dikkatlice değerlendirin.

En iyi yöntemler

  • İş etki alanı çevresinde hizmetleri modelleme. Sınırlanmış bağlamları tanımlamak ve açık hizmet sınırlarını tanımlamak için DDD kullanın. Karmaşıklığı artırabilecek ve performansı düşürebilecek aşırı ayrıntılı hizmetler oluşturmaktan kaçının.

  • Her şeyi merkeziyetsizleştirin. Hizmetleri uçtan uca tasarlama ve inşa etme sorumluluğu, bireysel ekiplerin üzerindedir. Kod veya veri şemalarını paylaşmaktan kaçının.

  • Kullandığınız dil ve çerçeve sayısını sınırlayarak teknoloji seçeneklerinizi standartlaştırın. Günlüğe kaydetme, izleme ve dağıtım için platform çapında standartlar belirleyin.

  • 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.

  • Zaman uyumsuz iletişim için mesajlaşma çerçevelerini kullanın. Özel mesajlaşma mantığı oluşturmak yerine yönlendirme, yeniden denemeler, dayanıklılık ve iş akışı desenlerini işlemek için MassTransit veya NServiceBus gibi araçları benimseyin. Çerçeveler, dağıtılmış sistem karmaşıklığını azaltmaya, güvenilirliği artırmaya ve ileti temelli mikro hizmetler uygularken sık karşılaşılan tuzaklardan kaçınmaya yardımcı olur.

  • Hizmet-hizmet şifrelemesi için karşılıklı Aktarım Katmanı Güvenliği (mTLS) kullanarak güvenliği geliştirin. Rol tabanlı erişim denetimi uygulayın ve ilkeleri zorunlu kılmak için API ağ geçitlerini kullanın.

  • Kimlik doğrulaması ve Güvenli Yuva Katmanı sonlandırma gibi çapraz kesme sorunlarını ağ geçidine boşaltın. Dapr gibi servis mesh'leri ve framework'leri, mTLS kimlik doğrulaması ve dayanıklılık gibi sık karşılaşılan ortak çapraz sorunlara da çözüm sunabilir.

  • 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 gerektirdiğinden bu hizmetler sıkı bir şekilde birbirine bağlanmış olur. İki hizmet arasındaki aşırı konuşkan iletişim, sıkı bağlantı ve düşük uyum belirtisi olabilir.

  • Test ve dağıtımı otomatikleştirmek için sürekli tümleştirme ve sürekli dağıtım (CI/CD) işlem hatlarını kullanın. Hizmetleri bağımsız olarak dağıtın ve dağıtımın sağlık durumunu izleyin.

  • Hataları yalıtın. Bir hizmet içindeki hataların basamaklı olmasını önlemek için dayanıklılık stratejilerini kullanın. Daha fazla bilgi için bkz . Dayanıklılık desenleri ve Güvenilir uygulamalar tasarlama.

  • Mikro hizmet mimarinizin ve bağımlılıklarının dayanıklılığını test etmek için kaos mühendisliğini kullanın. Sistemin kısmi hataları işleme biçimini değerlendirin ve geliştirin.

  • Gözlemlenebilirliği sağlamak için merkezi günlük kaydı, dağıtılmış izleme (OpenTelemetry) ve ölçüm koleksiyonu uygulayın.

Mikro hizmetler için antipatternler

Mikro hizmetleri tasarlayıp uyguladığınızda, bu mimari stilin avantajlarını zedeleyebilecek belirli tuzaklar sık sık ortaya çıkar. Bu kötü modellerin tanınması, ekiplerin yüksek maliyetli hatalardan kaçınmalarına ve daha dayanıklı, sürdürülebilir sistemler oluşturmalarına yardımcı olur. Aşağıdaki kötü modellerden kaçının:

  • mikro hizmetlerin iş etki alanı hakkında ayrıntılı bilgi olmadan uygulanması, hizmet sınırlarının kötü hizalanmasına neden olur ve amaçlanan avantajları baltalar.

  • Geçmiş veya gelecekteki olaylara bağlı olayları tasarlamak, atomik ve bağımsız mesajlaşma ilkesini ihlal eder. Bu bağımlılık tüketicileri beklemeye zorlar ve sistem güvenilirliğini azaltır.

  • Veritabanı varlıklarını olaylar olarak kullanmak iç hizmet ayrıntılarını ortaya çıkarır ve genellikle doğru iş amacını iletmez ve bu da sıkı bir şekilde bağlanmış ve belirsiz tümleştirmelere yol açar.

  • Her ne pahasına olursa olsun veri yinelemesini önlemek bir kötü modeldir. Yerel kopyaları korumak için materyalize edilmiş görünümler gibi desenlerin kullanılması hizmet özerkliğini artırır ve hizmetler arası bağımlılıkları azaltır.

  • Genel olayları kullanmak, tüketicileri iletileri yorumlamaya ve filtrelemeye zorlar. Bu yaklaşım gereksiz karmaşıklık ekler ve olay odaklı iletişimdeki netliği azaltır.

  • Mikro hizmetler arasında ortak kitaplıkların veya bağımlılıkların paylaşılması, değişiklikleri riskli ve yaygın hale getiren ve bağımsız hizmetler ilkesine aykırı olan sıkı bir bağlantı oluşturur.

  • Mikro hizmetleri doğrudan tüketicilere ifşa etmek, sıkı bağlama, ölçeklenebilirlik sorunları ve güvenlik riskleriyle sonuçlanabilir. API ağ geçidi kullanmak temiz, yönetilebilir ve güvenli bir giriş noktası sağlar.

  • Yapılandırma değerlerini mikro hizmetlerde tutmak, bunları belirli ortamlarla sıkı bir şekilde birleştirir ve bu da dağıtımları zorlaştırır. Ancak yapılandırmanın dışlaştırılması esnekliği ve ortam taşınabilirliğini teşvik eder.

  • Belirteç doğrulaması gibi güvenlik mantığını doğrudan mikro hizmetlerin içine eklemek, bunların kodunu ve bakımını karmaşıklaştırır. Alternatif olarak, güvenliği ayrılmış bileşenlere boşaltmak, hizmetlerin odaklanmış ve daha temiz olmasını sağlar.

  • Yaygın mikro hizmet görevlerini soyutlamamak yinelenen, hataya açık koda neden olur ve esnekliği sınırlar. Alternatif olarak, Dapr gibi soyutlama çerçevelerinin kullanılması, iş mantığını altyapı sorunlarından ayrıştırarak geliştirmeyi kolaylaştırır.

Mikro hizmetler mimarisi oluşturma

Aşağıdaki makalelerde mikro hizmet mimarisi tasarlama, oluşturma ve çalıştırmaya yönelik yapılandırılmış bir yaklaşım sunulur.

Etki alanı analizini kullanın: Mikro hizmetler tasarlarken sık karşılaşılan tuzaklardan kaçınmak için, mikro hizmet sınırlarınızı tanımlamak için etki alanı analizini kullanın. Aşağıdaki adımları yapın:

  1. Mikro hizmetleri modellemek için etki alanı analizi kullanın.
  2. Mikro hizmetleri tasarlamak için taktiksel DDD kullanın.
  3. Mikro hizmet sınırlarını tanımlayın.

Hizmetleri tasarla: Mikro hizmetler, uygulamaları tasarlamak ve oluşturmak için merkezi olmayan ve çevik bir yaklaşım gerektirir. Daha fazla bilgi için bkz . Mikro hizmet mimarisi tasarlama.

Üretimde çalışma: Mikro hizmet mimarileri dağıtıldığından, dağıtım ve izleme için sağlam işlemlere sahip olmanız gerekir.

  • Last updated on