Reliable Services özelliğine genel bakış
Azure Service Fabric, durum bilgisi olmayan ve durum bilgisi olan hizmetlerin yazılması ve yönetilmesini kolaylaştırır. Bu konu şunları içerir:
- Durum bilgisi olmayan ve durum bilgisi olan hizmetler için Reliable Services programlama modeli.
- Güvenilir Hizmet yazarken yapmanız gereken seçimler.
- Reliable Services'ın ne zaman kullanılacağına ve nasıl yazıldıklarına dair bazı senaryolar ve örnekler.
Reliable Services , Service Fabric'te kullanılabilen programlama modellerinden biridir. Bir diğeri, Reliable Services modelinin üzerinde bir Sanal Aktör uygulama çerçevesi sağlayan Reliable Actor programlama modelidir. Reliable Actors hakkında daha fazla bilgi için bkz . Service Fabric Reliable Actors'a Giriş.
Service Fabric, hizmet sağlama ve dağıtımdan yükseltme ve silmeye kadar hizmetlerin ömrünü Service Fabric uygulama yönetimi aracılığıyla yönetir.
Reliable Services nedir?
Reliable Services, uygulamanız için önemli olan şeyleri ifade etmeye yardımcı olmak için basit, güçlü, üst düzey bir programlama modeli sunar. Reliable Services programlama modeliyle şunları elde edersiniz:
- Service Fabric API'lerine erişim. Konuk Yürütülebilir Dosyaları olarak modellenen Service Fabric hizmetlerinden farklı olarak Reliable Services, Service Fabric API'lerini doğrudan kullanabilir. Bu, hizmetlerin şunları yapmasına olanak tanır:
- Diğer tanıdık programlama modelleri gibi hissettiren kendi kodunuzu çalıştırmak için basit bir model. Kodunuzun iyi tanımlanmış bir giriş noktası ve kolayca yönetilen yaşam döngüsü vardır.
- Takılabilir iletişim modeli. Web API'si, WebSockets, özel TCP protokolleri veya başka herhangi bir şeyle HTTP gibi tercih edilen aktarımları kullanın. Reliable Services, kullanabileceğiniz harika kullanıma uygun seçenekler sunar veya kendiniz de sağlayabilirsiniz.
- Durum bilgisi olan hizmetler için Reliable Services programlama modeli, Reliable Collections kullanarak durumunuzu tutarlı ve güvenilir bir şekilde hizmetinizin içinde depolamanıza olanak tanır. Reliable Collections, C# koleksiyonlarını kullanan herkese tanıdık gelecek, yüksek oranda kullanılabilir ve güvenilir koleksiyon sınıflarından oluşan basit bir kümedir. Geleneksel olarak, hizmetlerin Güvenilir durum yönetimi için dış sistemlere ihtiyacı vardı. Reliable Collections ile durumunuzu, yüksek oranda kullanılabilir dış mağazalardan beklediğiniz yüksek kullanılabilirlik ve güvenilirlikle işleminizin yanında depolayabilirsiniz. Bu model, işlem ve çalışması gereken durumu birlikte konumlandırdığınızdan gecikme süresini de artırır.
Reliable Services'i farklı kılan şey
Service Fabric şunları sağladığından, Reliable Services daha önce yazmış olabileceğiniz hizmetlerden farklıdır:
- Güvenilirlik - Hizmetiniz, makinelerinizin başarısız olduğu veya ağ sorunlarına düştüğü ya da hizmetlerin hatalarla karşılaştığı ve kilitlenme ya da başarısız olduğu durumlarda bile güvenilir olmayan ortamlarda çalışır durumda kalır. Durum bilgisi olan hizmetler için, durumunuz ağ veya diğer hatalar olduğunda bile korunur.
- Kullanılabilirlik - Hizmetinize ulaşılabilir ve yanıt verir. Service Fabric, istediğiniz sayıda çalışan kopyayı korur.
- Ölçeklenebilirlik - Hizmetler belirli donanımlardan ayrılmıştır ve donanım veya diğer kaynakların eklenmesi veya kaldırılması yoluyla gerektiğinde büyüyebilir veya küçülebilir. Hizmetlerin kısmi hataları ölçeklendirebilmesi ve işleyebilmesi için hizmetler kolayca bölümlenir (özellikle durum bilgisi olan durumlarda). Hizmetler kod aracılığıyla dinamik olarak oluşturulup silinebilir ve böylece daha fazla örneğin gerektiğinde (örneğin müşteri isteklerine yanıt olarak) desteklenmesi sağlanabilir. Son olarak Service Fabric, hizmetlerin basit olmasını teşvik eder. Service Fabric, işletim sistemi örneklerinin veya işlemlerinin tamamını tek bir hizmet örneğine gerektirmek veya ayırmak yerine tek bir işlem içinde binlerce hizmetin sağlanmasına olanak tanır.
- Tutarlılık - Güvenilir Hizmette depolanan tüm bilgilerin tutarlı olması garanti edilebilir. Bu, bir hizmet içindeki birden çok Güvenilir Koleksiyonda bile geçerlidir. Bir hizmet içindeki koleksiyonlar arasında yapılan değişiklikler işlemsel olarak atomik bir şekilde yapılabilir.
Hizmet yaşam döngüsü
Hizmetinizin durum bilgisi veya durum bilgisi olmasa da Reliable Services, kodunuzu hızla takmanızı ve kullanmaya başlamanızı sağlayan basit bir yaşam döngüsü sağlar. Yeni bir hizmeti çalışır duruma getirmek için iki yöntem uygulamanız gerekir:
- CreateServiceReplicaListeners/CreateServiceInstanceListeners - Bu yöntem, hizmetin kullanmak istediği iletişim yığınlarını tanımladığı yöntemdir. Web API'si gibi iletişim yığını, hizmetin dinleme uç noktasını veya uç noktalarını (istemcilerin hizmete nasıl ulaştığı) tanımlar. Ayrıca görüntülenen iletilerin hizmet kodunun geri kalanıyla nasıl etkileşim kurduğunu da tanımlar.
- RunAsync - Bu yöntem, hizmetinizin iş mantığını çalıştırdığı ve hizmetin ömrü boyunca çalışması gereken arka plan görevlerini başlatacağı yerdir. Sağlanan iptal belirteci, bu çalışmanın ne zaman durdurulacağını belirten bir sinyaldir. Örneğin, hizmetin iletileri Güvenilir Kuyruktan çekmesi ve işlemesi gerekiyorsa, bu iş burada gerçekleşir.
Güvenilir hizmetler hakkında ilk kez bilgi ediniyorsanız okumaya devam edin! Güvenilir hizmetlerin yaşam döngüsü hakkında ayrıntılı bir kılavuz arıyorsanız Reliable Services yaşam döngüsüne genel bakış makalesine bakın.
Örnek hizmetler
Reliable Services modelinin hem durum bilgisi olmayan hem de durum bilgisi olan hizmetlerle nasıl çalıştığına daha yakından bakalım.
Durum Bilgisi Olmayan Güvenilir Hizmetler
Durum bilgisi olmayan bir hizmet, çağrılar arasında hizmet içinde hiçbir durumun korunmadığı hizmettir. Mevcut olan herhangi bir durum tamamen atılabilirdir ve eşitleme, çoğaltma, kalıcılık veya yüksek kullanılabilirlik gerektirmez.
Örneğin, belleği olmayan ve aynı anda gerçekleştirilecek tüm terimleri ve işlemleri alan bir hesap makinesi düşünün.
Bu durumda, RunAsync() hizmetin (C#) veya runAsync() (Java) boş olabilir çünkü hizmetin yapması gereken arka plan görevi işlemesi yoktur. Hesap makinesi hizmeti oluşturulduğunda, bir bağlantı noktasında dinleme uç noktasını açan bir ICommunicationListener (C#) veya CommunicationListener (Java) (örneğin Web API'si) döndürür. Bu dinleme uç noktası, hesaplayıcının genel API'sini tanımlayan farklı hesaplama yöntemlerine (örnek: "Ekle(n1, n2)") bağlar.
bir istemciden çağrı yapıldığında, uygun yöntem çağrılır ve hesap makinesi hizmeti sağlanan veriler üzerinde işlemleri gerçekleştirir ve sonucu döndürür. Herhangi bir durum depolamaz.
Herhangi bir iç durumun depolanmaması, bu örnek hesaplayıcıyı basitleştirir. Ancak çoğu hizmet gerçekten durum bilgisi olmayan bir hizmettir. Bunun yerine, durumlarını başka bir depoda dışlarlar. (Örneğin, bir yedekleme deposunda veya önbellekte oturum durumunu korumayı kullanan herhangi bir web uygulaması durum bilgisi yoktur.)
Service Fabric'te durum bilgisi olmayan hizmetlerin nasıl kullanıldığını gösteren yaygın bir örnek, web uygulaması için genel kullanıma yönelik API'yi kullanıma sunan bir ön uç olarak gösterilir. Ön uç hizmeti daha sonra durum bilgisi olan hizmetlerle konuşarak kullanıcı isteğini tamamlar. Bu durumda, istemcilerden gelen çağrılar durum bilgisi olmayan hizmetin dinlediği 80 gibi bilinen bir bağlantı noktasına yönlendirilir. Bu durum bilgisi olmayan hizmet çağrıyı alır ve aramanın güvenilir bir tarafa ait olup olmadığını ve hedeflendiği hizmeti belirler. Ardından durum bilgisi olmayan hizmet çağrıyı durum bilgisi olan hizmetin doğru bölümüne iletir ve yanıt bekler. Durum bilgisi olmayan hizmet bir yanıt aldığında, özgün istemciyi yanıtlar. Bu tür bir hizmete örnek olarak, bu depodaki diğer Service Fabric örneklerinin yanı sıra Service Fabric Kullanmaya Başlama örneği (C# / Java) gösteriliyor.
Durum Bilgisi Olan Güvenilir Hizmetler
Durum bilgisi olan bir hizmet, hizmetin çalışması için durumun bazı bölümlerinin tutarlı ve mevcut tutulması gereken hizmettir. Aldığı güncelleştirmelere göre sürekli bir değer ortalaması hesaplayan bir hizmet düşünün. Bunu yapmak için işlemesi gereken geçerli gelen istek kümesine ve geçerli ortalamaya sahip olması gerekir. Bilgileri bir dış depoda (bugün Azure blobu veya tablo deposu gibi) alan, işleyen ve depolayan tüm hizmetler durum bilgisi içerir. Yalnızca durumunu dış durum deposunda tutar.
Günümüzde çoğu hizmet, bu durum için güvenilirlik, kullanılabilirlik, ölçeklenebilirlik ve tutarlılık sağlayan dış depo olduğundan, durumlarını harici olarak depolar. Service Fabric'te hizmetlerin durumlarını harici olarak depolaması gerekmez. Service Fabric hem hizmet kodu hem de hizmet durumu için bu gereksinimleri üstlenir.
Görüntüleri işleyen bir hizmet yazmak istediğimizi düşünelim. Bunu yapmak için hizmet bir görüntü alır ve bu görüntüde gerçekleştirilecek dönüştürme serisini alır. Bu hizmet, gibi ConvertImage(Image i, IList<Conversion> conversions)bir API'yi kullanıma sunan bir iletişim dinleyicisi (bir WebAPI olduğunu varsayalım) döndürür. Bir istek aldığında, hizmet bunu bir IReliableQueueiçinde depolar ve isteği izleyebilmesi için istemciye bir kimlik döndürür.
Bu hizmette daha RunAsync() karmaşık olabilir. Hizmetin içinde RunAsync() istekleri çeken IReliableQueue ve istenen dönüştürmeleri gerçekleştiren bir döngü vardır. Sonuçlar, istemci geri döndüğünde dönüştürülen görüntülerini alabilmesi için bir IReliableDictionary içinde depolanır. Bir şey başarısız olsa bile görüntünün kaybolmadığından emin olmak için, bu Güvenilir Hizmet kuyruktan çekilir, dönüştürmeleri gerçekleştirir ve sonucun tümünü tek bir işlemde depolar. Bu durumda, ileti kuyruktan kaldırılır ve sonuçlar yalnızca dönüştürmeler tamamlandığında sonuç sözlüğünde depolanır. Alternatif olarak, hizmet görüntüyü kuyruktan çıkarabilir ve hemen uzak bir depoda depolayabilir. Bu, hizmetin yönetmesi gereken durum miktarını azaltır, ancak hizmetin uzak depoyu yönetmek için gerekli meta verileri tutması gerektiğinden karmaşıklığı artırır. Her iki yaklaşımdan biriyle de, ortada bir şey başarısız olursa istek işlenmek üzere kuyrukta kalır.
Bu hizmet tipik bir .NET hizmeti gibi görünse de, fark kullanılan veri yapılarının (IReliableQueue ve IReliableDictionary) Service Fabric tarafından sağlanması ve son derece güvenilir, kullanılabilir ve tutarlı olmasıdır.
Reliable Services API'leri ne zaman kullanılır?
Aşağıdaki durumlarda Reliable Services API'lerini göz önünde bulundurun:
- Hizmetinizin kodunun (ve isteğe bağlı olarak durumunun) yüksek oranda kullanılabilir ve güvenilir olmasını istiyorsunuz.
- Birden çok durum birimi (örneğin, siparişler ve sipariş satırı öğeleri) genelinde işlem garantilerine ihtiyacınız vardır.
- Uygulamanızın durumu doğal olarak Güvenilir Sözlükler ve Kuyruklar olarak modellenebilir.
- Uygulama kodunuzun veya durumunuzun düşük gecikmeli okuma ve yazma işlemleriyle yüksek oranda kullanılabilir olması gerekir.
- Uygulamanızın bir veya daha fazla Güvenilir Koleksiyonda işlenen işlemlerin eşzamanlılığını veya ayrıntı düzeyini denetlemesi gerekir.
- İletişimleri yönetmek veya hizmetiniz için bölümleme düzenini denetlemek istiyorsunuz.
- Kodunuz serbest iş parçacıklı bir çalışma zamanı ortamına ihtiyaç duyar.
- Uygulamanızın çalışma zamanında Güvenilir Sözlükler, Kuyruklar veya tüm Hizmetleri dinamik olarak oluşturması veya yok etmesi gerekir.
- Hizmetinizin durumu için Service Fabric tarafından sağlanan yedekleme ve geri yükleme özelliklerini program aracılığıyla denetlemeniz gerekir.
- Uygulamanızın durum birimleri için değişiklik geçmişini koruması gerekir.
- Üçüncü taraf tarafından geliştirilen özel durum sağlayıcıları geliştirmek veya kullanmak istiyorsunuz.