Service Fabric'te ölçeklendirme

Azure Service Fabric, bir kümenin düğümlerindeki hizmetleri, bölümleri ve çoğaltmaları yöneterek ölçeklenebilir uygulamalar oluşturmayı kolaylaştırır. Aynı donanımda birçok iş yükü çalıştırmak en fazla kaynak kullanımına olanak tanır, ancak iş yüklerinizi ölçeklendirmeyi nasıl seçtiğiniz konusunda esneklik de sağlar. Bu Channel 9 videosunda ölçeklenebilir mikro hizmet uygulamalarını nasıl oluşturabileceğiniz açıklanır:

Service Fabric'te ölçeklendirme birkaç farklı yolla gerçekleştirilir:

1. Durum bilgisi olmayan hizmet örnekleri oluşturarak veya kaldırarak ölçeklendirme
2. Yeni adlandırılmış hizmetler oluşturarak veya kaldırarak ölçeklendirme
3. Yeni adlandırılmış uygulama örnekleri oluşturarak veya kaldırarak ölçeklendirme
4. Bölümlenmiş hizmetleri kullanarak ölçeklendirme
5. Kümeye düğüm ekleyerek ve kümeden kaldırarak ölçeklendirme
6. Küme Resource Manager ölçümlerini kullanarak ölçeklendirme

Durum bilgisi olmayan hizmet örnekleri oluşturarak veya kaldırarak ölçeklendirme

Service Fabric içinde ölçeklendirmenin en basit yollarından biri durum bilgisi olmayan hizmetlerle çalışır. Durum bilgisi olmayan bir hizmet oluşturduğunuzda, bir InstanceCounttanımlama fırsatı elde edersiniz. InstanceCount , hizmet başlatıldığında bu hizmet kodunun kaç tane çalışan kopyasının oluşturulduğunu tanımlar. Örneğin kümede 100 düğüm olduğunu varsayalım. Ayrıca 10 ile bir hizmet oluşturulduğunu InstanceCount da düşünelim. Çalışma zamanı sırasında, kodun çalışan 10 kopyası çok meşgul olabilir (veya yeterince meşgul olmayabilir). Bu iş yükünü ölçeklendirmenin bir yolu, örnek sayısını değiştirmektir. Örneğin, bir izleme veya yönetim kodu parçası, iş yükünün yüke göre ölçeği daraltması veya genişletmesi gerekip gerekmediğine bağlı olarak mevcut örnek sayısını 50 veya 5 olarak değiştirebilir.

C#:

StatelessServiceUpdateDescription updateDescription = new StatelessServiceUpdateDescription(); 
updateDescription.InstanceCount = 50;
await fabricClient.ServiceManager.UpdateServiceAsync(new Uri("fabric:/app/service"), updateDescription);

PowerShell:

Update-ServiceFabricService -Stateless -ServiceName $serviceName -InstanceCount 50

Dinamik Örnek Sayısını Kullanma

Özellikle durum bilgisi olmayan hizmetler için Service Fabric, örnek sayısını değiştirmek için otomatik bir yol sunar. Bu, hizmetin kullanılabilir düğüm sayısıyla dinamik olarak ölçeklendirilmesini sağlar. Bu davranışı kabul etmenin yolu, örnek sayısını = -1 ayarlamaktır. InstanceCount = -1, Service Fabric için "Bu durum bilgisi olmayan hizmeti her düğümde çalıştır" yazan bir yönergedir. Düğüm sayısı değişirse Service Fabric, hizmetin tüm geçerli düğümlerde çalıştığından emin olarak örnek sayısını otomatik olarak eşleşecek şekilde değiştirir.

C#:

StatelessServiceDescription serviceDescription = new StatelessServiceDescription();
//Set other service properties necessary for creation....
serviceDescription.InstanceCount = -1;
await fc.ServiceManager.CreateServiceAsync(serviceDescription);

PowerShell:

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName -Stateless -PartitionSchemeSingleton -InstanceCount "-1"

Yeni adlandırılmış hizmetler oluşturarak veya kaldırarak ölçeklendirme

Adlandırılmış hizmet örneği, kümedeki bazı adlandırılmış uygulama örneği içindeki bir hizmet türünün (bkz . Service Fabric uygulama yaşam döngüsü) belirli bir örneğidir.

Hizmetler daha fazla veya daha az meşgul hale geldikçe yeni adlandırılmış hizmet örnekleri oluşturulabilir (veya kaldırılabilir). Bu, isteklerin daha fazla hizmet örneğine yayılmasına olanak tanır ve genellikle mevcut hizmetler üzerindeki yükün azalmasına olanak tanır. Hizmet oluştururken Service Fabric Kümesi Kaynak Yöneticisi, hizmetleri dağıtılmış bir şekilde kümeye yerleştirir. Kesin kararlar kümedeki ölçümlere ve diğer yerleştirme kurallarına tabidir. Hizmetler birkaç farklı yolla oluşturulabilir, ancak en yaygın olanı veya kod çağrısı CreateServiceAsyncyapan biri New-ServiceFabricServicegibi yönetim eylemleridir. CreateServiceAsync kümede çalışan diğer hizmetlerin içinden bile çağrılabilir.

Hizmetleri dinamik olarak oluşturmak her türlü senaryoda kullanılabilir ve yaygın bir desendir. Örneğin, belirli bir iş akışını temsil eden durum bilgisi olan bir hizmet düşünün. Çalışmayı temsil eden çağrılar bu hizmette gösterilir ve bu hizmet bu iş akışı ve kayıt ilerleme durumunun adımlarını yürütür.

Bu hizmet ölçeğini nasıl oluşturursunuz? Hizmet bir biçimde çok kiracılı olabilir ve çağrıları kabul edebilir ve aynı iş akışının birçok farklı örneği için adımları tek seferde başlatabilir. Ancak bu, kodu daha karmaşık hale getirebileceğinden, artık farklı aşamalarda ve farklı müşterilerden gelen aynı iş akışının birçok farklı örneği hakkında endişelenmesi gerekir. Ayrıca, birden çok iş akışının aynı anda işlenmesi ölçek sorununu çözmez. Bunun nedeni, bir noktada bu hizmetin belirli bir makineye sığamayacak kadar çok kaynak tüketmesidir. İlk etapta bu düzen için derlenmemiş birçok hizmet, kendi kodlarındaki bazı performans sorunları veya yavaşlama nedeniyle de zorluk yaşar. Bu tür sorunlar, izlediği eşzamanlı iş akışlarının sayısı daha fazla olduğunda hizmetin de çalışmamasına neden olur.

Çözüm, izlemek istediğiniz iş akışının her farklı örneği için bu hizmetin bir örneğini oluşturmaktır. Bu harika bir desendir ve hizmet durum bilgisi olmayan veya durum bilgisi olan bir hizmettir. Bu düzenin çalışması için genellikle "İş Yükü Yöneticisi Hizmeti" işlevi gören başka bir hizmet vardır. Bu hizmetin işi, istekleri almak ve bu istekleri diğer hizmetlere yönlendirmektir. Yönetici, iletiyi aldığında iş yükü hizmetinin bir örneğini dinamik olarak oluşturabilir ve ardından istekleri bu hizmetlere iletebilir. Belirli bir iş akışı hizmeti işini tamamladığında yönetici hizmeti de geri çağırmalar alabilir. Yönetici bu geri çağırmaları aldığında iş akışı hizmetinin söz konusu örneğini silebilir veya daha fazla çağrı bekleniyorsa bu durumdan ayrılabilir.

Bu tür bir yöneticinin gelişmiş sürümleri, yönettiği hizmetlerin havuzlarını bile oluşturabilir. Havuz, yeni bir istek geldiğinde hizmetin dönmesini beklemek zorunda olmamasını sağlamaya yardımcı olur. Bunun yerine, yönetici havuzdan şu anda meşgul olmayan bir iş akışı hizmeti seçebilir veya rastgele yönlendirme yapabilir. Bir hizmet havuzunun kullanılabilir durumda tutulması, yeni isteklerin işlenmesini hızlandırır, çünkü isteğin yeni bir hizmetin başlatılmasını beklemesi daha az olasıdır. Yeni hizmetler oluşturmak hızlıdır, ancak ücretsiz veya anlık değildir. Havuz, isteğin servise alınmadan önce beklemesi gereken süreyi en aza indirmeye yardımcı olur. Yanıt sürelerinin en önemli olduğu durumlarda genellikle bu yöneticiyi ve havuz desenini görürsünüz. İsteği kuyruğa alıp arka planda hizmet oluşturup sonra da geçirmek, hizmetin şu anda beklemede olduğu çalışma miktarının bir miktar izlenmesine dayalı olarak hizmet oluşturma ve silme gibi popüler bir yönetici düzenidir.

Yeni adlandırılmış uygulama örnekleri oluşturarak veya kaldırarak ölçeklendirme

Uygulama örneklerinin tamamını oluşturma ve silme, hizmet oluşturma ve silme desenine benzer. Bu düzen için, gördüğü isteklere ve küme içindeki diğer hizmetlerden aldığı bilgilere göre karar veren bir yönetici hizmeti vardır.

Mevcut olan bir uygulamada yeni adlandırılmış hizmet örnekleri oluşturmak yerine ne zaman yeni bir adlandırılmış uygulama örneği oluşturulmalıdır? Birkaç durum vardır:

• Yeni uygulama örneği, kodu belirli bir kimlik veya güvenlik ayarları altında çalışması gereken bir müşteriye yöneliktir.
  • Service Fabric, belirli kimlikler altında çalıştırılacak farklı kod paketleri tanımlamaya olanak tanır. Aynı kod paketini farklı kimlikler altında başlatmak için etkinleştirmelerin farklı uygulama örneklerinde gerçekleşmesi gerekir. Mevcut bir müşterinin iş yüklerinin dağıtıldığı bir durum düşünün. Bunlar belirli bir kimlik altında çalışıyor olabilir, böylece uzak veritabanları veya diğer sistemler gibi diğer kaynaklara erişimlerini izleyebilir ve denetleyebilirsiniz. Bu durumda, yeni bir müşteri kaydolduğunda, büyük olasılıkla kodunu aynı bağlamda (işlem alanı) etkinleştirmek istemezsiniz. Bu, hizmet kodunuzun belirli bir kimlik bağlamında hareket etmelerini zorlaştırır. Genellikle daha fazla güvenlik, yalıtım ve kimlik yönetimi koduna sahip olmanız gerekir. Aynı uygulama örneği ve dolayısıyla aynı işlem alanı içinde farklı adlandırılmış hizmet örnekleri kullanmak yerine farklı adlandırılmış Service Fabric Uygulaması örnekleri kullanabilirsiniz. Bu, farklı kimlik bağlamları tanımlamayı kolaylaştırır.
• Yeni uygulama örneği aynı zamanda bir yapılandırma aracı olarak da hizmet eder
  • Varsayılan olarak, bir uygulama örneği içindeki belirli bir hizmet türünün adlandırılmış hizmet örneklerinin tümü belirli bir düğümde aynı işlemde çalışır. Bunun anlamı, her hizmet örneğini farklı şekilde yapılandırabilmenize karşın bunu yapmanın karmaşık olduğudur. Hizmetlerin yapılandırmalarını bir yapılandırma paketi içinde aramak için kullandıkları bazı belirteçler olmalıdır. Genellikle bu yalnızca hizmetin adıdır. Bu düzgün çalışır, ancak yapılandırmayı söz konusu uygulama örneği içindeki tek tek adlandırılmış hizmet örneklerinin adlarıyla eşler. Yapılandırma normalde uygulama örneğine özgü değerlerle bir tasarım zamanı yapıtı olduğundan bu durum kafa karıştırıcı ve yönetilmesi zor olabilir. Daha fazla hizmet oluşturmak, her zaman yapılandırma paketleri içindeki bilgileri değiştirmek veya yenilerini dağıtmak için daha fazla uygulama yükseltmesi anlamına gelir; böylece yeni hizmetler kendi özel bilgilerini arayabilir. Tamamen yeni bir adlandırılmış uygulama örneği oluşturmak genellikle daha kolaydır. Ardından, hizmetler için gereken yapılandırmayı ayarlamak için uygulama parametrelerini kullanabilirsiniz. Bu şekilde, söz konusu adlandırılmış uygulama örneğinde oluşturulan tüm hizmetler belirli yapılandırma ayarlarını devralabilir. Örneğin, gizli diziler veya müşteri başına kaynak sınırları gibi her müşteri için ayarlar ve özelleştirmeler içeren tek bir yapılandırma dosyası yerine, bu ayarları geçersiz kılınan her müşteri için farklı bir uygulama örneğine sahip olursunuz.
• Yeni uygulama bir yükseltme sınırı görevi görür
  • Service Fabric'in içinde, farklı adlandırılmış uygulama örnekleri yükseltme için sınırlar görevi görür. Adlandırılmış bir uygulama örneğinin yükseltmesi, başka bir adlandırılmış uygulama örneğinin çalıştırdığı kodu etkilemez. Farklı uygulamalar aynı düğümlerde aynı kodun farklı sürümlerini çalıştırır. Yeni kodun başka bir hizmetle aynı yükseltmeleri izleyip izlemeyeceğini seçebildiğiniz için ölçeklendirme kararı vermeniz gerektiğinde bu bir faktör olabilir. Örneğin, hizmetleri dinamik olarak oluşturup silerek belirli bir müşterinin iş yüklerini ölçeklendirmek için sorumlu olan yönetici hizmetine bir çağrı geldiğini düşünün. Ancak bu durumda çağrı, yeni müşteriyle ilişkilendirilmiş bir iş yüküne yöneliktir. Müşterilerin çoğu, yalnızca daha önce listelenen güvenlik ve yapılandırma nedenleriyle değil, yazılımın belirli sürümlerini çalıştırma ve ne zaman yükseltildiklerini seçme açısından daha fazla esneklik sağladığından birbirinden yalıtılmaktan hoşlanır. Ayrıca, herhangi bir yükseltmenin dokunacağı hizmetlerinizin miktarını daha fazla bölümlendirmek için yeni bir uygulama örneği oluşturabilir ve hizmeti orada oluşturabilirsiniz. Ayrı uygulama örnekleri, uygulama yükseltmeleri yaparken daha fazla ayrıntı sağlar ve ayrıca A/B testi ile Mavi/Yeşil dağıtımları etkinleştirir.
• Mevcut uygulama örneği dolu
  • Service Fabric'te uygulama kapasitesi, belirli uygulama örnekleri için kullanılabilir kaynak miktarını denetlemek için kullanabileceğiniz bir kavramdır. Örneğin, belirli bir hizmetin ölçeklendirilebilmesi için başka bir örneğin oluşturulması gerektiğine karar vekleyebilirsiniz. Ancak bu uygulama örneğinin belirli bir ölçüm için kapasitesi yetersiz. Bu belirli müşteriye veya iş yüküne yine de daha fazla kaynak verilmesi gerekiyorsa, söz konusu uygulama için mevcut kapasiteyi artırabilir veya yeni bir uygulama oluşturabilirsiniz.

Bölüm düzeyinde ölçeklendirme

Service Fabric bölümleme desteği sağlar. Bölümleme, bir hizmeti her biri bağımsız olarak çalışan birkaç mantıksal ve fiziksel bölüme böler. Bu durum bilgisi olan hizmetlerde kullanışlıdır çünkü hiçbir çoğaltma kümesinin tüm çağrıları işlemesi ve tüm durumu aynı anda işlemesi gerekmez. Bölümlemeye genel bakış , desteklenen bölümleme düzenlerinin türleri hakkında bilgi sağlar. Her bölümün çoğaltmaları bir kümedeki düğümler arasında yayılır, bu hizmetin yükünü dağıtır ve hizmetin bir bütün olarak veya herhangi bir bölüm olarak tek bir hata noktası olmadığından emin olur.

Düşük anahtar 0, yüksek anahtar 99 ve bölüm sayısı 4 olan aralıklı bölümleme düzeni kullanan bir hizmeti düşünün. Üç düğümlü bir kümede hizmet, burada gösterildiği gibi her düğümdeki kaynakları paylaşan dört çoğaltmayla düzenlenmiş olabilir:

Düğüm sayısını artırırsanız, Service Fabric mevcut çoğaltmalardan bazılarını oraya taşır. Örneğin, düğüm sayısının dörte yükselip çoğaltmaların yeniden dağıtılacağını düşünelim. Artık hizmetin her düğümde çalışan ve her birinin farklı bölümlere ait olduğu üç çoğaltması vardır. Bu, yeni düğüm soğuk olmadığından daha iyi kaynak kullanımına olanak tanır. Genellikle, her hizmetin kullanılabilir kaynakları daha fazla olduğundan performansı da artırır.

Service Fabric Kümesi Resource Manager'ı ve ölçümleri kullanarak ölçeklendirme

Ölçümler , hizmetlerin kaynak tüketimini Service Fabric'e nasıl ifade ettikleridir. Ölçümlerin kullanılması, Küme Kaynak Yöneticisi'ne küme düzenini yeniden düzenleme ve iyileştirme fırsatı verir. Örneğin, kümede çok sayıda kaynak olabilir, ancak şu anda çalışmakta olan hizmetlere ayrılmamış olabilir. Ölçümlerin kullanılması, Küme Kaynak Yöneticisi'nin hizmetlerin kullanılabilir kaynaklara erişimi olduğundan emin olmak için kümeyi yeniden düzenlemesine olanak tanır.

Kümeye düğüm ekleyerek ve kümeden kaldırarak ölçeklendirme

Service Fabric ile ölçeklendirmeye yönelik bir diğer seçenek de kümenin boyutunu değiştirmektir. Kümenin boyutunu değiştirmek, kümedeki bir veya daha fazla düğüm türü için düğüm ekleme veya kaldırma anlamına gelir. Örneğin, kümedeki tüm düğümlerin sık erişimli olduğu bir durum düşünün. Bu, küme kaynaklarının neredeyse tamamının tüketildiğini gösterir. Bu durumda, kümeye daha fazla düğüm eklemek ölçeklendirmenin en iyi yoludur. Yeni düğümler kümeye katıldıktan sonra Service Fabric Kümesi Kaynak Yöneticisi hizmetleri bunlara taşır ve mevcut düğümlerde daha az toplam yük elde eder. Örnek sayısı = -1 olan durum bilgisi olmayan hizmetler için otomatik olarak daha fazla hizmet örneği oluşturulur. Bu, bazı çağrıların mevcut düğümlerden yeni düğümlere taşınmasına olanak tanır.

Daha fazla bilgi için bkz . Küme ölçeklendirme.

Platform seçme

İşletim sistemleri arasındaki uygulama farklılıkları nedeniyle Service Fabric'i Windows veya Linux ile kullanmayı seçmek, uygulamanızı ölçeklendirmenin önemli bir parçası olabilir. Olası engellerden biri, aşamalı günlüğe kaydetmenin nasıl gerçekleştirildiğidir. Windows'da Service Fabric, durum bilgisi olan hizmet çoğaltmaları arasında paylaşılan, makine başına bir günlük için çekirdek sürücüsü kullanır. Bu günlük yaklaşık 8 GB ağırlığındadır. Linux ise her çoğaltma için 256 MB hazırlama günlüğü kullanarak belirli bir düğümde çalışan basit hizmet çoğaltmalarının sayısını en üst düzeye çıkarmak isteyen uygulamalar için daha az ideal olmasını sağlar. Geçici depolama gereksinimlerindeki bu farklar, Service Fabric kümesi dağıtımı için istenen platformu bilgilendirebilir.

Hepsini bir araya getirme

Burada ele aldığımız tüm fikirleri ele alalım ve bir örnek üzerinden konuşalım. Şu hizmeti göz önünde bulundurun: Adres defteri işlevi gören, adlara ve iletişim bilgilerine sahip olan bir hizmet oluşturmaya çalışıyorsunuz.

Hemen ön tarafta ölçeklendirmeyle ilgili bir dizi sorunuz var: Kaç kullanıcınız olacak? Her kullanıcı kaç kişi depolayacak? Hizmetinizi ilk kez ayakta dururken tüm bunları anlamaya çalışmak zordur. Belirli bir bölüm sayısına sahip tek bir statik hizmetle gideceğiniz varsayalım. Yanlış bölüm sayısını seçmenin sonuçları daha sonra ölçeklendirme sorunlarına neden olabilir. Benzer şekilde, doğru sayıyı seçseniz bile ihtiyacınız olan tüm bilgilere sahip olmayabilirsiniz. Örneğin, hem düğüm sayısı hem de bunların boyutları açısından kümenin boyutunu önceden belirlemeniz gerekir. Bir hizmetin kullanım ömrü boyunca kaç kaynak tüketeceğini tahmin etmek genellikle zordur. Ayrıca hizmetin gerçekten gördüğü trafik düzenini önceden bilmek de zor olabilir. Örneğin, insanlar kişilerini yalnızca sabah ilk iş olarak ekleyip kaldırabilir veya gün boyunca eşit bir şekilde dağıtılır. Buna bağlı olarak ölçeği dinamik olarak genişletmeniz gerekebilir. Ölçeği ne zaman genişletmeniz ve daraltmanız gerekeceğini tahmin etmeyi öğrenebilirsiniz, ancak her iki durumda da büyük olasılıkla hizmetiniz tarafından değişen kaynak tüketimine tepki vermeniz gerekir. Bu, mevcut kaynakların yeniden düzenlenmesi yeterli olmadığında daha fazla kaynak sağlamak için kümenin boyutunu değiştirmeyi içerebilir.

Ama neden tüm kullanıcılar için tek bir bölüm düzeni seçmeye çalışsın? Neden kendinizi bir hizmet ve bir statik kümeyle sınırlamalısınız? Gerçek durum genellikle daha dinamiktir.

Ölçek için oluştururken aşağıdaki dinamik deseni göz önünde bulundurun. Bu durumu kendi durumunuzla uyarlamanız gerekebilir:

1. Herkes için bir bölümleme düzeni seçmeye çalışmak yerine bir "yönetici hizmeti" oluşturun.
2. Yönetici hizmetinin görevi, hizmetinize kaydolan müşteri bilgilerine bakmaktır. Ardından bu bilgilere bağlı olarak, yönetici hizmeti yalnızca bu müşteri için gerçek kişi depolama hizmetinizin bir örneğini oluşturur. Belirli yapılandırma, yalıtım veya yükseltme gerekiyorsa, bu müşteri için bir Uygulama örneği de oluşturabilirsiniz.

Bu dinamik oluşturma deseni birçok avantaj sunar:

• Ön taraftaki tüm kullanıcılar için doğru bölüm sayısını tahmin etmeye veya kendi başına sonsuz ölçeklenebilir tek bir hizmet oluşturmaya çalışmıyorsunuz.
• Farklı kullanıcıların aynı bölüm sayısına, çoğaltma sayısına, yerleştirme kısıtlamalarına, ölçümlere, varsayılan yüklere, hizmet adlarına, dns ayarlarına veya hizmet veya uygulama düzeyinde belirtilen diğer özelliklerden herhangi birine sahip olması gerekmez.
• Ek veri segmentasyonu elde edebilirsiniz. Her müşterinin kendi hizmet kopyası vardır
  • Her müşteri hizmeti farklı yapılandırılabilir ve beklenen ölçeğe göre gerektiğinde daha fazla veya daha az bölüm veya çoğaltma ile daha fazla veya daha az kaynak verilebilir.
    • Örneğin müşterinin "Gold" katmanı için ödeme yaptıklarını varsayalım; daha fazla çoğaltma veya daha fazla bölüm sayısı elde edebilir ve ölçümler ve uygulama kapasiteleri aracılığıyla hizmetlerine ayrılmış olabilecek kaynaklar elde edebilir.
    • Ya da ihtiyaç duydukları kişi sayısının "Küçük" olduğunu belirten bilgiler sağladıklarını varsayalım; yalnızca birkaç bölüm alabilirler, hatta diğer müşterilerle paylaşılan bir hizmet havuzuna bile yerleştirilebilirler.
• Müşterilerin görünmesini beklerken bir dizi hizmet örneği veya çoğaltma çalıştırmıyorsunuz
• Bir müşteri ayrılırsa, bilgilerini hizmetinizden kaldırmak, yöneticinin oluşturduğu hizmeti veya uygulamayı silmesi kadar basittir.

Sonraki adımlar

Service Fabric kavramları hakkında daha fazla bilgi için aşağıdaki makalelere bakın:

• Service Fabric hizmetlerinin kullanılabilirliği
• Service Fabric hizmetlerini bölümleme