Delen via

Best practices voor Azure Service Fabric-toepassingen

  • Artikel

Dit artikel bevat richtlijnen voor aanbevolen procedures voor het bouwen van toepassingen en services in Azure Service Fabric.

Vertrouwd raken met Service Fabric

Richtlijnen voor het ontwerpen van toepassingen

Raak vertrouwd met de algemene architectuur van Service Fabric-toepassingen en hun ontwerpoverwegingen.

Een API-gateway kiezen

Gebruik een API-gatewayservice die communiceert met back-endservices die vervolgens kunnen worden uitgeschaald. De meest voorkomende API-gatewayservices die worden gebruikt, zijn:

Stateless services

We raden u aan om altijd stateless services te bouwen met behulp van Reliable Services en de status op te slaan in een Azure-database, Azure Cosmos DB of Azure Storage. De externe status is de meer vertrouwde benadering voor de meeste ontwikkelaars. Met deze aanpak kunt u ook profiteren van querymogelijkheden in de store.

Wanneer stateful services gebruiken

Overweeg stateful services wanneer u een scenario voor lage latentie hebt en de gegevens dicht bij de berekening moet houden. Enkele voorbeeldscenario's zijn IoT-apparaten met digitale dubbels, gamestatus, sessiestatus, cachinggegevens uit een database en langlopende werkstromen om aanroepen naar andere services bij te houden.

Bepaal het tijdsbestek voor gegevensretentie:

  • Gegevens komen uit het cachegeheugen. Caching gebruiken wanneer latentie voor externe winkels een probleem is. Gebruik een stateful service als uw eigen gegevenscache of overweeg om de gedistribueerde cache socreate Service Fabric te gebruiken. In dit scenario hoeft u zich geen zorgen te maken als u alle gegevens in de cache kwijtraakt.
  • Tijdgebonden gegevens. In dit scenario moet u gegevens dicht bij de berekening houden gedurende een bepaalde periode voor latentie, maar u kunt zich veroorloven om de gegevens in een noodgeval te verliezen. In veel IoT-oplossingen moeten gegevens bijvoorbeeld dicht bij de berekening staan, bijvoorbeeld wanneer de gemiddelde temperatuur in de afgelopen dagen wordt berekend, maar als deze gegevens verloren gaan, zijn de specifieke gegevenspunten die zijn vastgelegd niet zo belangrijk. In dit scenario hoeft u meestal geen back-up te maken van de afzonderlijke gegevenspunten. U maakt alleen een back-up van berekende gemiddelde waarden die periodiek naar externe opslag worden geschreven.
  • Langetermijngegevens. Betrouwbare verzamelingen kunnen uw gegevens permanent opslaan. Maar in dit geval moet u zich voorbereiden op herstel na noodgevallen, waaronder het configureren van periodieke back-upbeleidsregels voor uw clusters. In feite configureert u wat er gebeurt als uw cluster wordt vernietigd in een noodgeval, waar u een nieuw cluster moet maken en hoe u nieuwe toepassingsexemplaren implementeert en herstelt van de meest recente back-up.

Bespaar kosten en verbeter de beschikbaarheid:

  • U kunt kosten verlagen door stateful services te gebruiken, omdat u geen kosten voor gegevenstoegang en transacties in rekening brengen vanuit het externe archief en omdat u geen andere service hoeft te gebruiken, zoals Azure Cache voor Redis.
  • Het gebruik van stateful services voornamelijk voor opslag en niet voor rekenkracht is duur en we raden het niet aan. Denk aan stateful services als rekenkracht met goedkope lokale opslag.
  • Door afhankelijkheden van andere services te verwijderen, kunt u de beschikbaarheid van uw service verbeteren. Het beheren van de status met hoge beschikbaarheid in het cluster isoleert u van andere service-downtime of latentieproblemen.

Werken met Reliable Services

Met Service Fabric Reliable Services kunt u eenvoudig stateless en stateful services maken. Zie de inleiding tot Reliable Services voor meer informatie.

  • Houd altijd rekening met het annuleringstoken in de RunAsync() methode voor staatloze en stateful services en de ChangeRole() methode voor stateful services. Als u dat niet doet, weet Service Fabric niet of uw service kan worden gesloten. Als u bijvoorbeeld het annuleringstoken niet nakomt, kunnen er veel langere upgradetijden voor toepassingen optreden.
  • Open en sluit communicatielisteners tijdig en volg de annuleringstokens.
  • Combineer nooit synchronisatiecode met asynchrone code. Gebruik bijvoorbeeld niet .GetAwaiter().GetResult() in uw asynchrone aanroepen. Gebruik asynchroon door de aanroepstack.

Werken met Reliable Actors

Met Service Fabric Reliable Actors kunt u eenvoudig stateful virtuele actoren maken. Zie de inleiding tot Reliable Actors voor meer informatie.

  • Overweeg het gebruik van pub/subberichten tussen uw actoren voor het schalen van uw toepassing. Hulpprogramma's die deze service bieden, zijn onder andere de open source SoCreate Service Fabric Pub/Sub en Azure Service Bus.
  • Maak de actorstatus zo gedetailleerd mogelijk.
  • De levenscyclus van de actor beheren. Verwijder actoren als u ze niet opnieuw gaat gebruiken. Het verwijderen van overbodige actoren is vooral belangrijk wanneer u de vluchtige statusprovider gebruikt, omdat alle statussen in het geheugen worden opgeslagen.
  • Vanwege hun turn-based gelijktijdigheid kunnen actoren het beste worden gebruikt als onafhankelijke objecten. Maak geen grafieken van multi-actor, synchrone methodeaanroepen (die elk waarschijnlijk een afzonderlijke netwerkaanroep worden) of maak circulaire actoraanvragen. Deze zijn van invloed op de prestaties en schaal.
  • Combineer synchronisatiecode niet met asynchrone code. Gebruik asynchroon om prestatieproblemen te voorkomen.
  • Doe niet langlopende oproepen in acteurs. Langlopende aanroepen blokkeren andere aanroepen naar dezelfde actor, vanwege de gelijktijdigheid op basis van turn-based.
  • Als u communiceert met andere services met behulp van externe communicatie van Service Fabric en u een ServiceProxyFactory, maakt u de fabriek op actorserviceniveau en niet op actorniveau.

Toepassingsdiagnose

Wees grondig bezig met het toevoegen van toepassingslogboekregistratie in service-aanroepen. Hiermee kunt u scenario's vaststellen waarin services elkaar aanroepen. Wanneer A bijvoorbeeld B aanroept, wordt C aangeroepen D, kan de aanroep overal mislukken. Als u niet voldoende logboekregistratie hebt, zijn fouten moeilijk te diagnosticeren. Als de services zich te veel registreren vanwege oproepvolumes, moet u ten minste fouten en waarschuwingen vastleggen.

Ontwerprichtlijnen voor Azure