Azure Service Fabric uygulaması tasarımı için en iyi yöntemler

Bu makale, Azure Service Fabric'te uygulama ve hizmet oluşturmaya yönelik en iyi uygulama kılavuzlarını sağlar.

Service Fabric hakkında bilgi edinin

• Service Fabric hakkında bilgi edinmek mi istiyorsunuz? makalesini okuyun.
• Service Fabric uygulama senaryoları hakkında bilgi edinin.
• Service Fabric programlama modeline genel bakış okuyarak programlama modeli seçimlerini anlayın.

Uygulama tasarımı kılavuzu

Service Fabric uygulamalarının genel mimarisini ve tasarım konularını tanıyın.

API ağ geçidi seçme

Daha sonra ölçeği genişletilebilen arka uç hizmetleriyle iletişim kuran bir API ağ geçidi hizmeti kullanın. Kullanılan en yaygın API ağ geçidi hizmetleri şunlardır:

• Service Fabric ile tümleştirilmiş Azure API Management.

• Azure Service Fabric sağlayıcısını kullanarak Træfik ters proxy'si.

• Azure Uygulaması Lication Gateway.

  Dekont

  Azure Uygulaması lication Gateway, Service Fabric ile doğrudan tümleştirilmez. Azure API Management genellikle tercih edilen seçenektir.

• Kendi özel olarak oluşturulmuş ASP.NET Core web uygulaması ağ geçidiniz.

Durum bilgisi olmayan hizmetler

Her zaman Reliable Services kullanarak durum bilgisi olmayan hizmetler oluşturarak başlamanızı ve durumu bir Azure veritabanında, Azure Cosmos DB'de veya Azure Depolama depolamanızı öneririz. Dışlaştırılmış durum, çoğu geliştirici için daha tanıdık bir yaklaşımdır. Bu yaklaşım, mağazadaki sorgu özelliklerinden de yararlanmanızı sağlar.

Durum bilgisi olan hizmetler ne zaman kullanılır?

Düşük gecikme süresi senaryonuz varsa ve verileri işlemle yakın tutmanız gerektiğinde durum bilgisi olan hizmetleri göz önünde bulundurun. Bazı örnek senaryolar arasında IoT dijital ikiz cihazları, oyun durumu, oturum durumu, veritabanından verileri önbelleğe alma ve diğer hizmetlere yapılan çağrıları izlemek için uzun süre çalışan iş akışları sayılabilir.

Veri saklama zaman çerçevesine karar verin:

• Önbellege alınan veri Dış depolarda gecikme süresi sorun olduğunda önbelleğe alma özelliğini kullanın. Durum bilgisi olan bir hizmeti kendi veri önbelleğiniz olarak kullanın veya açık kaynak SoCreate Service Fabric Dağıtılmış Önbelleğini kullanmayı göz önünde bulundurun. Bu senaryoda, önbellekteki tüm verileri kaybederseniz endişelenmenize gerek yoktur.
• Zamana bağlı veriler. Bu senaryoda, verileri gecikme süresi için bir süre için işlemle yakın tutmanız gerekir, ancak olağanüstü durumdaki verileri kaybetmeyi göze alabilirsiniz. Örneğin, birçok IoT çözümünde verilerin, son birkaç gün içindeki ortalama sıcaklığın hesaplanması gibi işlem açısından yakın olması gerekir, ancak bu veriler kaybolursa, kaydedilen belirli veri noktaları o kadar önemli değildir. Ayrıca, bu senaryoda genellikle tek tek veri noktalarını yedeklemeyi önemsemezsiniz. Yalnızca düzenli aralıklarla dış depolama alanına yazılan hesaplanan ortalama değerleri yedeklersiniz.
• Uzun vadeli veriler. Güvenilir koleksiyonlar verilerinizi kalıcı olarak depolayabilir. Ancak bu durumda, kümeleriniz için düzenli yedekleme ilkeleri yapılandırmak da dahil olmak üzere olağanüstü durum kurtarma için hazırlanmanız gerekir. Aslında, kümeniz bir olağanüstü durumda yok edilirse ne olacağını, yeni bir küme oluşturmanız gerekeceği durumları ve yeni uygulama örneklerini dağıtmayı ve en son yedeklemeden kurtarmayı yapılandırabilirsiniz.

Maliyetlerden tasarruf edin ve kullanılabilirliği artırın:

• Uzak depodan veri erişimi ve işlem maliyetlerine neden olmadığınızdan ve Redis için Azure Cache gibi başka bir hizmet kullanmanız gerekmediğinden durum bilgisi olan hizmetleri kullanarak maliyetleri azaltabilirsiniz.
• Durum bilgisi olan hizmetleri işlem için değil öncelikli olarak depolama için kullanmak pahalıdır ve bunu önermiyoruz. Durum bilgisi olan hizmetleri ucuz yerel depolama alanıyla işlem olarak düşünün.
• Diğer hizmetlerdeki bağımlılıkları kaldırarak hizmet kullanılabilirliğinizi geliştirebilirsiniz. Kümede HA ile durumu yönetmek, sizi diğer hizmet kapalı kalma sürelerinden veya gecikme sorunlarından yalıtır.

Reliable Services ile çalışma

Service Fabric Reliable Services, durum bilgisi olmayan ve durum bilgisi olan hizmetleri kolayca oluşturmanıza olanak tanır. Daha fazla bilgi için Reliable Services'a giriş bölümüne bakın.

• Durum bilgisi olmayan ve durum bilgisi olan hizmetler için yönteminde RunAsync() ve durum bilgisi olan hizmetler için yönteminde her zaman iptal belirteciniChangeRole() kabul edin. Bunu yapmazsanız Service Fabric hizmetinizin kapatılıp kapatılamadığını bilmez. Örneğin, iptal belirtecini kabul etmediyseniz, uygulama yükseltme süreleri çok daha uzun olabilir.
• İletişim dinleyicilerini zamanında açıp kapatın ve iptal belirteçlerini kabul edin.
• Eşitleme kodunu hiçbir zaman uyumsuz kodla karıştırmayın. Örneğin, zaman uyumsuz çağrılarınızda kullanmayın .GetAwaiter().GetResult() . Çağrı yığını boyunca zaman uyumsuz kullanın.

Reliable Actors ile çalışma

Service Fabric Reliable Actors, durum bilgisi olan sanal aktörleri kolayca oluşturmanıza olanak tanır. Daha fazla bilgi için Reliable Actors'a giriş bölümüne bakın.

• Uygulamanızı ölçeklendirmek için aktörleriniz arasında pub/sub mesajlaşması kullanmayı ciddi şekilde göz önünde bulundurun. Bu hizmeti sağlayan araçlar arasında açık kaynak SoCreate Service Fabric Pub/Sub ve Azure Service Bus bulunur.
• Aktör durumunu mümkün olduğunca ayrıntılı hale getirin.
• Aktörün yaşam döngüsünü yönetin. Yeniden kullanmayacaksanız aktörleri silin. Tüm durum bellekte depolandığından , geçici durum sağlayıcısını kullanırken gereksiz aktörlerin silinmesi özellikle önemlidir.
• Sıra tabanlı eşzamanlılıkları nedeniyle aktörler en iyi bağımsız nesneler olarak kullanılır. Çok aktörlü, zaman uyumlu yöntem çağrılarının grafiklerini oluşturmayın (her biri büyük olasılıkla ayrı bir ağ çağrısına dönüşür) veya döngüsel aktör istekleri oluşturmayın. Bunlar performansı ve ölçeği önemli ölçüde etkiler.
• Eşitleme kodunu zaman uyumsuz kodla karıştırmayın. Performans sorunlarını önlemek için sürekli olarak zaman uyumsuz kullanın.
• Aktörlerde uzun süre çalışan aramalar yapmayın. Uzun süre çalışan çağrılar, sıra tabanlı eşzamanlılık nedeniyle aynı aktöre yapılan diğer çağrıları engeller.
• Service Fabric uzaktan iletişimini kullanarak diğer hizmetlerle iletişim kuruyorsanız ve bir ServiceProxyFactoryoluşturuyorsanız, fabrikayı aktör düzeyinde değil aktör-hizmet düzeyinde oluşturun.

Uygulama tanılamaları

Hizmet çağrılarına uygulama günlüğü ekleme konusunda kapsamlı olun. Hizmetlerin birbirini çağırdığı senaryoları tanılamanıza yardımcı olur. Örneğin, A B çağrısı C,D'yi aradığında, arama her yerde başarısız olabilir. Yeterli günlük kaydınız yoksa hataları tanılamak zordur. Çağrı birimleri nedeniyle hizmetler çok fazla günlüğe kaydediyorsa, en azından hataları ve uyarıları günlüğe kaydetmeyi unutmayın.

Azure'da tasarım kılavuzu

• Azure'da mikro hizmetler oluşturmaya yönelik tasarım yönergeleri için Azure mimari merkezini ziyaret edin.

• Oyun hizmetlerinde Service Fabric'i kullanmayla ilgili tasarım yönergeleri için Oyun için Azure'ı kullanmaya başlama sayfasını ziyaret edin.