Aracılığıyla paylaş

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 depolamaya olanak tanır.

İ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 bir desenidir. Daha geniş anlamda, ölçeklenebilirliği ve performansı geliştirmek için bölümlemenin durumu (verileri) ve işlemi daha küçük erişilebilir birimlere bölme kavramı olarak düşünebiliriz. İyi bilinen bir bölümleme 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ği içeren mantıksal bir birim olduğunu düşünebilirsiniz. Şekil 1'de, bir bölüm kullanılarak küme genelinde dağıtılan 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ı'daki 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.

Örnek olarak, 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 ucunuz (örneğin, SQL Veritabanı parçalı bir veritabanı) olması 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ümleme gerektirmez.

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. Veriler büyüdükçe bölümler büyür ve Service Fabric düğümler arasında bölümleri yeniden dengeler. Bu, donanım kaynaklarının verimli kullanımına devam edilmesini sağlar.

Size bir örnek vermek gerekirse, 5 düğümlü bir küme ve 10 bölüm 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üme genelinde 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 tamamı 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ığından, uygulamanın genel performansı iyileştirildiğinden ve veri öbeklerine erişimdeki çekişme 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ı yönleri 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 genelindeki 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şinin oylarını o şehre karşılık gelen bölümde depolayabilirsiniz. Şekil 3'te bir grup kişi ve bulundukları şehir gösterilmektedir.

Basit bölüm

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

Örneği yeniden düşünürseniz Seattle'a oy veren 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 veren çoğaltmaları ve daha az trafiğe hizmet veren diğer çoğaltmaları barındıran düğümlerle karşılaşabilirsiniz. Tercihen bir 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 şu makaleye göz atın: Ölçümler ve Yükleme). Service Fabric, hizmetler tarafından kullanılan bellek miktarı veya kayıt sayısı gibi yükü raporlama özelliği sağlar. Service Fabric, bildirilen ölçümlere bağlı olarak 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; ilk 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üklemedeki 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 açısından 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. Olgudan 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ı 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ğıdaki adımları izlemeniz gerekir:

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

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

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 (diğer adıyla UniformInt64Partition).
  • 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.
  • Tek 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ı, aralıklı bölümleme düzenine odaklanır.

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

Bu, bir tamsayı aralığı (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 alt konumundan sorumlu olan n bölüm oluşturur. Örneğin, aşağıda gösterildiği gibi düşük anahtar 0, yüksek anahtar 99 ve 4 sayıyla aralıklı bölümleme düzeni dört bölüm oluşturur.

Aralık bölümleme

Yaygın bir yaklaşım, veri kümesindeki benzersiz bir anahtarı temel alan bir karma oluşturmaktır. Anahtarlara örnek olarak araç kimlik numarası (VIN), çalışan kimliği veya benzersiz bir dize verilebilir. Bu benzersiz anahtarı kullanarak, anahtarınız olarak kullanmak üzere anahtar aralığını modüle eden bir karma kodu 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 birbirine yakın benzer anahtarları (yerelliğe duyarlı karma oluşturma) gruplandırmak mı yoksa etkinliğin daha yaygın olan tüm bölümlere (dağıtım karması) geniş bir şekilde dağıtılması mı gerektiğ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çenekleri için iyi bir kaynak, karma işlevlerindeki Wikipedia sayfasıdır.

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

Şimdi birden çok bölümle 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şlar ne olacak? Harfin tam anlamıyla harf başına bir bölüm olmasını istediğimiz için, 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 çağı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 bir bağlantı noktasında bir uç nokta açın:

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

    Artık hizmet, 26 bölümlü bir iç uç noktayı dinleyecek şekilde yapılandırılmıştır.

  7. Ardından, processing 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 dinlediğini URL için önerilen desen şu biçimdedir: {scheme}://{nodeIp}:{port}/{partitionid}/{replicaid}/{guid}. Bu nedenle, iletişim dinleyicinizi doğru uç noktalarda ve bu desenle dinleyecek şekilde 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. HTTPListener, URL ön eki benzersiz olduğu sürece aynı bağlantı noktasındaki birden çok adresi dinleyebilir.

    İkincil çoğaltmaların da salt okunur istekleri dinlediği gelişmiş bir durum için ek GUID vardır. Bu durumda, istemcileri adresi yeniden çözümlemeye zorlamak için birincil adresten ikincilye 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 '+' öğesini yukarıda gösterildiği gibi 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şlemek ü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 karaktere 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 ResolveAsync bu anahtar için hizmet bölümünü partition elde edeceğiz. servicePartitionResolver olarak tanımlanır

    private readonly ServicePartitionResolver servicePartitionResolver = ServicePartitionResolver.GetDefault();

    ResolveAsync yöntemi, hizmet URI'sini, 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 sorgu dizesini 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 Gezgini'nde de kontrol edebilirsiniz.

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

  17. Tarayıcıda, yazarak http://localhost:8081/?lastname=somenamebölümleme mantığını test 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: