A Service Fabric Reliable Services particionálása

Cikk
08/25/2024

Ez a cikk bemutatja az Azure Service Fabric megbízható szolgáltatások particionálásának alapfogalmait. A particionálás lehetővé teszi az adatok tárolását a helyi gépeken, így az adatok és a számítás együtt méretezhetők.

Tipp.

A jelen cikkben szereplő kód teljes mintája elérhető a GitHubon.

Particionálás

A particionálás nem egyedi a Service Fabricben. Valójában ez a skálázható szolgáltatások létrehozásának alapvető mintája. Tágabb értelemben a particionálást az állapotok (adatok) osztásának és kisebb akadálymentes egységekre való kiszámításának koncepciójaként is felfoghatjuk, hogy javíthassuk a méretezhetőséget és a teljesítményt. A particionálás jól ismert formája az adatparticionálás, más néven horizontális particionálás.

A Partition Service Fabric állapot nélküli szolgáltatásai

Az állapot nélküli szolgáltatások esetében azt gondolhatja, hogy egy partíció egy logikai egység, amely egy vagy több szolgáltatáspéldányt tartalmaz. Az 1. ábra egy állapot nélküli szolgáltatást mutat be, amely öt példányt oszt el egy fürtben egy partíció használatával.

Állapot nélküli szolgáltatás

Az állapot nélküli szolgáltatásmegoldásoknak valójában két típusa van. Az első egy olyan szolgáltatás, amely külsőleg megőrzi az állapotát, például egy Azure SQL Database-adatbázisban (például egy olyan webhelyen, amely tárolja a munkamenet adatait és adatait). A második a csak számítási szolgáltatásokat (például egy számológépet vagy a kép miniatűrjeit), amelyek nem kezelik az állandó állapotokat.

Az állapot nélküli szolgáltatások particionálása mindkét esetben nagyon ritka forgatókönyv – a méretezhetőség és a rendelkezésre állás általában több példány hozzáadásával érhető el. Az állapot nélküli szolgáltatáspéldányok több partíciójának csak akkor érdemes több partíciót figyelembe vennie, ha speciális útválasztási kéréseknek kell megfelelnie.

Vegyük például azt az esetet, amikor egy adott tartományban azonosítóval rendelkező felhasználókat csak egy adott szolgáltatáspéldánynak kell kiszolgálnia. Az állapot nélküli szolgáltatások particionálására egy másik példa, ha valóban particionált háttérrendszerrel rendelkezik (például egy szegmenses adatbázissal az SQL Database-ben), és meg szeretné szabályozni, hogy melyik szolgáltatáspéldánynak kell írnia az adatbázis szegmensére – vagy más előkészítési munkát kell végeznie az állapot nélküli szolgáltatáson belül, amely ugyanazokat a particionálási adatokat igényli, mint a háttérrendszerben. Ezek a forgatókönyvek különböző módokon is megoldhatók, és nem feltétlenül igényelnek szolgáltatásparticionálást.

Az útmutató további része az állapotalapú szolgáltatásokra összpontosít.

A Partition Service Fabric állapotalapú szolgáltatásai

A Service Fabric megkönnyíti a skálázható állapotalapú szolgáltatások fejlesztését azáltal, hogy első osztályú módot kínál az állapot (adatok) particionálására. Elméletileg egy állapotalapú szolgáltatás partícióját skálázási egységként tekintheti, amely a fürt csomópontjai között elosztott és elosztott replikákon keresztül rendkívül megbízható.

A Service Fabric állapotalapú szolgáltatásainak kontextusában történő particionálás azt a folyamatot jelenti, amely meghatározza, hogy egy adott szolgáltatáspartíció felelős-e a szolgáltatás teljes állapotának egy részéért. (Ahogy korábban említettük, a partíció replikák készlete). A Service Fabric egyik nagyszerű tulajdonsága, hogy a partíciókat különböző csomópontokra helyezi. Ez lehetővé teszi számukra, hogy egy csomópont erőforráskorlátjára nőjenek. Az adatok növekedésével a partíciók növekednek, a Service Fabric pedig újraegyensúlyozza a csomópontok partícióit. Ez biztosítja a hardvererőforrások folyamatos hatékony használatát.

Példaként tegyük fel, hogy egy ötcsomópontos fürttel és egy 10 partícióra és három replika célként konfigurált szolgáltatással kezd. Ebben az esetben a Service Fabric kiegyensúlyozza és elosztja a replikákat a fürtben, és csomópontonként két elsődleges replikát fog végezni. Ha most 10 csomópontra kell skáláznia a fürtöt, a Service Fabric újraegyensúlyozná az elsődleges replikákat mind a 10 csomóponton. Hasonlóképpen, ha 5 csomópontra skáláz vissza, a Service Fabric újraegyensúlyozná az összes replikát az 5 csomóponton.

A 2. ábra 10 partíció eloszlását mutatja a fürt skálázása előtt és után.

Állapotalapú szolgáltatás

Ennek eredményeképpen a vertikális felskálázás elérhetővé vált, mivel az ügyfelektől érkező kérések szét vannak osztva a számítógépek között, javul az alkalmazás általános teljesítménye, és csökken az adattömbökhöz való hozzáféréssel kapcsolatos versengés.

Particionálás megtervezése

A szolgáltatás implementálása előtt mindig vegye figyelembe a horizontális felskálázáshoz szükséges particionálási stratégiát. Különböző módokon, de mindegyik arra összpontosít, amit az alkalmazásnak el kell érnie. A cikk kontextusában tekintsünk át néhány fontosabb szempontot.

Jó megközelítés, ha első lépésként a particionálásra szoruló állapot szerkezetére gondolunk.

Vegyünk egy egyszerű példát. Ha egy szolgáltatást szeretne létrehozni egy megyei szintű szavazáshoz, létrehozhat egy partíciót a megye minden városához. Ezután a város minden egyes személyére vonatkozó szavazatokat a városnak megfelelő partíción tárolhatja. A 3. ábra az emberek egy csoportját és azt a várost szemlélteti, amelyben laknak.

Egyszerű partíció

Mivel a városok lakossága széles körben változik, előfordulhat, hogy olyan partíciók is megjelennek, amelyek sok adatot tartalmaznak (pl. Seattle) és más, nagyon kevés állapotú partíciókat (például Kirkland). Mi a hatása annak, hogy a partíciók egyenetlen mennyiségű állapotban vannak?

Ha újra a példára gondol, könnyen láthatja, hogy a Seattle-hez tartozó szavazatokat tartalmazó partíció nagyobb forgalmat fog kapni, mint a Kirkland. A Service Fabric alapértelmezés szerint gondoskodik arról, hogy az egyes csomópontokon körülbelül ugyanannyi elsődleges és másodlagos replika legyen. Így előfordulhat, hogy olyan csomópontokat fog használni, amelyek replikákat tárolnak, amelyek több forgalmat, másokat pedig kevesebb forgalmat szolgálnak ki. Érdemes lehet elkerülni az ilyen gyakori és hideg foltokat egy fürtben.

Ennek elkerülése érdekében két dolgot kell tennie particionálási szempontból:

Próbálja meg particionálásra az állapotot úgy, hogy az egyenlően legyen elosztva az összes partíció között.
Jelentésbetöltés a szolgáltatás minden replikájáról. (A hogyanról a következő cikkben olvashat bővebben: Metrikák és terhelés). A Service Fabric lehetővé teszi a szolgáltatások által felhasznált terhelés jelentését, például a memória mennyiségét vagy a rekordok számát. A jelentett metrikák alapján a Service Fabric azt észleli, hogy egyes partíciók nagyobb terhelést szolgálnak ki, mint mások, és a replikák megfelelőbb csomópontokra való áthelyezésével újraegyensúlyozza a fürtöt, így összességében egyetlen csomópont sem lesz túlterhelve.

Előfordulhat, hogy nem tudja, mennyi adat lesz egy adott partícióban. Általános javaslat tehát, hogy először is végezze el a particionálási stratégiát, amely egyenletesen szórja el az adatokat a partíciók között, másodszor pedig a terhelés jelentésével. Az első módszer megakadályozza a szavazási példában leírt helyzeteket, míg a második segít a hozzáférés vagy a terhelés átmeneti eltéréseinek kiegyenlítésében az idő múlásával.

A partíciótervezés másik aspektusa a megfelelő számú partíció kiválasztása. Service Fabric-szempontból semmi sem akadályozza meg, hogy a forgatókönyvhöz vártnál nagyobb számú partícióval kezdjen. Valójában, feltételezve, hogy a partíciók maximális száma érvényes megközelítés.

Ritkán előfordulhat, hogy az eredetileg választottnál több partícióra lesz szüksége. Mivel a tény után nem módosíthatja a partíciók számát, speciális partíciós megközelítéseket kell alkalmaznia, például egy azonos szolgáltatástípusú új szolgáltatáspéldányt kell létrehoznia. Emellett implementálnia kell néhány ügyféloldali logikát is, amely a kéréseket a megfelelő szolgáltatáspéldányhoz irányítja, az ügyféloldali tudás alapján, amelyet az ügyfélkódnak fenn kell tartania.

A particionálás tervezésének másik szempontja a rendelkezésre álló számítógép-erőforrások. Mivel az állapotot hozzá kell férni és tárolni kell, a következőt kell követnie:

Hálózati sávszélesség korlátai
Rendszermemória korlátai
Lemeztárolási korlátok

Mi történik, ha erőforrás-korlátozásokba ütközik egy futó fürtben? A válasz az, hogy egyszerűen felskálázhatja a fürtöt az új követelményeknek megfelelően.

A kapacitástervezési útmutató útmutatást nyújt annak meghatározásához, hogy hány csomópontra van szüksége a fürtnek.

Bevezetés a particionálásba

Ez a szakasz a szolgáltatás particionálásának első lépéseit ismerteti.

A Service Fabric három partíciós séma közül választhat:

Tartományos particionálás (más néven UniformInt64Partition).
Elnevezett particionálás. Az ezt a modellt használó alkalmazások általában egy határolókereten belül gyűjthetők adatokkal. Az elnevezett partíciókulcsként használt adatmezőkre néhány gyakori példa a régiók, az irányítószámok, az ügyfélcsoportok vagy más üzleti határok.
Singleton particionálás. Az egyszeri partíciókat általában akkor használják, ha a szolgáltatás nem igényel további útválasztást. Az állapot nélküli szolgáltatások például alapértelmezés szerint ezt a particionálási sémát használják.

A névvel ellátott és egyszemélyes particionálási sémák a tartományos partíciók speciális formái. Alapértelmezés szerint a Service FabricHez készült Visual Studio-sablonok tartományos particionálást használnak, mivel ez a leggyakoribb és leg hasznosabb. A cikk további része a tartományos particionálási sémára összpontosít.

Tartomány szerinti particionálási séma

Ez egy egész számtartomány (alacsony és magas kulccsal azonosítva) és számos partíció (n) megadására szolgál. N partíciókat hoz létre, mindegyik felelős a teljes partíciókulcs-tartomány nem egymást átfedő altartományáért. Például egy tartományos particionálási séma alacsony 0 kulccsal, egy 99-ből álló magas kulccsal és 4 darabszámmal négy partíciót hozna létre, ahogy az alább látható.

Tartomány particionálása

Gyakori módszer egy kivonat létrehozása egy egyedi kulcs alapján az adatkészleten belül. A kulcsok gyakori példái a jármű-azonosító szám (VIN), egy alkalmazotti azonosító vagy egy egyedi sztring. Ezzel az egyedi kulccsal létrehozna egy kivonatkódot, amely modulálja a kulcstartományt, hogy kulcsként használhassa. Megadhatja az engedélyezett kulcstartomány felső és alsó határát.

Kivonatoló algoritmus kiválasztása

A kivonatolás fontos része a kivonatoló algoritmus kiválasztása. Megfontolandó szempont, hogy a cél a hasonló kulcsok egymáshoz közeli csoportosítása (területi szempontból érzékeny kivonatolás) vagy az, hogy a tevékenységeket széles körben el kell-e osztani az összes partíción (terjesztési kivonatolás), ami gyakoribb.

A jó terjesztési kivonatoló algoritmus jellemzői, hogy könnyen kiszámítható, kevés ütközést okoz, és egyenletesen osztja el a kulcsokat. A hatékony kivonatoló algoritmusra jó példa az FNV-1 kivonatoló algoritmus.

Az általános kivonatkód-algoritmusválasztáshoz jó forrás a Kivonatfüggvények Wikipedia-oldala.

Állapotalapú szolgáltatás létrehozása több partícióval

Hozzuk létre az első megbízható állapotalapú szolgáltatást több partícióval. Ebben a példában egy nagyon egyszerű alkalmazást fog létrehozni, amelyben az összes olyan vezetéknevet tárolni szeretné, amely ugyanazzal a betűvel kezdődik ugyanabban a partícióban.

Mielőtt bármilyen kódot ír, gondolnia kell a partíciókra és a partíciókulcsokra. 26 partícióra van szüksége (egyet az ábécé minden betűje esetén), de mi a helyzet az alacsony és a magas kulcsokkal? Mivel szó szerint betűnként egy partíciót szeretnénk használni, a 0-t használhatjuk alacsony kulcsként, a 25-öt pedig magas kulcsként, mivel minden betű a saját kulcsa.

Feljegyzés

Ez egy egyszerűsített forgatókönyv, mivel a valóságban az eloszlás egyenetlen lenne. Az "S" vagy az "M" betűvel kezdődő vezetéknevek gyakoribbak, mint az "X" vagy az "Y" betűvel kezdődő nevek.

Nyissa meg a Visual Studio>File>New>Projectet.
Az Új projekt párbeszédpanelen válassza a Service Fabric-alkalmazást.
Hívja meg az "AlphabetPartitions" projektet.
A Szolgáltatás létrehozása párbeszédpanelen válassza az Állapotalapú szolgáltatás lehetőséget, és hívja az "Alphabet.Processing" nevet.

Adja meg a partíciók számát. Nyissa meg az AlphabetPartitions projekt ApplicationPackageRoot mappájában található ApplicationManifest.xml fájlt, és frissítse a Processing_PartitionCount paramétert 26-ra az alább látható módon.

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

Frissítenie kell a StatefulService elem LowKey és HighKey tulajdonságait is a ApplicationManifest.xml az alább látható módon.

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

Ahhoz, hogy a szolgáltatás elérhető legyen, nyisson meg egy végpontot egy porton a ServiceManifest.xml végpontelemének (a PackageRoot mappában található) az Alphabet.Processing szolgáltatáshoz az alábbiak szerint:
```
<Endpoint Name="ProcessingServiceEndpoint" Port="8089" Protocol="http" Type="Internal" />
```
Most a szolgáltatás úgy van konfigurálva, hogy egy 26 partícióval rendelkező belső végpontot hallgasson.
Ezután felül kell bírálnia a CreateServiceReplicaListeners() Feldolgozási osztály metódusát.

Feljegyzés

Ebben a mintában feltételezzük, hogy egy egyszerű HttpCommunicationListenert használ. A megbízható szolgáltatáskommunikációval kapcsolatos további információkért tekintse meg a Reliable Service kommunikációs modelljét.
A replika által figyelt URL-cím ajánlott mintája a következő formátum: {scheme}://{nodeIp}:{port}/{partitionid}/{replicaid}/{guid}. Ezért úgy szeretné konfigurálni a kommunikációs figyelőt, hogy a megfelelő végpontokat és ezzel a mintával figyelje.

A szolgáltatás több replikája is üzemeltethető ugyanazon a számítógépen, ezért ennek a címnek egyedinek kell lennie a replika számára. Ezért van a partícióazonosító + replikaazonosító az URL-címben. A HttpListener több címet is figyelhet ugyanazon a porton, ha az URL-előtag egyedi.

Az extra GUID egy speciális esethez tartozik, ahol a másodlagos replikák is figyelik az írásvédett kérelmeket. Ebben az esetben meg kell győződnie arról, hogy egy új egyedi cím lesz használva az elsődlegesről a másodlagosra való áttéréskor, hogy az ügyfelek újra feloldják a címet. Itt a "+" a cím, így a replika az összes elérhető gazdagépen (IP, teljes tartománynév, localhost stb.) figyel. Az alábbi kód egy példát mutat be.
```
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);
}
```
Azt is érdemes megjegyezni, hogy a közzétett URL kissé eltér a figyelési URL-előtagtól. A figyelési URL-címet a HttpListener kapja meg. A közzétett URL-cím a Service Fabric elnevezési szolgáltatásban közzétett URL-cím, amelyet a szolgáltatásfelderítéshez használnak. Az ügyfelek ezt a címet fogják kérni a felderítési szolgáltatáson keresztül. Az ügyfelek által megkapott címnek a csomópont tényleges IP-címével vagy teljes tartománynevével kell rendelkeznie a csatlakozáshoz. Ezért a fenti módon a "+" helyett a csomópont IP-címét vagy teljes tartománynevét kell megadnia.

Az utolsó lépés a feldolgozási logika hozzáadása a szolgáltatáshoz az alább látható módon.

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");
    }
}

ProcessInternalRequest Beolvassa a partíció meghívásához használt lekérdezési sztring paraméter értékeit, és meghívja AddUserAsync a vezetéknevet a megbízható szótárhoz dictionary.

Adjunk hozzá egy állapot nélküli szolgáltatást a projekthez, hogy lássuk, hogyan hívhat meg egy adott partíciót.

Ez a szolgáltatás egy egyszerű webes felület, amely a vezetéknevet fogadja el lekérdezési sztringparaméterként, meghatározza a partíciókulcsot, és elküldi azt az Alphabet.Processing szolgáltatásnak feldolgozás céljából.
A Szolgáltatás létrehozása párbeszédpanelen válassza az Állapot nélküli szolgáltatás lehetőséget, és hívja meg az "Alphabet.Web" nevet az alább látható módon.

.
Frissítse a végpontadatokat az Alphabet.WebApi szolgáltatás ServiceManifest.xml egy port megnyitásához az alább látható módon.
```
<Endpoint Name="WebApiServiceEndpoint" Protocol="http" Port="8081"/>
```

A ServiceInstanceListeners gyűjteményét vissza kell adnia a Web osztályban. Ismét választhat egy egyszerű HttpCommunicationListener implementálását.

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);
}

Most implementálnia kell a feldolgozási logikát. A HttpCommunicationListener meghívja ProcessInputRequest a kérések érkezésekor. Tehát menjünk tovább, és adja hozzá az alábbi kódot.

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);
        }
    }
}

Haladjunk végig lépésről lépésre. A kód beolvassa a lekérdezési sztring paraméter lastname első betűját egy karakterbe. Ezután meghatározza a betű partíciókulcsát úgy, hogy kivonja a hexadecimális értéket a vezetéknevek első betűjének A hexadecimális értékéből.

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

Ne feledje, hogy ebben a példában 26 partíciót használunk partíciónként egy partíciókulcsmal. Ezután lekérjük a kulcs szolgáltatáspartícióját partition az ResolveAsync objektum metódusával servicePartitionResolver . servicePartitionResolver a következőként van definiálva:

private readonly ServicePartitionResolver servicePartitionResolver = ServicePartitionResolver.GetDefault();

A ResolveAsync metódus paraméterként a szolgáltatás URI-t, a partíciókulcsot és a lemondási jogkivonatot veszi fel. A feldolgozási szolgáltatás szolgáltatás URI-ja a következő fabric:/AlphabetPartitions/Processing: . Ezután lekérjük a partíció végpontját.

ResolvedServiceEndpoint ep = partition.GetEndpoint()

Végül létrehozzuk a végpont URL-címét, valamint a lekérdezést, és meghívjuk a feldolgozási szolgáltatást.

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);

A feldolgozás befejezése után visszaírjuk a kimenetet.

Az utolsó lépés a szolgáltatás tesztelése. A Visual Studio alkalmazásparamétereket használ a helyi és a felhőbeli üzembe helyezéshez. Ha a szolgáltatást helyileg 26 partícióval szeretné tesztelni, frissítenie kell a fájlt az Local.xml AlphabetPartitions projekt ApplicationParameters mappájában az alábbi módon:
```
<Parameters>
  <Parameter Name="Processing_PartitionCount" Value="26" />
  <Parameter Name="WebApi_InstanceCount" Value="1" />
</Parameters>
```
Az üzembe helyezés befejezése után ellenőrizheti a szolgáltatást és annak összes partícióját a Service Fabric Explorerben.
A böngészőben a particionálási logikát a beírással http://localhost:8081/?lastname=somenametesztelheti. Látni fogja, hogy az azonos betűvel kezdődő vezetéknevek ugyanabban a partícióban lesznek tárolva.

A cikkben használt kód teljes megoldása itt érhető el: https://github.com/Azure-Samples/service-fabric-dotnet-getting-started/tree/classic/Services/AlphabetPartitions.

Következő lépések

További információ a Service Fabric-szolgáltatásokról:

Megosztás a következőn keresztül: