Delen via

Levenscyclus van Reliable Services

  • Artikel

Reliable Services is een van de programmeermodellen die beschikbaar zijn in Azure Service Fabric. Wanneer u meer wilt weten over de levenscyclus van Reliable Services, is het belangrijk dat u de basislevenscyclus-gebeurtenissen begrijpt. De exacte volgorde van gebeurtenissen is afhankelijk van configuratiedetails.

Over het algemeen omvat de levenscyclus van Reliable Services de volgende gebeurtenissen:

  • Tijdens het opstarten:
    • Services worden samengesteld.
    • Services hebben de mogelijkheid om nul of meer listeners te bouwen en te retourneren.
    • Alle geretourneerde listeners worden geopend voor communicatie met de service.
    • De methode van runAsync de service wordt aangeroepen, zodat de service langlopend of achtergrondwerk kan uitvoeren.
  • Tijdens het afsluiten:
    • Het annuleringstoken waaraan is doorgegeven runAsync , wordt geannuleerd en de listeners worden gesloten.
    • Het serviceobject zelf is gedestructeerd.

De volgorde van gebeurtenissen in Reliable Services kan enigszins veranderen, afhankelijk van of de betrouwbare service staatloos of stateful is.

Voor stateful services moet u ook het primaire swapscenario aanpakken. Tijdens deze reeks wordt de rol van primair adres overgebracht naar een andere replica (of wordt teruggestuurd) zonder dat de service wordt afgesloten.

Ten slotte moet u nadenken over fout- of foutvoorwaarden.

Stateless service opstarten

De levenscyclus van een staatloze service is vrij eenvoudig. Dit is de volgorde van gebeurtenissen:

  1. De service is samengesteld.
  2. StatelessService.createServiceInstanceListeners() wordt aangeroepen en alle geretourneerde listeners worden geopend. CommunicationListener.openAsync() wordt op elke listener aangeroepen.
  3. Vervolgens parallel:
    • De methode (StatelessService.runAsync()) van runAsync de service wordt aangeroepen.
    • Indien aanwezig, wordt de eigen onOpenAsync methode van de service aangeroepen. Met name wordt StatelessService.onOpenAsync() aangeroepen. Dit is een ongebruikelijke onderdrukking, maar deze is beschikbaar.

Stateless service afsluiten

Bij het afsluiten van een staatloze service wordt hetzelfde patroon gevolgd, maar omgekeerd:

  1. Alle open listeners worden gesloten. CommunicationListener.closeAsync() wordt op elke listener aangeroepen.
  2. Het annuleringstoken waaraan is doorgegeven runAsync() , wordt geannuleerd. Als u de eigenschap van isCancelled het annuleringstoken controleert true, wordt de methode van throwIfCancellationRequested het token een CancellationException.
  3. Wanneer runAsync() deze is voltooid, wordt de methode van StatelessService.onCloseAsync() de service aangeroepen, als deze aanwezig is. Dit is nogmaals geen veelvoorkomende onderdrukking, maar kan worden gebruikt om resources veilig te sluiten, achtergrondverwerking te stoppen, externe status op te slaan of bestaande verbindingen te sluiten.
  4. Nadat StatelessService.onCloseAsync() het is voltooid, wordt het serviceobject gedestructeerd.

Stateful service opstarten

Stateful services hebben een patroon dat vergelijkbaar is met stateless services, met enkele wijzigingen. Hier volgt de volgorde van gebeurtenissen voor het starten van een stateful service:

  1. De service is samengesteld.
  2. StatefulServiceBase.onOpenAsync() wordt aangeroepen. Deze aanroep wordt meestal niet overschreven in de service.
  3. StatefulServiceBase.createServiceReplicaListeners() wordt aangeroepen.
    • Als de service een primaire service is, worden alle geretourneerde listeners geopend. CommunicationListener.openAsync() wordt op elke listener aangeroepen.
    • Als de service een secundaire service is, worden alleen listeners geopend die zijn gemarkeerd als listenOnSecondary = true geopend. Het hebben van listeners die open zijn op secundaire bestanden is minder gebruikelijk.
  4. Vervolgens parallel:
    • Als de service momenteel een primaire service is, wordt de methode van StatefulServiceBase.runAsync() de service aangeroepen.
    • StatefulServiceBase.onChangeRoleAsync() wordt aangeroepen. Deze aanroep wordt meestal niet overschreven in de service.

Notitie

Voor een nieuwe secundaire replica wordt StatefulServiceBase.onChangeRoleAsync() twee keer aangeroepen. Eenmaal na stap 2, wanneer het een niet-actieve secundaire en opnieuw tijdens stap 4 wordt, wanneer het een actieve secundaire wordt. Lees replica- en exemplaarlevenscyclus voor meer informatie over de levenscyclus van replica's en exemplaren.

Stateful service afsluiten

Net als stateless services zijn de levenscyclusgebeurtenissen tijdens het afsluiten hetzelfde als tijdens het opstarten, maar omgekeerd. Wanneer een stateful service wordt afgesloten, vinden de volgende gebeurtenissen plaats:

  1. Alle open listeners worden gesloten. CommunicationListener.closeAsync() wordt op elke listener aangeroepen.
  2. Het annuleringstoken waaraan is doorgegeven runAsync() , wordt geannuleerd. Een aanroep naar de methode van isCancelled() het annuleringstoken retourneert true, en als dit wordt aangeroepen, genereert de methode van throwIfCancellationRequested() het token een OperationCanceledException. Service Fabric wacht totdat runAsync() het is voltooid.

Notitie

Wachten op runAsync voltooiing is alleen nodig als deze replica een primaire replica is.

  1. Nadat runAsync() de service StatefulServiceBase.onCloseAsync() is voltooid, wordt de methode aangeroepen. Deze aanroep is een ongebruikelijke onderdrukking, maar deze is beschikbaar.
  2. Nadat StatefulServiceBase.onCloseAsync() het is voltooid, wordt het serviceobject gedestructeerd.

Primaire wisselingen van stateful services

Terwijl een stateful service wordt uitgevoerd, worden communicatielisteners geopend en wordt de runAsync methode alleen aangeroepen voor de primaire replica's van die stateful services. Secundaire replica's worden samengesteld, maar zien geen verdere aanroepen. Terwijl een stateful service wordt uitgevoerd, kan de replica die momenteel de primaire service is, wijzigen. De levenscyclusgebeurtenissen die een stateful replica kan zien, is afhankelijk van of de replica wordt gedegradeerd of gepromoveerd tijdens de wissel.

Voor de gedegradeerde primaire

Service Fabric heeft de primaire replica nodig die wordt gedegradeerd om het verwerken van berichten te stoppen en eventuele achtergrondwerkzaamheden te stoppen. Deze stap is vergelijkbaar met wanneer de service wordt afgesloten. Een verschil is dat de service niet wordt gedestructeerd of gesloten, omdat deze als secundaire service blijft. De volgende gebeurtenissen vinden plaats:

  1. Alle open listeners worden gesloten. CommunicationListener.closeAsync() wordt op elke listener aangeroepen.
  2. Het annuleringstoken waaraan is doorgegeven runAsync() , wordt geannuleerd. Een controle van de methode van isCancelled() het annuleringstoken retourneert true. Als het wordt aangeroepen, genereert de methode van throwIfCancellationRequested() het token een OperationCanceledException. Service Fabric wacht totdat runAsync() het is voltooid.
  3. Listeners die zijn gemarkeerd als listenOnSecondary = true, worden geopend.
  4. De service StatefulServiceBase.onChangeRoleAsync() wordt aangeroepen. Deze aanroep wordt meestal niet overschreven in de service.

Voor de gepromoveerde secundaire

Op dezelfde manier heeft Service Fabric de secundaire replica nodig die wordt gepromoveerd om te beginnen met luisteren naar berichten op de kabel en om eventuele achtergrondtaken te starten die moeten worden voltooid. Dit proces is vergelijkbaar met wanneer de service wordt gemaakt. Het verschil is dat de replica zelf al bestaat. De volgende gebeurtenissen vinden plaats:

  1. CommunicationListener.closeAsync() wordt aangeroepen voor alle geopende listeners (gemarkeerd met listenOnSecondary = true)
  2. Alle communicatielisteners worden geopend. CommunicationListener.openAsync() wordt op elke listener aangeroepen.
  3. Vervolgens parallel:
    • De methode van StatefulServiceBase.runAsync() de service wordt aangeroepen.
    • StatefulServiceBase.onChangeRoleAsync() wordt aangeroepen. Deze aanroep wordt meestal niet overschreven in de service.

Notitie

createServiceReplicaListeners wordt slechts één keer aangeroepen en wordt niet opnieuw aangeroepen tijdens het promotie- of degradatieproces van de replica; dezelfde ServiceReplicaListener exemplaren worden gebruikt, maar er worden nieuwe CommunicationListener exemplaren gemaakt (door de ServiceReplicaListener.createCommunicationListener methode aan te roepen) nadat de vorige exemplaren zijn gesloten.

Veelvoorkomende problemen tijdens het afsluiten van stateful services en primaire degradatie

Service Fabric wijzigt om verschillende redenen de primaire van een stateful service. De meest voorkomende redenen zijn het opnieuw verdelen van clusters en het upgraden van toepassingen. Tijdens deze bewerkingen is het belangrijk dat de service de cancellationToken. Dit geldt ook tijdens het afsluiten van de normale service, bijvoorbeeld als de service is verwijderd.

Services die niet op een schone manier omgaan met annulering, kunnen verschillende problemen ondervinden. Deze bewerkingen zijn traag omdat Service Fabric wacht tot de services correct zijn gestopt. Dit kan uiteindelijk leiden tot mislukte upgrades die time-out en terugdraaien. Als u het annuleringstoken niet nakomt, kan dit ook onevenwichtige clusters veroorzaken. Clusters worden onevenwichtig omdat knooppunten dynamisch worden. De services kunnen echter niet opnieuw worden geherbalanceerd omdat het te lang duurt om ze ergens anders te verplaatsen.

Omdat de services stateful zijn, is het ook waarschijnlijk dat de services Betrouwbare verzamelingen gebruiken. Wanneer in Service Fabric een primaire status wordt gedegradeerd, is een van de eerste dingen die gebeuren dat schrijftoegang tot de onderliggende status wordt ingetrokken. Dit leidt tot een tweede reeks problemen die van invloed kunnen zijn op de levenscyclus van de service. De verzamelingen retourneren uitzonderingen op basis van de timing en of de replica wordt verplaatst of afgesloten. Het is belangrijk om deze uitzonderingen correct af te handelen.

Uitzonderingen die worden gegenereerd door Service Fabric, zijn permanent (FabricException) of tijdelijk (FabricTransientException). Permanente uitzonderingen moeten worden vastgelegd en gegenereerd. Tijdelijke uitzonderingen kunnen opnieuw worden geprobeerd op basis van logica voor opnieuw proberen.

Een belangrijk onderdeel van het testen en valideren van Reliable Services is het verwerken van de uitzonderingen die afkomstig zijn van het gebruik van de ReliableCollections levenscyclus van de service. U wordt aangeraden uw service altijd onder belasting uit te voeren. U moet ook upgrades en chaostests uitvoeren voordat u in productie implementeert. Deze basisstappen helpen ervoor te zorgen dat uw service correct wordt geïmplementeerd en dat deze levenscyclus-gebeurtenissen correct verwerkt.

Opmerkingen over de levenscyclus van de service

  • Zowel de runAsync() methode als de createServiceInstanceListeners/createServiceReplicaListeners aanroepen zijn optioneel. Een service kan één, beide of geen van beide hebben. Als de service bijvoorbeeld al het werk uitvoert als reactie op gebruikersaanroepen, is het niet nodig om deze te implementeren runAsync(). Alleen de communicatielisteners en de bijbehorende code zijn nodig. Op dezelfde manier is het maken en retourneren van communicatielisteners optioneel. De service heeft mogelijk alleen achtergrondwerk te doen, dus hoeft deze alleen te implementeren runAsync().
  • Het is geldig voor een service om deze te voltooien runAsync() en terug te keren. Dit wordt niet beschouwd als een foutvoorwaarde. Het vertegenwoordigt het achtergrondwerk van de serviceafwerking. Voor stateful Reliable Services runAsync() wordt deze opnieuw aangeroepen als de service wordt gedegradeerd van de primaire service en vervolgens weer wordt gepromoveerd naar primaire services.
  • Als een service wordt afgesloten runAsync() door een onverwachte uitzondering te genereren, is dit een fout. Het serviceobject wordt afgesloten en er wordt een statusfout gerapporteerd.
  • Hoewel er geen tijdslimiet is voor het retourneren van deze methoden, verliest u onmiddellijk de mogelijkheid om te schrijven. Daarom kunt u geen echt werk voltooien. We raden u aan zo snel mogelijk terug te keren na ontvangst van de annuleringsaanvraag. Als uw service niet binnen een redelijke tijd op deze API-aanroepen reageert, kan Service Fabric uw service geforceerd beëindigen. Dit gebeurt meestal alleen tijdens het upgraden van toepassingen of wanneer een service wordt verwijderd. Deze time-out is standaard 15 minuten.
  • Fouten in het onCloseAsync() padresultaat worden onAbort() aangeroepen. Deze aanroep is een laatste kans, beste inspanningskans voor de service om resources op te schonen en vrij te geven die ze hebben geclaimd. Dit wordt meestal aangeroepen wanneer er een permanente fout op het knooppunt wordt gedetecteerd of wanneer Service Fabric de levenscyclus van het service-exemplaar niet betrouwbaar kan beheren vanwege interne fouten.
  • OnChangeRoleAsync() wordt aangeroepen wanneer de stateful servicereplica de rol wijzigt, bijvoorbeeld naar primaire of secundaire replica. Primaire replica's krijgen de schrijfstatus (mogen betrouwbare verzamelingen maken en schrijven). Secundaire replica's krijgen de leesstatus (kan alleen worden gelezen uit bestaande Betrouwbare verzamelingen). Het meeste werk in een stateful service wordt uitgevoerd op de primaire replica. Secundaire replica's kunnen alleen-lezenvalidatie, rapportgeneratie, gegevensanalyse of andere alleen-lezen taken uitvoeren.

Volgende stappen