Aracılığıyla paylaş


Azure Service Fabric barındırma modeli

Bu makale, Azure Service Fabric tarafından sağlanan uygulama barındırma modellerine genel bir bakış sağlar ve Paylaşılan İşlem ile Özel İşlem modelleri arasındaki farkları açıklar. Dağıtılan bir uygulamanın Service Fabric düğümünde nasıl göründüğünü ve hizmetin çoğaltmaları (veya örnekleri) ile hizmet konağı işlemi arasındaki ilişkiyi açıklar.

Devam etmeden önce Service Fabric'te bir uygulamayı modelleme başlığında açıklanan çeşitli kavramları ve ilişkileri anladığınızdan emin olun.

Not

Bu makalede, açıkça farklı bir anlam ifade etmediği sürece:

  • Çoğaltma hem durum bilgisi olan bir hizmetin çoğaltmasına hem de durum bilgisi olmayan bir hizmetin örneğine başvurur.
  • CodePackage, ServiceType'ı kaydeden ve bu ServiceType hizmetinin çoğaltmalarını barındıran bir ServiceHost işlemine eşdeğer olarak değerlendirilir.

Barındırma modelini anlamak için bir örneği inceleyelim. ServiceType 'MyServiceType' olan bir ApplicationType 'MyAppType' olduğunu varsayalım. 'MyServiceType', 'MyCodePackage' CodePackage'ı olan 'MyServicePackage' ServicePackage tarafından sağlanır. 'MyCodePackage', çalıştığında 'MyServiceType' ServiceType'ı kaydeder.

Üç düğümlü bir kümemiz olduğunu ve 'MyAppType' türünde bir application fabric:/App1 oluşturduğumuz varsayalım. Bu uygulama dokusunun içinde:/App1, 'MyServiceType' türünde bir service fabric:/App1/ServiceA oluştururuz. Bu hizmetin iki bölümü (örneğin, P1 ve P2) ve bölüm başına üç çoğaltması vardır. Aşağıdaki diyagramda, bir düğüme dağıtıldığında bu uygulamanın görünümü gösterilmektedir.

Bir düğüme dağıtılırken bu uygulamanın görünümünü gösteren diyagram.

Service Fabric, her iki bölümden çoğaltmaları barındıran 'MyCodePackage'ı başlatan 'MyServicePackage'ı etkinleştirdi. Bölüm başına çoğaltma sayısını kümedeki düğüm sayısına eşit olarak seçtiğimiz için kümedeki tüm düğümler aynı görünüme sahiptir. Şimdi application fabric:/App1/ServiceB olarak başka bir hizmet oluşturalım: application fabric:/App1. Bu hizmetin bir bölümü (örneğin, P3) ve bölüm başına üç çoğaltması vardır. Aşağıdaki diyagramda düğümdeki yeni görünüm gösterilmektedir:

Düğümdeki yeni görünümü gösteren diyagram.

Service Fabric, service fabric:/App1/ServiceB'nin P3 bölümü için yeni çoğaltmayı mevcut 'MyServicePackage' etkinleştirmesine yerleştirdi. Şimdi. Şimdi 'MyAppType' türünde başka bir application fabric:/App2 oluşturalım. Doku :/App2 içinde bir service fabric:/App2/ServiceA oluşturun. Bu hizmetin iki bölümü (P4 ve P5) ve bölüm başına üç çoğaltması vardır. Aşağıdaki diyagramda yeni düğüm görünümü gösterilmektedir:

Yeni düğüm görünümünü gösteren diyagram.

Service Fabric, 'MyCodePackage' öğesinin yeni bir kopyasını başlatan yeni bir 'MyServicePackage' kopyasını etkinleştirir. Service Fabric:/App2/ServiceA'nın (P4 ve P5) her iki bölümünden çoğaltmalar bu yeni 'MyCodePackage' kopyasına yerleştirilir.

Paylaşılan İşlem modeli

Yukarıdaki bölümde, Service Fabric tarafından sağlanan ve Paylaşılan İşlem modeli olarak adlandırılan varsayılan barındırma modeli açıklanmaktadır. Bu modelde, belirli bir uygulama için düğümde belirli bir ServicePackage'ın yalnızca bir kopyası etkinleştirilir (bu, içindeki tüm CodePackage'ları başlatır). Belirli bir ServiceType'ın tüm hizmetlerinin tüm çoğaltmaları, bu ServiceType'ı kaydeden CodePackage'a yerleştirilir. Başka bir deyişle, belirli bir ServiceType düğümündeki tüm hizmetlerin tüm çoğaltmaları aynı işlemi paylaşır.

Özel İşlem modeli

Service Fabric tarafından sağlanan diğer barındırma modeli, Özel İşlem modelidir. Bu modelde, belirli bir düğümde her çoğaltma kendi ayrılmış işleminde yer alır. Service Fabric, ServicePackage'ın yeni bir kopyasını etkinleştirir (içindeki tüm CodePackage'ları başlatır). Çoğaltmalar, çoğaltmanın ait olduğu hizmetin ServiceType'ını kaydeden CodePackage'a yerleştirilir.

Service Fabric sürüm 5.6 veya üzerini kullanıyorsanız, bir hizmet oluştururken (PowerShell, REST veya FabricClient kullanarak) Özel İşlem modelini seçebilirsiniz. ServicePackageActivationMode'u 'ExclusiveProcess' olarak belirtin.

PS C:\>New-ServiceFabricService -ApplicationName "fabric:/App1" -ServiceName "fabric:/App1/ServiceA" -ServiceTypeName "MyServiceType" -Stateless -PartitionSchemeSingleton -InstanceCount -1 -ServicePackageActivationMode "ExclusiveProcess"
var serviceDescription = new StatelessServiceDescription
{
    ApplicationName = new Uri("fabric:/App1"),
    ServiceName = new Uri("fabric:/App1/ServiceA"),
    ServiceTypeName = "MyServiceType",
    PartitionSchemeDescription = new SingletonPartitionSchemeDescription(),
    InstanceCount = -1,
    ServicePackageActivationMode = ServicePackageActivationMode.ExclusiveProcess
};

var fabricClient = new FabricClient(clusterEndpoints);
await fabricClient.ServiceManager.CreateServiceAsync(serviceDescription);

Uygulama bildiriminizde varsayılan bir hizmet varsa, ServicePackageActivationMode özniteliğini belirterek Özel İşlem modelini seçebilirsiniz:

<DefaultServices>
  <Service Name="MyService" ServicePackageActivationMode="ExclusiveProcess">
    <StatelessService ServiceTypeName="MyServiceType" InstanceCount="1">
      <SingletonPartition/>
    </StatelessService>
  </Service>
</DefaultServices>

Şimdi application fabric:/App1'de fabric:/App1/ServiceC gibi başka bir hizmet oluşturalım. Bu hizmetin iki bölümü (örneğin, P6 ve P7) ve bölüm başına üç çoğaltması vardır. ServicePackageActivationMode'u 'ExclusiveProcess' olarak ayarladınız. Aşağıdaki diyagramda düğümdeki yeni görünüm gösterilmektedir:

Dağıtılan uygulamanın düğüm görünümü diyagramı

Gördüğünüz gibi, Service Fabric 'MyServicePackage' öğesinin iki yeni kopyasını etkinleştirdi (P6 ve P7 bölümündeki her çoğaltma için bir kopya). Service Fabric her çoğaltmayı codepackage'ın ayrılmış kopyasına yerleştirmiştir. Özel Kullanım İşlemi modelini kullandığınızda, belirli bir uygulama için belirli bir ServicePackage'ın birden çok kopyası bir düğümde etkin olabilir. Yukarıdaki örnekte doku:/App1 için 'MyServicePackage' öğesinin üç kopyası etkindir. Bu etkin 'MyServicePackage' kopyalarının her birinde kendisiyle ilişkilendirilmiş bir ServicePackageActivationId vardır. Bu kimlik, bu kopyayı application fabric:/App1 içinde tanımlar.

Bir uygulama için yalnızca Paylaşılan İşlem modelini kullandığınızda, düğümde yalnızca bir etkin ServicePackage kopyası vardır. ServicePackage'ın bu etkinleştirilmesi için ServicePackageActivationId boş bir dizedir. Örneğin doku:/App2 ile bu durum söz konusudur.

Not

  • Paylaşılan İşlem barındırma modeli ServicePackageActivationMode eşittir SharedProcess'e karşılık gelir. Bu varsayılan barındırma modelidir ve ServicePackageActivationMode hizmeti oluştururken belirtilmez.

  • Özel İşlem barındırma modeli, ServicePackageActivationMode eşittir ExclusiveProcess'e karşılık gelir. Bu ayarı kullanmak için, hizmeti oluştururken açıkça belirtmeniz gerekir.

  • Bir hizmetin barındırma modelini görüntülemek için hizmet açıklamasını sorgulayıp ServicePackageActivationMode değerine bakın.

Dağıtılan hizmet paketiyle çalışma

Bir düğümdeki ServicePackage'ın etkin bir kopyası, dağıtılan hizmet paketi olarak adlandırılır. Belirli bir uygulama için hizmet oluşturmak için Özel Kullanım İşlemi modelini kullandığınızda, aynı ServicePackage için birden çok dağıtılmış hizmet paketi olabilir. Dağıtılan bir hizmet paketine özgü işlemler gerçekleştiriyorsanız, dağıtılan belirli bir hizmet paketini tanımlamak için ServicePackageActivationId sağlamanız gerekir. Örneğin, dağıtılan bir hizmet paketinin durumunu bildiriyorsanız veya dağıtılan hizmet paketinin kod paketini yeniden başlatıyorsanız kimliği belirtin.

Bir düğümdeki dağıtılmış hizmet paketlerinin listesini sorgulayarak dağıtılan bir hizmet paketinin ServicePackageActivationId değerini öğrenebilirsiniz. Bir düğümde dağıtılan hizmet türlerini, dağıtılan çoğaltmaları ve dağıtılan kod paketlerini sorgularken, sorgu sonucu üst dağıtılan hizmet paketinin ServicePackageActivationId değerini de içerir.

Not

  • Paylaşılan İşlem barındırma modeli altında, belirli bir düğümde, belirli bir uygulama için ServicePackage'ın yalnızca bir kopyası etkinleştirilir. Boş dizeye eşit bir ServicePackageActivationId değerine sahiptir ve dağıtılan hizmet paketiyle ilgili işlemler gerçekleştirilirken belirtilmesi gerekmez.

  • Özel Kullanım İşlemi barındırma modeli altında, belirli bir düğümde, belirli bir uygulama için ServicePackage'ın bir veya daha fazla kopyası etkin olabilir. Her etkinleştirme, dağıtılan hizmet paketiyle ilgili işlemler gerçekleştirilirken belirtilen boş olmayan bir ServicePackageActivationId değerine sahiptir.

  • ServicePackageActivationId belirtilmezse, varsayılan olarak boş dize olur. Paylaşılan İşlem modeli altında etkinleştirilen dağıtılmış bir hizmet paketi varsa, işlem üzerinde gerçekleştirilir. Aksi takdirde işlem başarısız olur.

  • Bir kez sorgulamayın ve ServicePackageActivationId değerini önbelleğe alın. Kimlik dinamik olarak oluşturulur ve çeşitli nedenlerle değişebilir. ServicePackageActivationId gerektiren bir işlemi gerçekleştirmeden önce düğümde dağıtılan hizmet paketlerinin listesini sorgulamanız gerekir. Ardından, özgün işlemi gerçekleştirmek için sorgu sonucundaki ServicePackageActivationId değerini kullanın.

Konuk yürütülebilir dosyası ve kapsayıcı uygulamaları

Service Fabric , konuk yürütülebilir dosyaları ve kapsayıcı uygulamalarını kendi içinde bulunan durum bilgisi olmayan hizmetler olarak kabul eder. ServiceHost'ta (işlem veya kapsayıcı) Service Fabric çalışma zamanı yoktur. Bu hizmetler kendi içinde olduğundan, ServiceHost başına çoğaltma sayısı bu hizmetler için geçerli değildir. Bu hizmetlerle kullanılan en yaygın yapılandırma tek bölümdür ve InstanceCount değeri -1'e eşittir (kümenin her düğümünde çalışan hizmet kodunun bir kopyası).

Bu hizmetler için varsayılan ServicePackageActivationMode SharedProcess'dir. Bu durumda Service Fabric, belirli bir uygulama için düğümde servicePackage'ın yalnızca bir kopyasını etkinleştirir. Bu, hizmet kodunun yalnızca bir kopyasının bir düğümü çalıştıracağı anlamına gelir. Hizmet kodunuzun birden çok kopyasının bir düğümde çalışmasını istiyorsanız, hizmeti oluştururken ExclusiveProcess olarak ServicePackageActivationMode değerini belirtin. Örneğin, serviceType'ın birden çok hizmetini (Service1'i ServiceN'ye) oluşturduğunuzda (ServiceManifest'te belirtilen) veya hizmetiniz çok bölümlü olduğunda bunu yapabilirsiniz.

Mevcut bir hizmetin barındırma modelini değiştirme

Şu anda, mevcut bir hizmetin barındırma modelini Paylaşılan İşlemden Özel Kullanım sürecine (veya tam tersi) değiştiremezsiniz.

Barındırma modelleri arasında seçim yapma

Gereksinimlerinize en uygun barındırma modelini değerlendirmeniz gerekir. Paylaşılan İşlem modeli işletim sistemi kaynaklarını daha iyi kullanır çünkü daha az işlem oluşturulur ve aynı işlemdeki birden çok çoğaltma bağlantı noktalarını paylaşabilir. Ancak, çoğaltmalardan biri hizmet ana bilgisayarını düşürmesi gereken bir hataya sahipse, aynı işlemdeki diğer tüm çoğaltmaları etkiler.

Özel İşlem modeli, her çoğaltmanın kendi işleminde daha iyi yalıtım sağlar. Çoğaltmalardan birinde hata varsa, diğer çoğaltmaları etkilemez. Bu model, bağlantı noktası paylaşımının iletişim protokolü tarafından desteklenmediği durumlarda kullanışlıdır. Çoğaltma düzeyinde kaynak idaresi uygulama olanağını kolaylaştırır. Ancak Özel Kullanım İşlemi, düğümdeki her çoğaltma için bir işlem oluşturarak daha fazla işletim sistemi kaynağı tüketir.

Özel süreç modeli ve uygulama modeliyle ilgili dikkat edilmesi gerekenler

Çoğu uygulama için, ServicePackage başına bir ServiceType tutarak uygulamanızı Service Fabric'te modelleyebilirsiniz.

Bazı durumlarda Service Fabric, ServicePackage başına birden fazla ServiceType'a da izin verir (ve bir CodePackage birden fazla ServiceType kaydedebilir). Bu yapılandırmaların yararlı olabileceği senaryolardan bazıları şunlardır:

  • Daha az işlem ortaya çıkarır ve işlem başına daha yüksek çoğaltma yoğunluğuna sahip olarak kaynak kullanımını iyileştirmek istersiniz.
  • Farklı ServiceType'lardan çoğaltmaların , yüksek başlatma veya bellek maliyeti olan bazı ortak verileri paylaşması gerekir.
  • Ücretsiz bir hizmet teklifiniz var ve hizmetin tüm çoğaltmalarını aynı işleme koyarak kaynak kullanımına bir sınır koymak istiyorsunuz.

Özel İşlem barındırma modeli, ServicePackage başına birden çok ServiceType'a sahip bir uygulama modeliyle uyumlu değildir. Bunun nedeni, ServicePackage başına birden çok ServiceType'ın çoğaltmalar arasında daha yüksek kaynak paylaşımı elde etmek için tasarlanmış olması ve işlem başına daha yüksek çoğaltma yoğunluğuna olanak tanımasıdır. Özel İşlem modeli farklı sonuçlar elde etmek için tasarlanmıştır.

Her ServiceType'ı kaydeden farklı bir CodePackage ile ServicePackage başına birden çok ServiceType örneğini göz önünde bulundurun. İki CodePackage içeren bir ServicePackage 'MultiTypeServicePackage' olduğunu varsayalım:

  • 'MyServiceTypeA' ServiceType'ı kaydeden 'MyCodePackageA'.
  • 'MyServiceTypeB' ServiceType'ı kaydeden 'MyCodePackageB'.

Şimdi fabric:/SpecialApp şeklinde bir uygulama oluşturduğumuz düşünelim. Fabric:/SpecialApp içinde, Özel Kullanım İşlemi modeliyle aşağıdaki iki hizmeti oluşturuyoruz:

  • İki bölüm (örneğin, P1 ve P2) ve bölüm başına üç çoğaltma içeren 'MyServiceTypeA' türündeki Service fabric:/SpecialApp/ServiceA.
  • İki bölüm (P3 ve P4) ve bölüm başına üç çoğaltma içeren 'MyServiceTypeB' türündeki Service fabric:/SpecialApp/ServiceB.

Belirli bir düğümde her iki hizmetin de her biri iki çoğaltmaya sahiptir. Hizmetleri oluşturmak için Özel İşlem modelini kullandığımızdan, Service Fabric her çoğaltma için yeni bir 'MyServicePackage' kopyasını etkinleştirir. Her 'MultiTypeServicePackage' etkinleştirmesi 'MyCodePackageA' ve 'MyCodePackageB' kopyalarını başlatır. Ancak, 'MultiTypeServicePackage' öğesinin etkinleştirildiği çoğaltmayı yalnızca 'MyCodePackageA' veya 'MyCodePackageB' barındırıyor. Aşağıdaki diyagramda düğüm görünümü gösterilmektedir:

Düğüm görünümünü gösteren diyagram.

Service Fabric:/SpecialApp/ServiceA'nın bölüm P1'inin çoğaltması için 'MultiTypeServicePackage' etkinleştirmesinde, çoğaltmayı 'MyCodePackageA' barındırılıyor. 'MyCodePackageB' çalışıyor. Benzer şekilde, service fabric:/SpecialApp/ServiceB'nin P3 bölümünün çoğaltması için 'MultiTypeServicePackage' etkinleştirmesinde, çoğaltmayı 'MyCodePackageB' barındırılır. 'MyCodePackageA' çalışıyor. Bu nedenle, ServicePackage başına CodePackage sayısı (farklı ServiceType'ları kaydetme) ne kadar fazla olursa, yedekli kaynak kullanımı o kadar yüksek olur.

Ancak, Paylaşılan İşlem modeliyle services fabric:/SpecialApp/ServiceA ve fabric:/SpecialApp/ServiceB oluşturursak, Service Fabric uygulama dokusu:/SpecialApp için yalnızca bir 'MultiTypeServicePackage' kopyasını etkinleştirir. 'MyCodePackageA' service fabric:/SpecialApp/ServiceA için tüm çoğaltmaları barındırıyor. 'MyCodePackageB' service fabric:/SpecialApp/ServiceB için tüm çoğaltmaları barındırıyor. Aşağıdaki diyagramda bu ayardaki düğüm görünümü gösterilmektedir:

Dağıtılan uygulamanın düğüm görünümünün diyagramı

Yukarıdaki örnekte, 'MyCodePackageA' hem 'MyServiceTypeA' hem de 'MyServiceTypeB' kaydediyorsa ve 'MyCodePackageB' yoksa, çalışan yedekli CodePackage olmadığını düşünebilirsiniz. Bu doğru olsa da, bu uygulama modeli Özel İşlem barındırma modeliyle uyumlu değildir. Amaç her çoğaltmayı kendi ayrılmış işlemine yerleştirmekse, aynı CodePackage'dan her iki ServiceType'ı da kaydetmeniz gerekmez. Bunun yerine, her ServiceType'ı kendi ServicePackage'sine yerleştirmeniz yeterlidir.

Reliable Services ve Actor çatallama alt işlemcileri

Service Fabric, güvenilir hizmetleri ve daha sonra güvenilir aktörlerin alt işlemleri çatallamasını desteklemez. Desteklenmeyen bir alt işlemi kaydetmek için CodePackageActivationContext kullanılamaz ve iptal belirteçleri yalnızca kayıtlı işlemlere gönderilir; bu da üst işlem iptal belirteci aldıktan sonra alt işlemler kapatılmadığında yükseltme hataları gibi her türlü soruna yol açar.

Sonraki adımlar

Bir uygulamayı paketleyin ve dağıtmaya hazırlayın.

Uygulamaları dağıtma ve kaldırma. Bu makalede, uygulama örneklerini yönetmek için PowerShell'in nasıl kullanılacağı açıklanmaktadır.