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ını sağlar, ancak iş yüklerinizi ölçeklendirmeyi seçme yönteminiz açısından esneklik de sağlar. Bu Channel 9 videosu, ölçeklenebilir mikro hizmet uygulamalarını nasıl oluşturabileceğinizi açıklar:

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 tanımlama InstanceCountfırsatı elde edersiniz. InstanceCount , hizmet başlatıldığında bu hizmet kodunun kaç ç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ştirmenin otomatik bir yolunu 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 olarak 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 hizmetlerdeki yükün azalmasına olanak tanır. Hizmet oluştururken Service Fabric Kümesi Resource Manager hizmetleri kümeye dağıtılmış bir şekilde 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ı New-ServiceFabricServiceCreateServiceAsyncyapan biri gibi 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 hizmeti düşünün. çalışmayı temsil eden çağrılar bu hizmette gösterilir ve bu hizmet bu iş akışının adımlarını yürütecek ve ilerleme durumunu kaydedecek.

Bu hizmeti nasıl ölçeklendirirsiniz? Hizmet bir biçimde çok kiracılı olabilir ve aynı iş akışının birçok farklı örneği için aynı anda çağrıları kabul edebilir ve adımları 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ı aynı anda işlemek ö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 oluşturulmamış birçok hizmet, kendi kodlarındaki bazı doğal performans sorunları veya yavaşlama nedeniyle 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 hizmetin durum bilgisi olmayan veya durum bilgisi olan hizmetlerde çalışır. Bu düzenin çalışması için genellikle "İş Yükü Yöneticisi Hizmeti" olarak davranan 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 geçirebilir. 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 bu örneğini silebilir veya daha fazla çağrı bekleniyorsa bırakabilir.

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önlendirebilir. 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 de popüler bir yönetici düzenidir. Bu, hizmetin şu anda beklemede olan çalışma miktarının bir kısmını izlemeye dayalı olarak hizmetleri oluşturma ve silme işlemidir.

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, kodunun belirli bir kimlik veya güvenlik ayarları altında çalıştırılması 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 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 muhtemelen kodunu aynı bağlamda (işlem alanı) etkinleştirmek istemezsiniz. Bunu yapmak, hizmet kodunuzun belirli bir kimlik bağlamında işlem yapmalarını 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ı yapılandırırken bunu yapmak karmaşık bir işlemdir. Hizmetlerin yapılandırmalarını bir yapılandırma paketi içinde aramak için kullandıkları bazı belirteçleri olmalıdır. Genellikle bu yalnızca hizmetin adıdır. Bu işlem 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ğıtarak yeni hizmetlerin kendi özel bilgilerini arayabilmesi için daha fazla uygulama yükseltmesi anlamına gelir. 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ştirmeleri içeren tek bir yapılandırma dosyası yerine, bu ayarları geçersiz kılarak her müşteri için farklı bir uygulama örneğiniz olur.
• 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ükseltimi, 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çeklendirmeden 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ğı hizmet 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ı düzeyi sağlar ve ayrıca A/B testini ve Mavi/Yeşil dağıtımlarını 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ği belirli bir ölçüm için kapasite dışıdır. 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 durumu tek seferde 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ü dağıtılır ve hizmetin tamamı veya herhangi bir bölümün 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 şeması 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 birlikte yerleştirilebilir:

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ı sağlar. Genellikle, her hizmetin kullanabileceği daha fazla kaynak olduğundan performansı da artırır.

Service Fabric Kümesi Resource Manager ve ölçümlerini kullanarak ölçeklendirme

Ölçümler , hizmetlerin kaynak tüketimini Service Fabric'e nasıl ifade ettikleridir. Ölçümlerin kullanılması, Küme Resource Manager 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 Resource Manager 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 tümü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 Resource Manager hizmetleri bunlara taşır ve bu da mevcut düğümlerde toplam yükün daha az olmasını sağlar. Ö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 farklılıklar, Service Fabric küme 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. Aşağıdaki hizmeti göz önünde bulundurun: Adlara ve iletişim bilgilerine bağlı olarak adres defteri işlevi gören 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 bunların hepsini anlamaya çalışmak zordur. Belirli bir bölüm sayısıyla tek bir statik hizmet kullanacağını 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 boyutları açısından kümenin boyutuna önceden karar vermeniz 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 olarak dağıtılır. Buna bağlı olarak ölçeği genişletmeniz ve dinamik olarak daraltmanız gerekebilir. Ölçeği genişletmeniz ve daraltmanız gerekeceği zamanları 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.

Ancak neden tüm kullanıcılar için tek bir bölüm düzeni seçmeye çalışıyorsunuz? 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. Bunu 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çingerçek kişi depolama hizmetinizin bir örneğini oluşturur. Belirli bir 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:

• Öndeki tüm kullanıcılar için doğru bölüm sayısını tahmin etmeye çalışmıyorsunuz veya tek başına sınırsız olarak ölçeklenebilir tek bir hizmet oluşturmuyorsunuz.
• 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ı ile ölçümler ve uygulama kapasiteleri aracılığıyla hizmetlerine ayrılmış 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österilmesini beklerken bir grup 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 kolaydır.

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