Partition Service Fabric güvenilir hizmetleri

  • Makale

Bu makalede, Azure Service Fabric güvenilir hizmetlerini bölümlemeyle ilgili temel kavramlara giriş bilgileri sağlanmaktadır. Bölümleme, verilerin ve işlemlerin birlikte ölçeklendirilebilmesi için yerel makinelerde veri depolamayı etkinleştirir.

İpucu

Bu makaledeki kodun eksiksiz bir örneğini GitHub'da bulabilirsiniz.

Bölümleme

Bölümleme Service Fabric için benzersiz değildir. Aslında, ölçeklenebilir hizmetler oluşturmanın temel desenidir. Daha geniş anlamda bölümlemesi, durumu (verileri) bölme kavramı olarak düşünebilir ve ölçeklenebilirliği ve performansı geliştirmek için işlemi daha küçük erişilebilir birimlere ayırabiliriz. Bölümlemenin iyi bilinen bir biçimi, parçalama olarak da bilinen veri bölümlemedir.

Service Fabric durum bilgisi olmayan hizmetleri bölümleme

Durum bilgisi olmayan hizmetler için, bir bölümün bir veya daha fazla hizmet örneğini içeren mantıksal bir birim olduğunu düşünebilirsiniz. Şekil 1'de, bir bölüm kullanılarak kümeye dağıtılmış beş örneği olan durum bilgisi olmayan bir hizmet gösterilmektedir.

Durum bilgisi olmayan hizmet

Gerçekten iki tür durum bilgisi olmayan hizmet çözümü vardır. birincisi, örneğin Azure SQL Veritabanı'ndaki bir veritabanında (oturum bilgilerini ve verileri depolayan bir web sitesi gibi) durumunu harici olarak kalıcı hale getiren bir hizmettir. İkincisi, herhangi bir kalıcı durumu yönetmeyen yalnızca hesaplama hizmetleridir (hesap makinesi veya görüntü küçük resim oluşturma gibi).

Her iki durumda da durum bilgisi olmayan bir hizmetin bölümlenmesi çok nadir bir senaryodur; ölçeklenebilirlik ve kullanılabilirlik normalde daha fazla örnek eklenerek elde edilir. Durum bilgisi olmayan hizmet örnekleri için birden çok bölümü dikkate almak istediğiniz tek zaman, özel yönlendirme isteklerini karşılamanız gerektiği zamandır.

Örneğin, belirli bir aralıkta kimlikleri olan kullanıcıların yalnızca belirli bir hizmet örneği tarafından hizmet verilmesi gerektiğini düşünün. Durum bilgisi olmayan bir hizmeti bölümleyebileceğiniz bir diğer örnek, gerçekten bölümlenmiş bir arka uçtan (örneğin, SQL Veritabanı parçalı bir veritabanına) sahip olmanız ve hangi hizmet örneğinin veritabanı parçasına yazılması gerektiğini denetlemek veya durum bilgisi olmayan hizmette arka uçta kullanılan bölümleme bilgilerinin aynısını gerektiren başka bir hazırlık çalışması gerçekleştirmek istemenizdir. Bu tür senaryolar farklı yollarla da çözülebilir ve hizmet bölümlemesi gerekmez.

Bu kılavuzun geri kalanı durum bilgisi olan hizmetlere odaklanır.

Service Fabric durum bilgisi olan hizmetleri bölümleme

Service Fabric, durumu (verileri) bölümlemenin birinci sınıf bir yolunu sunarak durum bilgisi olan ölçeklenebilir hizmetler geliştirmeyi kolaylaştırır. Kavramsal olarak, durum bilgisi olan bir hizmetin bir bölümünü, kümedeki düğümler arasında dağıtılan ve dengelenen çoğaltmalar aracılığıyla son derece güvenilir bir ölçek birimi olarak düşünebilirsiniz.

Service Fabric durum bilgisi olan hizmetler bağlamında bölümleme, belirli bir hizmet bölümünün hizmetin tam durumunun bir bölümünden sorumlu olduğunu belirleme işlemini ifade eder. (Daha önce belirtildiği gibi, bölüm bir çoğaltma kümesidir). Service Fabric'in harika bir özelliği, bölümleri farklı düğümlere yerleştirmiş olmasıdır. Bu, bir düğümün kaynak sınırına kadar büyümelerini sağlar. Veri gereksinimleri arttıkça bölümler büyür ve Service Fabric düğümler arasında bölümleri yeniden dengeler. Bu, donanım kaynaklarının sürekli verimli kullanılmasını sağlar.

Size bir örnek vermek gerekirse, 5 düğümlü bir kümeyle ve 10 bölüme ve üç çoğaltma hedefi olacak şekilde yapılandırılmış bir hizmetle başladığınızı varsayalım. Bu durumda, Service Fabric çoğaltmaları kümede dengeleyip dağıtır ve düğüm başına iki birincil çoğaltma elde edebilirsiniz. Şimdi kümenin ölçeğini 10 düğüme genişletmeniz gerekiyorsa Service Fabric, birincil çoğaltmaları 10 düğümün tümü arasında yeniden dengeler . Benzer şekilde, 5 düğüme geri ölçeklendirdiyseniz Service Fabric 5 düğümdeki tüm çoğaltmaları yeniden dengeler.

Şekil 2'de küme ölçeklendirilmeden önce ve sonra 10 bölümün dağılımı gösterilmektedir.

Durum bilgisi olan hizmet

Sonuç olarak, istemcilerden gelen istekler bilgisayarlar arasında dağıtıldığı, uygulamanın genel performansı iyileştirildiğinden ve veri öbeklerine erişim çekişmesi azaldığından ölçeği genişletme elde edilir.

Bölümleme için planlama

Bir hizmeti uygulamadan önce, ölçeği genişletmek için gereken bölümleme stratejisini her zaman göz önünde bulundurmanız gerekir. Farklı yollar vardır, ancak hepsi uygulamanın başarması gerekenlere odaklanır. Bu makalenin bağlamı için daha önemli bazı konuları ele alalım.

İyi bir yaklaşım, bölümlenmesi gereken durumun yapısını ilk adım olarak düşünmektir.

Basit bir örnek alalım. İlçe genelinde bir anket için bir hizmet oluşturacaksanız, ilçedeki her şehir için bir bölüm oluşturabilirsiniz. Ardından, şehirdeki her kişi için oyları o şehre karşılık gelen bölümde depolayabilirsiniz. Şekil 3'te bir kişi kümesi ve bulundukları şehir gösterilmektedir.

Basit bölüm

Şehirlerin nüfusu yaygın olarak değiştiğinden, çok fazla veri (örneğin Seattle) içeren bazı bölümler ve çok az eyaletli (örneğin Kirkland) diğer bölümlere sahip olabilirsiniz. Peki eşit olmayan durum değerlerine sahip bölümlere sahip olmanın etkisi nedir?

Örneği yeniden düşünürseniz Seattle için oyları tutan bölümün Kirkland'dan daha fazla trafik alabileceğini kolayca görebilirsiniz. Varsayılan olarak, Service Fabric her düğümde yaklaşık aynı sayıda birincil ve ikincil çoğaltma olduğundan emin olur. Bu nedenle, daha fazla trafiğe hizmet eden çoğaltmaları ve daha az trafiğe hizmet eden diğer çoğaltmaları barındıran düğümlerle karşılaşabilirsiniz. Tercihen kümede bunun gibi sık ve soğuk noktalardan kaçınmak istersiniz.

Bunu önlemek için, bölümleme açısından iki şey yapmanız gerekir:

  • Durumu tüm bölümlere eşit olarak dağıtacak şekilde bölümlemeye çalışın.
  • Hizmet için çoğaltmaların her birinden rapor yükü. (Nasıl olduğu hakkında bilgi için Ölçümler ve Yükleme ile ilgili bu makaleye göz atın). Service Fabric, bellek miktarı veya kayıt sayısı gibi hizmetler tarafından tüketilen yükü raporlama özelliği sağlar. Service Fabric, bildirilen ölçümlere göre bazı bölümlerin diğerlerinden daha yüksek yüklere hizmet ettiğini algılar ve çoğaltmaları daha uygun düğümlere taşıyarak kümeyi yeniden dengeler; böylece genel olarak hiçbir düğüm aşırı yüklenmez.

Bazen, belirli bir bölümde ne kadar veri olacağını bilemezsinsiniz. Bu nedenle genel bir öneri her ikisini de yapmaktır. İlk olarak, verileri bölümlere eşit olarak yayan bir bölümleme stratejisini benimseyerek ve ikinci olarak da yükü bildirerek. İlk yöntem oylama örneğinde açıklanan durumları önlerken, ikincisi zaman içinde erişim veya yükleme arasındaki geçici farklılıkları düzeltmeye yardımcı olur.

Bölüm planlamasının bir diğer yönü de, başlangıç olarak doğru bölüm sayısını seçmektir. Service Fabric perspektifinden bakıldığında, senaryonuz için beklenenden daha fazla sayıda bölümle başlamanızı engelleyen hiçbir şey yoktur. Aslında, bölüm sayısı üst sınırının geçerli bir yaklaşım olduğunu varsayarsak.

Nadir durumlarda, başlangıçta seçtiğinizden daha fazla bölüme ihtiyacınız olabilir. Sonuçtan sonra bölüm sayısını değiştiremediğiniz için, aynı hizmet türünde yeni bir hizmet örneği oluşturma gibi bazı gelişmiş bölüm yaklaşımlarını uygulamanız gerekir. ayrıca, istemci kodunuzun tutması gereken istemci tarafı bilgisine dayanarak istekleri doğru hizmet örneğine yönlendiren bazı istemci tarafı mantığı uygulamanız gerekir.

Bölümleme planlaması için dikkat edilmesi gereken bir diğer nokta da kullanılabilir bilgisayar kaynaklarıdır. Duruma erişilmesi ve depolanması gerektiğinden, aşağıdakileri izlemeniz gerekir:

  • Ağ bant genişliği sınırları
  • Sistem belleği sınırları
  • Disk depolama sınırları

Çalışan bir kümede kaynak kısıtlamalarıyla karşılaşırsanız ne olur? Yanıt, yeni gereksinimleri karşılamak için kümenin ölçeğini genişletebilmenizdir.

Kapasite planlama kılavuzu , kümenizin kaç düğüme ihtiyacı olduğunu belirlemeye yönelik yönergeler sunar.

Bölümleme ile çalışmaya başlama

Bu bölümde hizmetinizi bölümlemeye nasıl başlandığı açıklanmaktadır.

Service Fabric üç bölüm düzeni seçeneği sunar:

  • Aralıklı bölümleme (UniformInt64Partition olarak da bilinir).
  • Adlandırılmış bölümleme. Bu modeli kullanan uygulamalar genellikle sınırlanmış küme içinde demetlenmiş verilere sahiptir. Adlandırılmış bölüm anahtarları olarak kullanılan veri alanlarına örnek olarak bölgeler, posta kodları, müşteri grupları veya diğer iş sınırları verilebilir.
  • Singleton bölümleme. Tekli bölümler genellikle hizmet ek yönlendirme gerektirmediğinde kullanılır. Örneğin, durum bilgisi olmayan hizmetler varsayılan olarak bu bölümleme düzenini kullanır.

Adlandırılmış ve Tekli bölümleme düzenleri, aralıklı bölümlerin özel biçimleridir. Varsayılan olarak, Service Fabric için Visual Studio şablonları en yaygın ve kullanışlı bölümleme olduğundan aralıklı bölümleme kullanır. Bu makalenin geri kalanında aralıklı bölümleme düzenine odaklanılır.

Aralıklı bölümleme düzeni

Bu, bir tamsayı aralığını (düşük anahtar ve yüksek anahtarla tanımlanır) ve bir dizi bölümü (n) belirtmek için kullanılır. Her biri genel bölüm anahtarı aralığının çakışmayan bir alt aralığından sorumlu olan n bölüm oluşturur. Örneğin, düşük anahtar 0, yüksek anahtar 99 ve 4 sayısına sahip aralıklı bölümleme düzeni, aşağıda gösterildiği gibi dört bölüm oluşturur.

Aralık bölümleme

Yaygın bir yaklaşım, veri kümesi içindeki benzersiz bir anahtarı temel alan bir karma oluşturmaktır. Anahtarlara örnek olarak araç kimlik numarası (VIN), çalışan kimliği veya benzersiz dize verilebilir. Bu benzersiz anahtarı kullanarak, anahtarınız olarak kullanmak üzere anahtar aralığını modüle eden bir karma kod oluşturursunuz. İzin verilen anahtar aralığının üst ve alt sınırlarını belirtebilirsiniz.

Karma algoritma seçme

Karma oluşturmanın önemli bir parçası, karma algoritmanızı seçmektir. Dikkat edilmesi gereken nokta, hedefin benzer anahtarları birbirine yakın bir şekilde gruplandırmak (yerelliğe duyarlı karma oluşturma) veya etkinliğin daha yaygın olan tüm bölümlere (dağıtım karması) geniş bir şekilde dağıtılması gerekip gerekmediğidir.

İyi bir dağıtım karma algoritmasının özellikleri, hesaplanması kolay olması, birkaç çakışması olması ve anahtarları eşit bir şekilde dağıtmasıdır. FNV-1 karma algoritması verimli karma algoritmasına iyi bir örnektir.

Genel karma kod algoritması seçimleri için iyi bir kaynak, karma işlevlerdeki Wikipedia sayfasıdır.

Birden çok bölümle durum bilgisi olan bir hizmet oluşturma

Şimdi birden çok bölüme sahip ilk güvenilir durum bilgisi olan hizmetinizi oluşturalım. Bu örnekte, aynı harfle başlayan tüm soyadlarını aynı bölümde depolamak istediğiniz çok basit bir uygulama oluşturacaksınız.

Herhangi bir kod yazmadan önce bölümler ve bölüm anahtarları hakkında düşünmeniz gerekir. 26 bölüme ihtiyacınız var (alfabedeki her harf için bir bölüm) ama düşük ve yüksek tuşlara ne olacak? Harfin başına bir bölüm olmasını istediğimizden, her harfin kendi anahtarı olduğundan düşük anahtar olarak 0 ve yüksek anahtar olarak 25'i kullanabiliriz.

Not

Bu basitleştirilmiş bir senaryodur, çünkü gerçekte dağıtım eşit değildir. "S" veya "M" harfleriyle başlayan soyadlar, "X" veya "Y" ile başlayan adlardan daha yaygındır.

  1. Visual Studio>Dosya>Yeni Projesi'ni> açın.

  2. Yeni Proje iletişim kutusunda Service Fabric uygulamasını seçin.

  3. Projeyi "AlphabetPartitions" olarak adlandırın.

  4. Hizmet Oluştur iletişim kutusunda Durum bilgisi olan hizmet'i seçin ve "Alphabet.Processing" olarak adlandırın.

  5. Bölüm sayısını ayarlayın. AlphabetPartitions projesinin ApplicationPackageRoot klasöründe bulunan ApplicationManifest.xml dosyasını açın ve aşağıda gösterildiği gibi Processing_PartitionCount parametresini 26 olarak güncelleştirin.

    <Parameter Name="Processing_PartitionCount" DefaultValue="26" />

    Aşağıda gösterildiği gibi ApplicationManifest.xml StatefulService öğesinin LowKey ve HighKey özelliklerini de güncelleştirmeniz gerekir.

    <Service Name="Alphabet.Processing">
  <StatefulService ServiceTypeName="Alphabet.ProcessingType" TargetReplicaSetSize="[Processing_TargetReplicaSetSize]" MinReplicaSetSize="[Processing_MinReplicaSetSize]">
    <UniformInt64Partition PartitionCount="[Processing_PartitionCount]" LowKey="0" HighKey="25" />
  </StatefulService>
</Service>

  6. Hizmetin erişilebilir olması için, aşağıda gösterildiği gibi Alphabet.Processing hizmeti için ServiceManifest.xml uç nokta öğesini (PackageRoot klasöründe bulunur) ekleyerek bağlantı noktasında bir uç nokta açın:

    <Endpoint Name="ProcessingServiceEndpoint" Port="8089" Protocol="http" Type="Internal" />

    Şimdi hizmet, 26 bölüme sahip bir iç uç noktayı dinleyecek şekilde yapılandırıldı.

  7. Ardından İşleme sınıfının yöntemini geçersiz kılmanız CreateServiceReplicaListeners() gerekir.

    Not

    Bu örnek için basit bir HttpCommunicationListener kullandığınızı varsayıyoruz. Güvenilir hizmet iletişimi hakkında daha fazla bilgi için bkz . Güvenilir Hizmet iletişim modeli.

  8. Bir çoğaltmanın dinlemesi gereken URL için önerilen desen şu biçimdedir: {scheme}://{nodeIp}:{port}/{partitionid}/{replicaid}/{guid}. Bu nedenle iletişim dinleyicinizi doğru uç noktaları dinleyecek şekilde ve bu desenle yapılandırmak istiyorsunuz.

    Bu hizmetin birden çok çoğaltması aynı bilgisayarda barındırılabilir, bu nedenle bu adresin çoğaltmaya özel olması gerekir. Bu nedenle bölüm kimliği + çoğaltma kimliği URL'dedir. URL ön eki benzersiz olduğu sürece HttpListener aynı bağlantı noktasında birden çok adresi dinleyebilir.

    İkincil çoğaltmaların da salt okunur istekleri dinlediği gelişmiş bir durum için ek GUID vardır. Böyle bir durumda, istemcileri adresi yeniden çözümlemeye zorlamak için birincilden ikincile geçiş yaparken yeni bir benzersiz adresin kullanıldığından emin olmak istersiniz. '+' burada adres olarak kullanılır, böylece çoğaltma tüm kullanılabilir konaklarda (IP, FQDN, localhost vb.) dinler. Aşağıdaki kodda bir örnek gösterilmektedir.

    protected override IEnumerable<ServiceReplicaListener> CreateServiceReplicaListeners()
{
     return new[] { new ServiceReplicaListener(context => this.CreateInternalListener(context))};
}
private ICommunicationListener CreateInternalListener(ServiceContext context)
{

     EndpointResourceDescription internalEndpoint = context.CodePackageActivationContext.GetEndpoint("ProcessingServiceEndpoint");
     string uriPrefix = String.Format(
            "{0}://+:{1}/{2}/{3}-{4}/",
            internalEndpoint.Protocol,
            internalEndpoint.Port,
            context.PartitionId,
            context.ReplicaOrInstanceId,
            Guid.NewGuid());

     string nodeIP = FabricRuntime.GetNodeContext().IPAddressOrFQDN;

     string uriPublished = uriPrefix.Replace("+", nodeIP);
     return new HttpCommunicationListener(uriPrefix, uriPublished, this.ProcessInternalRequest);
}

    Ayrıca yayımlanan URL'nin dinleme URL'si ön ekinden biraz farklı olduğunu da unutmayın. Dinleme URL'si HttpListener'a verilir. Yayımlanan URL, hizmet bulma için kullanılan Service Fabric Adlandırma Hizmeti'ne yayımlanan URL'dir. İstemciler bu adresi bulma hizmeti aracılığıyla ister. İstemcilerin elde edilen adresin bağlanabilmesi için düğümün gerçek IP veya FQDN'sine sahip olması gerekir. Bu nedenle yukarıda gösterildiği gibi '+' öğesini düğümün IP veya FQDN'siyle değiştirmeniz gerekir.

  9. Son adım, aşağıda gösterildiği gibi işleme mantığını hizmete eklemektir.

    private async Task ProcessInternalRequest(HttpListenerContext context, CancellationToken cancelRequest)
{
    string output = null;
    string user = context.Request.QueryString["lastname"].ToString();

    try
    {
        output = await this.AddUserAsync(user);
    }
    catch (Exception ex)
    {
        output = ex.Message;
    }

    using (HttpListenerResponse response = context.Response)
    {
        if (output != null)
        {
            byte[] outBytes = Encoding.UTF8.GetBytes(output);
            response.OutputStream.Write(outBytes, 0, outBytes.Length);
        }
    }
}
private async Task<string> AddUserAsync(string user)
{
    IReliableDictionary<String, String> dictionary = await this.StateManager.GetOrAddAsync<IReliableDictionary<String, String>>("dictionary");

    using (ITransaction tx = this.StateManager.CreateTransaction())
    {
        bool addResult = await dictionary.TryAddAsync(tx, user.ToUpperInvariant(), user);

        await tx.CommitAsync();

        return String.Format(
            "User {0} {1}",
            user,
            addResult ? "successfully added" : "already exists");
    }
}

    ProcessInternalRequestbölümü çağırmak için kullanılan sorgu dizesi parametresinin değerlerini okur ve soyadını güvenilir sözlüğe dictionaryeklemek için öğesini çağırırAddUserAsync.

  10. Belirli bir bölümü nasıl çağırabileceğinizi görmek için projeye durum bilgisi olmayan bir hizmet ekleyelim.

    Bu hizmet, soyadını sorgu dizesi parametresi olarak kabul eden, bölüm anahtarını belirleyen ve işlenmek üzere Alphabet.Processing hizmetine gönderen basit bir web arabirimi işlevi görür.

  11. Hizmet Oluştur iletişim kutusunda Durum bilgisi olmayan hizmet'i seçin ve aşağıda gösterildiği gibi "Alphabet.Web" olarak adlandırın.

    Durum bilgisi olmayan hizmet ekran görüntüsü.

  12. Aşağıda gösterildiği gibi bir bağlantı noktası açmak için Alphabet.WebApi hizmetinin ServiceManifest.xml uç nokta bilgilerini güncelleştirin.

    <Endpoint Name="WebApiServiceEndpoint" Protocol="http" Port="8081"/>

  13. Web sınıfında ServiceInstanceListeners koleksiyonunu döndürmeniz gerekir. Yine basit bir HttpCommunicationListener uygulamayı seçebilirsiniz.

    protected override IEnumerable<ServiceInstanceListener> CreateServiceInstanceListeners()
{
    return new[] {new ServiceInstanceListener(context => this.CreateInputListener(context))};
}
private ICommunicationListener CreateInputListener(ServiceContext context)
{
    // Service instance's URL is the node's IP & desired port
    EndpointResourceDescription inputEndpoint = context.CodePackageActivationContext.GetEndpoint("WebApiServiceEndpoint")
    string uriPrefix = String.Format("{0}://+:{1}/alphabetpartitions/", inputEndpoint.Protocol, inputEndpoint.Port);
    var uriPublished = uriPrefix.Replace("+", FabricRuntime.GetNodeContext().IPAddressOrFQDN);
    return new HttpCommunicationListener(uriPrefix, uriPublished, this.ProcessInputRequest);
}

  14. Şimdi işleme mantığını uygulamanız gerekir. HttpCommunicationListener, bir istek geldiğinde çağırır ProcessInputRequest . Bu nedenle devam edelim ve aşağıdaki kodu ekleyelim.

    private async Task ProcessInputRequest(HttpListenerContext context, CancellationToken cancelRequest)
{
    String output = null;
    try
    {
        string lastname = context.Request.QueryString["lastname"];
        char firstLetterOfLastName = lastname.First();
        ServicePartitionKey partitionKey = new ServicePartitionKey(Char.ToUpper(firstLetterOfLastName) - 'A');

        ResolvedServicePartition partition = await this.servicePartitionResolver.ResolveAsync(alphabetServiceUri, partitionKey, cancelRequest);
        ResolvedServiceEndpoint ep = partition.GetEndpoint();

        JObject addresses = JObject.Parse(ep.Address);
        string primaryReplicaAddress = (string)addresses["Endpoints"].First();

        UriBuilder primaryReplicaUriBuilder = new UriBuilder(primaryReplicaAddress);
        primaryReplicaUriBuilder.Query = "lastname=" + lastname;

        string result = await this.httpClient.GetStringAsync(primaryReplicaUriBuilder.Uri);

        output = String.Format(
                "Result: {0}. <p>Partition key: '{1}' generated from the first letter '{2}' of input value '{3}'. <br>Processing service partition ID: {4}. <br>Processing service replica address: {5}",
                result,
                partitionKey,
                firstLetterOfLastName,
                lastname,
                partition.Info.Id,
                primaryReplicaAddress);
    }
    catch (Exception ex) { output = ex.Message; }

    using (var response = context.Response)
    {
        if (output != null)
        {
            output = output + "added to Partition: " + primaryReplicaAddress;
            byte[] outBytes = Encoding.UTF8.GetBytes(output);
            response.OutputStream.Write(outBytes, 0, outBytes.Length);
        }
    }
}

    Adım adım ilerleyelim. Kod, sorgu dizesi parametresinin lastname ilk harfini bir char olarak okur. Ardından, soyadının ilk harfinin onaltılık değerinden onaltılık değerini A çıkararak bu harfin bölüm anahtarını belirler.

    string lastname = context.Request.QueryString["lastname"];
char firstLetterOfLastName = lastname.First();
ServicePartitionKey partitionKey = new ServicePartitionKey(Char.ToUpper(firstLetterOfLastName) - 'A');

    Bu örnekte, bölüm başına bir bölüm anahtarıyla 26 bölüm kullandığımızı unutmayın. Ardından, nesnesinde yöntemini servicePartitionResolver kullanarak bu anahtarın ResolveAsync hizmet bölümünü partition elde edeceğiz. servicePartitionResolver olarak tanımlanır

    private readonly ServicePartitionResolver servicePartitionResolver = ServicePartitionResolver.GetDefault();

    yöntemi hizmet URI'sini ResolveAsync , bölüm anahtarını ve bir iptal belirtecini parametre olarak alır. İşleme hizmetinin hizmet URI'si şeklindedir fabric:/AlphabetPartitions/Processing. Ardından bölümün uç noktasını alacağız.

    ResolvedServiceEndpoint ep = partition.GetEndpoint()

    Son olarak uç nokta URL'sini ve querystring'i derleyip işleme hizmetini çağıracağız.

    JObject addresses = JObject.Parse(ep.Address);
string primaryReplicaAddress = (string)addresses["Endpoints"].First();

UriBuilder primaryReplicaUriBuilder = new UriBuilder(primaryReplicaAddress);
primaryReplicaUriBuilder.Query = "lastname=" + lastname;

string result = await this.httpClient.GetStringAsync(primaryReplicaUriBuilder.Uri);

    İşlem tamamlandıktan sonra çıkışı geri yazarız.

  15. Son adım, hizmeti test etmektir. Visual Studio, yerel ve bulut dağıtımı için uygulama parametrelerini kullanır. Hizmeti yerel olarak 26 bölümle test etmek için, aşağıda gösterildiği gibi AlphabetPartitions projesinin ApplicationParameters klasöründeki dosyayı güncelleştirmeniz Local.xml gerekir:

    <Parameters>
  <Parameter Name="Processing_PartitionCount" Value="26" />
  <Parameter Name="WebApi_InstanceCount" Value="1" />
</Parameters>

  16. Dağıtımı tamamladıktan sonra hizmeti ve tüm bölümlerini Service Fabric Explorer kontrol edebilirsiniz.

    Service Fabric Explorer ekran görüntüsü

  17. Tarayıcıda yazarak bölümleme mantığını http://localhost:8081/?lastname=somenametest edebilirsiniz. Aynı harfle başlayan her soyadının aynı bölümde depolandığını göreceksiniz.

    Tarayıcı ekran görüntüsü

Bu makalede kullanılan kodun tam çözümüne şuradan ulaşabilirsiniz: https://github.com/Azure-Samples/service-fabric-dotnet-getting-started/tree/classic/Services/AlphabetPartitions.

Sonraki adımlar

Service Fabric hizmetleri hakkında daha fazla bilgi edinin: