Partitioneren van Service Fabric-betrouwbare services

Artikel
06/01/2023

Dit artikel bevat een inleiding tot de basisconcepten van het partitioneren van betrouwbare services van Azure Service Fabric. Partitionering maakt gegevensopslag op de lokale computers mogelijk, zodat gegevens en rekenkracht samen kunnen worden geschaald.

Tip

Een volledig voorbeeld van de code in dit artikel is beschikbaar op GitHub.

Partitionering

Partitioneren is niet uniek voor Service Fabric. In feite is het een kernpatroon voor het bouwen van schaalbare services. In bredere zin kunnen we partitioneren beschouwen als een concept van het verdelen van de status (gegevens) en berekenen in kleinere toegankelijke eenheden om de schaalbaarheid en prestaties te verbeteren. Een bekende vorm van partitioneren is gegevenspartitionering, ook wel bekend als sharding.

Service Fabric stateless services partitioneren

Voor stateless services kunt u denken dat een partitie een logische eenheid is die een of meer exemplaren van een service bevat. Afbeelding 1 toont een staatloze service met vijf exemplaren die zijn verdeeld over een cluster met behulp van één partitie.

Stateless service

Er zijn in feite twee soorten stateless serviceoplossingen. De eerste is een service die de status extern vasthoudt, bijvoorbeeld in een database in Azure SQL Database (zoals een website waarop de sessiegegevens en -gegevens worden opgeslagen). De tweede zijn services met alleen berekeningen (zoals een rekenmachine of afbeeldingsminiaturen) die geen permanente status beheren.

In beide gevallen is het partitioneren van een stateless service een zeer zeldzaam scenario: schaalbaarheid en beschikbaarheid worden normaal gesproken bereikt door meer exemplaren toe te voegen. De enige keer dat u meerdere partities voor stateless service-exemplaren wilt overwegen, is wanneer u moet voldoen aan speciale routeringsaanvragen.

Stel dat gebruikers met id's in een bepaald bereik alleen mogen worden bediend door een bepaald service-exemplaar. Een ander voorbeeld van wanneer u een staatloze service kunt partitioneren, is wanneer u een echt gepartitioneerde back-end hebt (bijvoorbeeld een sharddatabase in SQL Database) en u wilt bepalen welk service-exemplaar naar de database-shard moet schrijven of andere voorbereidingswerkzaamheden moet uitvoeren binnen de staatloze service waarvoor dezelfde partitioneringsgegevens nodig zijn als die in de back-end worden gebruikt. Dergelijke scenario's kunnen ook op verschillende manieren worden opgelost en vereisen niet noodzakelijkerwijs servicepartitionering.

De rest van deze walkthrough is gericht op stateful services.

Service Fabric-stateful services partitioneren

Service Fabric maakt het eenvoudig om schaalbare stateful services te ontwikkelen door een eersteklas manier aan te bieden voor de partitiestatus (gegevens). Conceptueel gezien kunt u een partitie van een stateful service beschouwen als een schaaleenheid die zeer betrouwbaar is via replica's die zijn gedistribueerd en verdeeld over de knooppunten in een cluster.

Partitionering in de context van Stateful Service Fabric-services verwijst naar het proces waarbij wordt vastgesteld dat een bepaalde servicepartitie verantwoordelijk is voor een deel van de volledige status van de service. (Zoals eerder vermeld, is een partitie een set replica's. Een groot ding over Service Fabric is dat de partities op verschillende knooppunten worden geplaatst. Hierdoor kunnen ze groeien tot de resourcelimiet van een knooppunt. Naarmate de gegevensbehoeften toenemen, worden partities groter en worden de partities in Service Fabric opnieuw verdeeld over knooppunten. Dit zorgt voor een blijvend efficiënt gebruik van hardwareresources.

Stel dat u begint met een cluster met vijf knooppunten en een service die is geconfigureerd voor 10 partities en een doel van drie replica's. In dit geval zou Service Fabric de replica's verdelen en verdelen over het cluster, en zou u uiteindelijk twee primaire replica's per knooppunt hebben. Als u het cluster nu wilt uitschalen naar 10 knooppunten, worden de primaire replica's opnieuw verdeeld over alle 10 knooppunten. Als u terugschaalt naar 5 knooppunten, herverdeelt Service Fabric alle replica's over de vijf knooppunten.

Afbeelding 2 toont de verdeling van 10 partities vóór en na het schalen van het cluster.

Stateful service

Als gevolg hiervan wordt de schaalaanpassing bereikt omdat aanvragen van clients over computers worden verdeeld, de algehele prestaties van de toepassing worden verbeterd en de conflicten over de toegang tot gegevenssegmenten worden verminderd.

Partitionering plannen

Voordat u een service implementeert, moet u altijd rekening houden met de partitiestrategie die nodig is om uit te schalen. Er zijn verschillende manieren, maar ze zijn allemaal gericht op wat de toepassing moet bereiken. Laten we voor de context van dit artikel enkele van de belangrijkste aspecten bekijken.

Een goede benadering is om als eerste stap na te denken over de structuur van de status die moet worden gepartitioneerd.

Laten we een eenvoudig voorbeeld nemen. Als u een service voor een peiling in de hele provincie zou bouwen, kunt u een partitie maken voor elke stad in de provincie. Vervolgens kunt u de stemmen voor elke persoon in de stad opslaan in de partitie die overeenkomt met die stad. Afbeelding 3 illustreert een reeks mensen en de stad waarin ze wonen.

Eenvoudige partitie

Omdat de bevolking van steden sterk varieert, kan het gebeuren dat sommige partities veel gegevens bevatten (bijvoorbeeld Seattle) en andere partities met zeer weinig staat (bijvoorbeeld Kirkland). Wat is de impact van partities met ongelijke hoeveelheden statussen?

Als u opnieuw nadenkt over het voorbeeld, kunt u gemakkelijk zien dat de partitie met de stemmen voor Seattle meer verkeer krijgt dan de Kirkland-partitie. Service Fabric zorgt er standaard voor dat er ongeveer hetzelfde aantal primaire en secundaire replica's op elk knooppunt is. Het is dus mogelijk dat u knooppunten hebt met replica's die meer verkeer bedienen en andere die minder verkeer bedienen. U wilt bij voorkeur warme en koude plekken zoals deze in een cluster vermijden.

Om dit te voorkomen, moet u twee dingen doen, vanuit het oogpunt van partitionering:

Probeer de status zo te partitioneren dat deze gelijkmatig over alle partities wordt verdeeld.
Rapportbelasting van elk van de replica's voor de service. (Raadpleeg dit artikel over Metrische gegevens en belasting voor meer informatie over hoe u dit doet). Service Fabric biedt de mogelijkheid om de door services verbruikte belasting te rapporteren, zoals de hoeveelheid geheugen of het aantal records. Op basis van de gerapporteerde metrische gegevens detecteert Service Fabric dat sommige partities hogere belastingen verwerken dan andere en wordt het cluster opnieuw verdeeld door replica's te verplaatsen naar geschiktere knooppunten, zodat er over het algemeen geen knooppunt overbelast raakt.

Soms kunt u niet weten hoeveel gegevens zich in een bepaalde partitie bevinden. Een algemene aanbeveling is dus om beide te doen: eerst door een partitioneringsstrategie te gebruiken die de gegevens gelijkmatig over de partities verspreidt en ten tweede door de belasting te rapporteren. De eerste methode voorkomt situaties die worden beschreven in het stemvoorbeeld, terwijl de tweede helpt tijdelijke verschillen in toegang of belasting na verloop van tijd weg te vlakken.

Een ander aspect van partitieplanning is het kiezen van het juiste aantal partities om mee te beginnen. Vanuit het perspectief van Service Fabric is er niets dat voorkomt dat u met een hoger aantal partities kunt beginnen dan verwacht voor uw scenario. Ervan uitgaande dat het maximum aantal partities een geldige benadering is.

In zeldzame gevallen hebt u mogelijk meer partities nodig dan u in eerste instantie hebt gekozen. Omdat u het aantal partities achteraf niet kunt wijzigen, moet u een aantal geavanceerde partitiemethoden toepassen, zoals het maken van een nieuw service-exemplaar van hetzelfde servicetype. U moet ook logica aan de clientzijde implementeren waarmee de aanvragen naar het juiste service-exemplaar worden gerouteerd, op basis van de kennis aan de clientzijde die uw clientcode moet onderhouden.

Een andere overweging voor partitioneringsplanning zijn de beschikbare computerbronnen. Omdat de status moet worden geopend en opgeslagen, moet u het volgende volgen:

Netwerkbandbreedtelimieten
Systeemgeheugenlimieten
Schijfopslaglimieten

Wat gebeurt er als u te maken krijgt met resourcebeperkingen in een actief cluster? Het antwoord is dat u het cluster eenvoudig kunt uitschalen om aan de nieuwe vereisten te voldoen.

De handleiding voor capaciteitsplanning biedt richtlijnen voor het bepalen van het aantal knooppunten dat uw cluster nodig heeft.

Aan de slag met partitioneren

In deze sectie wordt beschreven hoe u aan de slag gaat met het partitioneren van uw service.

Service Fabric biedt een keuze uit drie partitieschema's:

Ranged partitioning (ook wel bekend als UniformInt64Partition).
Benoemde partitionering. Toepassingen die dit model gebruiken, hebben meestal gegevens die binnen een begrensde set kunnen worden gebuckt. Enkele veelvoorkomende voorbeelden van gegevensvelden die als benoemde partitiesleutels worden gebruikt, zijn regio's, postcodes, klantgroepen of andere bedrijfsgrenzen.
Singleton partitioneren. Singleton-partities worden meestal gebruikt wanneer de service geen extra routering vereist. Staatloze services maken bijvoorbeeld standaard gebruik van dit partitieschema.

Benoemde en Singleton-partitioneringsschema's zijn speciale vormen van bereikpartities. De Visual Studio-sjablonen voor Service Fabric maken standaard gebruik van gebereikte partitionering, omdat dit de meest voorkomende en nuttige is. De rest van dit artikel is gericht op het bereik van het partitioneringsschema.

Bereikpartitioneringsschema

Dit wordt gebruikt om een bereik met een geheel getal (aangegeven door een lage sleutel en een hoge sleutel) en een aantal partities (n) op te geven. Er worden n partities gemaakt, die elk verantwoordelijk zijn voor een niet-overlappend subbereik van het totale partitiesleutelbereik. Een bereikpartitioneringsschema met een lage sleutel van 0, een hoge sleutel van 99 en een telling van 4 zou bijvoorbeeld vier partities maken, zoals hieronder wordt weergegeven.

Bereikpartitionering

Een algemene benadering is het maken van een hash op basis van een unieke sleutel in de gegevensset. Enkele veelvoorkomende voorbeelden van sleutels zijn een voertuigidentificatienummer (VIN), een werknemers-id of een unieke tekenreeks. Door deze unieke sleutel te gebruiken, genereert u vervolgens een hash-code, die het sleutelbereik moduleert, om als uw sleutel te gebruiken. U kunt de boven- en ondergrens van het toegestane sleutelbereik opgeven.

Een hash-algoritme selecteren

Een belangrijk onderdeel van hashing is het selecteren van uw hash-algoritme. Een overweging is of het doel is om vergelijkbare sleutels dicht bij elkaar te groeperen (locality sensitive hashing) of dat de activiteit breed moet worden verdeeld over alle partities (distributie-hashing), wat vaker voorkomt.

De kenmerken van een goed distributie-hash-algoritme zijn dat het eenvoudig te berekenen is, dat er weinig conflicten zijn en dat de sleutels gelijkmatig worden verdeeld. Een goed voorbeeld van een efficiënt hash-algoritme is het hash-algoritme FNV-1 .

Een goede bron voor algemene algoritmekeuzes voor hash-code is de Wikipedia-pagina over hash-functies.

Een stateful service bouwen met meerdere partities

Laten we uw eerste betrouwbare stateful service met meerdere partities maken. In dit voorbeeld bouwt u een zeer eenvoudige toepassing waarin u alle achternamen wilt opslaan die met dezelfde letter beginnen in dezelfde partitie.

Voordat u code schrijft, moet u nadenken over de partities en partitiesleutels. U hebt 26 partities nodig (één voor elke letter in het alfabet), maar hoe zit het met de lage en hoge toetsen? Omdat we letterlijk één partitie per letter willen hebben, kunnen we 0 gebruiken als de lage sleutel en 25 als de hoge sleutel, omdat elke letter een eigen sleutel is.

Notitie

Dit is een vereenvoudigd scenario, omdat de verdeling in werkelijkheid ongelijk zou zijn. Achternamen die beginnen met de letters 'S' of 'M' komen vaker voor dan namen die beginnen met 'X' of 'Y'.

Open Visual Studio>File>New>Project.
Kies in het dialoogvenster Nieuw project de Service Fabric-toepassing.
Noem het project 'AlphabetPartitions'.
Kies in het dialoogvenster Een service maken de optie Stateful service en noem deze 'Alphabet.Processing'.

Stel het aantal partities in. Open het ApplicationManifest.xml-bestand in de map ApplicationPackageRoot van het project AlphabetPartitions en werk de parameter Processing_PartitionCount bij naar 26 zoals hieronder wordt weergegeven.

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

U moet ook de eigenschappen LowKey en HighKey van het element StatefulService in de ApplicationManifest.xml bijwerken, zoals hieronder wordt weergegeven.

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

Om de service toegankelijk te maken, opent u een eindpunt op een poort door het eindpuntelement van ServiceManifest.xml (in de map PackageRoot) toe te voegen voor de service Alphabet.Processing, zoals hieronder wordt weergegeven:
```
<Endpoint Name="ProcessingServiceEndpoint" Port="8089" Protocol="http" Type="Internal" />
```
De service is nu geconfigureerd om te luisteren naar een intern eindpunt met 26 partities.
Vervolgens moet u de methode van de CreateServiceReplicaListeners() klasse Processing overschrijven.

Notitie

Voor dit voorbeeld gaan we ervan uit dat u een eenvoudige HttpCommunicationListener gebruikt. Zie Het Reliable Service-communicatiemodel voor meer informatie over betrouwbare servicecommunicatie.
Een aanbevolen patroon voor de URL waarop een replica luistert, is de volgende indeling: {scheme}://{nodeIp}:{port}/{partitionid}/{replicaid}/{guid}. U wilt uw communicatielistener dus configureren om te luisteren op de juiste eindpunten en met dit patroon.

Meerdere replica's van deze service kunnen op dezelfde computer worden gehost, dus dit adres moet uniek zijn voor de replica. Dit is de reden waarom partitie-id + replica-id in de URL staan. HttpListener kan op meerdere adressen op dezelfde poort luisteren, zolang het URL-voorvoegsel uniek is.

De extra GUID is er voor een geavanceerd geval waarbij secundaire replica's ook luisteren naar alleen-lezen aanvragen. Als dat het geval is, wilt u ervoor zorgen dat er een nieuw uniek adres wordt gebruikt bij de overgang van het primaire adres naar het secundaire adres om clients te dwingen het adres opnieuw om te zetten. '+' wordt hier gebruikt als het adres, zodat de replica luistert op alle beschikbare hosts (IP, FQDN, localhost, enzovoort) In de onderstaande code ziet u een voorbeeld.
```
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);
}
```
Het is ook vermeldenswaardig dat de gepubliceerde URL iets verschilt van het voorvoegsel van de luister-URL. De luister-URL wordt doorgegeven aan HttpListener. De gepubliceerde URL is de URL die wordt gepubliceerd naar de Service Fabric Naming Service, die wordt gebruikt voor servicedetectie. Clients vragen om dit adres via die detectieservice. Het adres dat clients krijgen, moet het werkelijke IP- of FQDN-adres van het knooppunt hebben om verbinding te kunnen maken. U moet dus '+' vervangen door het IP-adres of de FQDN van het knooppunt, zoals hierboven wordt weergegeven.

De laatste stap bestaat uit het toevoegen van de verwerkingslogica aan de service, zoals hieronder wordt weergegeven.

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 leest de waarden van de querytekenreeksparameter die wordt gebruikt om de partitie aan te roepen en roept AddUserAsync aan om de achternaam toe te voegen aan de betrouwbare woordenlijst dictionary.

We gaan een staatloze service toevoegen aan het project om te zien hoe u een bepaalde partitie kunt aanroepen.

Deze service fungeert als een eenvoudige webinterface die de achternaam accepteert als een queryreeksparameter, de partitiesleutel bepaalt en deze verzendt naar de service Alphabet.Processing voor verwerking.
Kies in het dialoogvenster Een service maken de optie Stateless service en noem deze 'Alphabet.Web', zoals hieronder wordt weergegeven.

.
Werk de eindpuntgegevens in de ServiceManifest.xml van de Service Alphabet.WebApi bij om een poort te openen, zoals hieronder wordt weergegeven.
```
<Endpoint Name="WebApiServiceEndpoint" Protocol="http" Port="8081"/>
```

U moet een verzameling ServiceInstanceListeners retourneren in de klasse Web. U kunt er ook voor kiezen om een eenvoudige HttpCommunicationListener te implementeren.

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

Nu moet u de verwerkingslogica implementeren. De HttpCommunicationListener roept aan ProcessInputRequest wanneer een aanvraag binnenkomt. We gaan dus de onderstaande code toevoegen.

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

Laten we het stap voor stap doorlopen. De code leest de eerste letter van de querytekenreeksparameter lastname in een teken. Vervolgens wordt de partitiesleutel voor deze letter bepaald door de hexadecimale waarde van af te trekken van A de hexadecimale waarde van de eerste letter van de achternamen.

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

In dit voorbeeld gebruiken we 26 partities met één partitiesleutel per partitie. Vervolgens verkrijgen we de servicepartitie partition voor deze sleutel met behulp van de ResolveAsync methode voor het servicePartitionResolver -object. servicePartitionResolver is gedefinieerd als

private readonly ServicePartitionResolver servicePartitionResolver = ServicePartitionResolver.GetDefault();

De ResolveAsync methode neemt de service-URI, de partitiesleutel en een annuleringstoken als parameters. De service-URI voor de verwerkingsservice is fabric:/AlphabetPartitions/Processing. Vervolgens wordt het eindpunt van de partitie opgehaald.

ResolvedServiceEndpoint ep = partition.GetEndpoint()

Ten slotte bouwen we de eindpunt-URL plus de querytekenreeks en roepen we de verwerkingsservice aan.

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

Zodra de verwerking is voltooid, schrijven we de uitvoer terug.

De laatste stap is het testen van de service. Visual Studio maakt gebruik van toepassingsparameters voor lokale implementatie en cloudimplementatie. Als u de service met 26 partities lokaal wilt testen, moet u het Local.xml bestand bijwerken in de map ApplicationParameters van het project AlphabetPartitions, zoals hieronder wordt weergegeven:
```
<Parameters>
  <Parameter Name="Processing_PartitionCount" Value="26" />
  <Parameter Name="WebApi_InstanceCount" Value="1" />
</Parameters>
```
Zodra u klaar bent met de implementatie, kunt u de service en alle bijbehorende partities in de Service Fabric Explorer controleren.
In een browser kunt u de partitielogica testen door in te voeren http://localhost:8081/?lastname=somename. U ziet dat elke achternaam die met dezelfde letter begint, wordt opgeslagen in dezelfde partitie.

De volledige oplossing van de code die in dit artikel wordt gebruikt, is hier beschikbaar: https://github.com/Azure-Samples/service-fabric-dotnet-getting-started/tree/classic/Services/AlphabetPartitions.

Volgende stappen

Meer informatie over Service Fabric-services: