Aracılığıyla paylaş


Mikro hizmetlerde esneklik ve yüksek kullanılabilirlik

İpucu

Bu içerik, .NET Docs'ta veya çevrimdışı olarak okunabilen ücretsiz indirilebilir bir PDF olarak sağlanan Kapsayıcılı .NET Uygulamaları için .NET Mikro Hizmet Mimarisi e-Kitabı'ndan bir alıntıdır.

.NET Microservices Architecture for Containerized .NET Applications eBook cover thumbnail.

Beklenmeyen hatalarla başa çıkmak, özellikle dağıtılmış bir sistemde çözülmesi en zor sorunlardan biridir. Geliştiricilerin yazdığı kodun büyük bölümü özel durumların işlenmesini içerir ve burası aynı zamanda test için en fazla zamanın harcandığı yerdir. Sorun, hataları işlemek için kod yazmaktan daha önemlidir. Mikro hizmetin çalıştığı makine başarısız olduğunda ne olur? Yalnızca bu mikro hizmet hatasını (kendi başına zor bir sorun) algılamanız değil, aynı zamanda mikro hizmetinizi yeniden başlatmak için bir şeye de ihtiyacınız vardır.

Bir mikro hizmetin hatalara dayanıklı olması ve kullanılabilirlik için başka bir makinede sık sık yeniden başlatılabilmesi gerekir. Bu dayanıklılık, mikro hizmet adına kaydedilen duruma, mikro hizmetin bu durumu kurtarabileceği duruma ve mikro hizmetin başarıyla yeniden başlatılıp başlatılamayacağına da bağlıdır. Başka bir deyişle, işlem özelliğinde dayanıklılık (işlem her zaman yeniden başlatılabilir) ve durum veya verilerde dayanıklılık (veri kaybı yoktur ve veriler tutarlı kalır) olmalıdır.

Dayanıklılık sorunları, uygulama yükseltmesi sırasında hata oluşması gibi diğer senaryolar sırasında birleştirilmiştir. Dağıtım sistemiyle çalışan mikro hizmetin, tutarlı bir durum korumak için daha yeni bir sürüme geçmeye devam edip etmeyeceğini veya bunun yerine önceki bir sürüme geri dönüp dönemeyeceğini belirlemesi gerekir. İlerlemeye devam etmek için yeterli sayıda makinenin kullanılabilir olup olmadığı ve mikro hizmetin önceki sürümlerini kurtarma gibi soruların dikkate alınması gerekir. Bu yaklaşım, genel uygulamanın ve düzenleyicinin bu kararları vermesini sağlamak için mikro hizmetin sistem durumu bilgilerini yayması gerekir.

Ayrıca dayanıklılık, bulut tabanlı sistemlerin nasıl davranması gerektiğiyle ilgilidir. Belirtildiği gibi, bulut tabanlı bir sistem hataları benimsemeli ve bunları otomatik olarak kurtarmaya çalışmalıdır. Örneğin, ağ veya kapsayıcı hataları durumunda, istemci uygulamalarının veya istemci hizmetlerinin iletileri göndermeyi yeniden deneme veya istekleri yeniden deneme stratejisi olmalıdır çünkü çoğu durumda buluttaki hatalar kısmidir. Bu kılavuzdaki Dayanıklı Uygulamaları Uygulama bölümü, kısmi hatanın nasıl işleneceğini ele alır. Bu konu ele almak için çok çeşitli ilkeler sunan Polly gibi kitaplıkları kullanarak .NET'te üstel geri alma veya Devre Kesici düzeni ile yeniden denemeler gibi teknikleri açıklar.

Mikro hizmetlerde sistem durumu yönetimi ve tanılama

Belirgin görünebilir ve genellikle göz ardı edilir, ancak mikro hizmetin sistem durumunu ve tanılamasını bildirmesi gerekir. Aksi takdirde operasyon perspektifinden çok az içgörü elde ederiz. Tanılama olaylarını bir dizi bağımsız hizmet arasında ilişkilendirmek ve olay sırasını anlamlı hale getirmek için makine saati dengesizlikleriyle ilgilenmek zordur. Üzerinde anlaşmaya varılan protokoller ve veri biçimleri üzerinden bir mikro hizmetle etkileşimde bulunmanızla aynı şekilde, sorgulama ve görüntüleme için bir olay deposunda son bu hale gelen sistem durumunu ve tanılama olaylarını günlüğe kaydetme konusunda standartlaştırmaya ihtiyaç vardır. Mikro hizmetler yaklaşımında, farklı ekiplerin tek bir günlüğe kaydetme biçimi üzerinde anlaşmaları önemlidir. Uygulamada tanılama olaylarını görüntülemek için tutarlı bir yaklaşım olması gerekir.

Sistem durumu denetimleri

Sistem durumu tanılamadan farklıdır. Sistem durumu, mikro hizmetin uygun eylemleri gerçekleştirmesi için geçerli durumunu raporlamasıyla ilgili. Kullanılabilirliği korumak için yükseltme ve dağıtım mekanizmalarıyla çalışmak iyi bir örnektir. İşlem kilitlenmesi veya makinenin yeniden başlatılması nedeniyle bir hizmet şu anda iyi durumda olmasa da, hizmet hala çalışır durumda olabilir. İhtiyacınız olan son şey, yükseltme yaparak bunu daha da kötü hale getirmektir. En iyi yaklaşım, önce bir araştırma yapmak veya mikro hizmetin kurtarılması için zaman vermektir. Mikro hizmetten gelen sağlık olayları bilinçli kararlar almamıza ve aslında kendi kendini iyileştirici hizmetler oluşturmamıza yardımcı olur.

Bu kılavuzun ASP.NET Core hizmetlerinde sistem durumu denetimlerini uygulama bölümünde, uygun eylemleri gerçekleştirmek üzere durumlarını bir izleme hizmetine bildirebilmeleri için mikro hizmetlerinizde yeni bir ASP.NET HealthChecks kitaplığının nasıl kullanılacağını açıklıyoruz.

Ayrıca GitHub'da ve NuGet paketi olarak kullanılabilen AspNetCore.Diagnostics.HealthChecks adlı mükemmel bir açık kaynak kitaplığı kullanma seçeneğiniz de vardır. Bu kitaplık ayrıca sistem durumu denetimleri de yapar ve iki tür denetimi işler:

  • Canlılık: Mikro hizmetin etkin olup olmadığını, yani istekleri kabul edip yanıt veremeyeceğini denetler.
  • Hazır olma: Mikro hizmetin bağımlılıklarının (Veritabanı, kuyruk hizmetleri vb.) kendilerinin hazır olup olmadığını denetler, böylece mikro hizmet yapması gerekenleri yapabilir.

Tanılama ve günlük olay akışlarını kullanma

Günlükler, özel durumlar, uyarılar ve basit bilgilendirme iletileri de dahil olmak üzere bir uygulamanın veya hizmetin nasıl çalıştığı hakkında bilgi sağlar. Genellikle her günlük olay başına bir satır içeren bir metin biçimindedir, ancak özel durumlar genellikle yığın izlemesini birden çok satırda da gösterir.

Monolitik sunucu tabanlı uygulamalarda, günlükleri diskteki bir dosyaya (logfile) yazabilir ve ardından herhangi bir araçla analiz edebilirsiniz. Uygulama yürütme sabit bir sunucu veya VM ile sınırlı olduğundan, genellikle olayların akışını analiz etmek çok karmaşık değildir. Ancak, bir düzenleyici kümesindeki birçok düğümde birden çok hizmetin yürütüldüğü dağıtılmış bir uygulamada, dağıtılmış olayları bağıntılı hale getirmek bir zorluktur.

Mikro hizmet tabanlı bir uygulama, olayların veya günlük dosyalarının çıkış akışını tek başına depolamayı denememeli ve hatta olayların merkezi bir yere yönlendirilmelerini yönetmeye çalışmamalıdır. Saydam olmalıdır, yani her işlem yalnızca olay akışını, altında çalıştığı yürütme ortamı altyapısı tarafından toplanacak standart bir çıkışa yazmalıdır. Bu olay akışı yönlendiricilerine örnek olarak , birden çok kaynaktan olay akışlarını toplayan ve çıkış sistemlerinde yayımlayan Microsoft.Diagnostic.EventFlow örnek olarak verilmiştir. Bunlar, geliştirme ortamı veya Azure İzleyici ve Azure Tanılama gibi bulut sistemleri için basit standart çıkışı içerebilir. Ayrıca Splunk gibi günlükleri gerçek zamanlı olarak bile arayabilir, uyarı verebilir, raporlayabilir ve izleyebilir iyi üçüncü taraf günlük analizi platformları ve araçları vardır.

Sistem durumu ve tanılama bilgilerini yöneten düzenleyiciler

Mikro hizmet tabanlı bir uygulama oluşturduğunuzda karmaşıklık ile ilgilenmeniz gerekir. Elbette tek bir mikro hizmetle ilgilenmek kolaydır, ancak onlarca veya yüzlerce tür ve binlerce mikro hizmet örneği karmaşık bir sorundur. Bu yalnızca mikro hizmet mimarinizi oluşturmakla ilgili değildir; kararlı ve uyumlu bir sisteme sahip olmak istiyorsanız yüksek kullanılabilirlik, adreslenebilirlik, dayanıklılık, sistem durumu ve tanılamaya da ihtiyacınız vardır.

Diagram of clusters supplying a support platform for microservices.

Şekil 4-22. Mikro Hizmet Platformu, bir uygulamanın sistem durumu yönetimi için temeldir

Şekil 4-22'de gösterilen karmaşık sorunları kendiniz çözmek zordur. Geliştirme ekipleri, mikro hizmet tabanlı yaklaşımlarla iş sorunlarını çözmeye ve özel uygulamalar oluşturmaya odaklanmalıdır. Karmaşık altyapı sorunlarını çözmeye odaklanmamalılar; varsa, mikro hizmet tabanlı herhangi bir uygulamanın maliyeti çok büyük olacaktır. Bu nedenle, hizmet oluşturma ve çalıştırma ve altyapı kaynaklarını verimli bir şekilde kullanmayla ilgili zor sorunları çözmeye çalışan, düzenleyiciler veya mikro hizmet kümeleri olarak adlandırılan mikro hizmet odaklı platformlar vardır. Bu yaklaşım, mikro hizmet yaklaşımı kullanan uygulamalar oluşturmanın karmaşıklıklarını azaltır.

Farklı düzenleyiciler benzer görünebilir, ancak her biri tarafından sunulan tanılama ve sistem durumu denetimleri, sonraki bölümde açıklandığı gibi bazı durumlarda işletim sistemi platformuna bağlı olarak özelliklerde ve olgunluk durumunda farklılık gösterir.

Ek kaynaklar