Dela via

Reliable Services-livscykel

  • Artikel

Reliable Services är en av de programmeringsmodeller som är tillgängliga i Azure Service Fabric. När du lär dig mer om livscykeln för Reliable Services är det viktigast att förstå de grundläggande livscykelhändelserna. Den exakta ordningen på händelser beror på konfigurationsinformationen.

I allmänhet innehåller reliable services-livscykeln följande händelser:

  • Under starten:
    • Tjänster skapas.
    • Tjänster har möjlighet att skapa och returnera noll eller fler lyssnare.
    • Alla returnerade lyssnare öppnas för kommunikation med tjänsten.
    • Tjänstens runAsync metod kallas så att tjänsten kan utföra tidskrävande arbete eller bakgrundsarbete.
  • Under avstängning:
    • Annulleringstoken som skickades till runAsync avbryts och lyssnarna stängs.
    • Själva tjänstobjektet förstörs.

Ordningen på händelser i Reliable Services kan ändras något beroende på om den tillförlitliga tjänsten är tillståndslös eller tillståndskänslig.

För tillståndskänsliga tjänster måste du också hantera det primära växlingsscenariot. Under den här sekvensen överförs rollen som primär till en annan replik (eller kommer tillbaka) utan att tjänsten stängs av.

Slutligen måste du tänka på fel- eller feltillstånd.

Tillståndslös tjänststart

Livscykeln för en tillståndslös tjänst är ganska enkel. Här är händelseordningen:

  1. Tjänsten är konstruerad.
  2. StatelessService.createServiceInstanceListeners() anropas och alla returnerade lyssnare öppnas. CommunicationListener.openAsync() anropas på varje lyssnare.
  3. Sedan parallellt:
    • Tjänstens metod (StatelessService.runAsync()) anropasrunAsync.
    • Om den finns anropas tjänstens egen onOpenAsync metod. StatelessService.onOpenAsync() Mer specifikt anropas. Det här är en ovanlig åsidosättning, men den är tillgänglig.

Tillståndslös tjänstavstängning

När du stänger av en tillståndslös tjänst följs samma mönster, men omvänt:

  1. Alla öppna lyssnare är stängda. CommunicationListener.closeAsync() anropas på varje lyssnare.
  2. Den annulleringstoken som skickades till runAsync() avbryts. Om du kontrollerar egenskapen för annulleringstoken returneras isCancelled true, och om den anropas genererar token-metoden throwIfCancellationRequested en CancellationException.
  3. När runAsync() den är klar anropas tjänstens StatelessService.onCloseAsync() metod, om den finns. Återigen är detta inte en vanlig åsidosättning, men det kan användas för att på ett säkert sätt stänga resurser, stoppa bakgrundsbearbetningen, slutföra besparingen av externt tillstånd eller stänga befintliga anslutningar.
  4. När StatelessService.onCloseAsync() tjänsten är klar förstörs tjänstobjektet.

Tillståndskänslig tjänststart

Tillståndskänsliga tjänster har ett mönster som liknar tillståndslösa tjänster, med några ändringar. Här är ordningen på händelser för att starta en tillståndskänslig tjänst:

  1. Tjänsten är konstruerad.
  2. StatefulServiceBase.onOpenAsync() anropas. Det här anropet åsidosättas vanligtvis inte i tjänsten.
  3. StatefulServiceBase.createServiceReplicaListeners() anropas.
    • Om tjänsten är en primär tjänst öppnas alla returnerade lyssnare. CommunicationListener.openAsync() anropas på varje lyssnare.
    • Om tjänsten är en sekundär tjänst är det bara lyssnare som har markerats som listenOnSecondary = true öppna. Det är mindre vanligt att ha lyssnare som är öppna på sekundärfiler.
  4. Sedan parallellt:
    • Om tjänsten för närvarande är primär anropas tjänstens StatefulServiceBase.runAsync() metod.
    • StatefulServiceBase.onChangeRoleAsync() anropas. Det här anropet åsidosättas vanligtvis inte i tjänsten.

Kommentar

För en ny sekundär replik StatefulServiceBase.onChangeRoleAsync() anropas två gånger. En gång efter steg 2, när den blir en inaktiv sekundär och igen under steg 4, när den blir en aktiv sekundär. Mer information om replik- och instanslivscykel finns i Livscykel för repliker och instanser.

Tillståndskänslig tjänstavstängning

Precis som tillståndslösa tjänster är livscykelhändelserna under avstängningen desamma som vid start, men omvända. När en tillståndskänslig tjänst stängs av inträffar följande händelser:

  1. Alla öppna lyssnare är stängda. CommunicationListener.closeAsync() anropas på varje lyssnare.
  2. Den annulleringstoken som skickades till runAsync() avbryts. Ett anrop till annulleringstokens isCancelled() -metod returnerar true, och om den anropas genererar tokenmetoden throwIfCancellationRequested() en OperationCanceledException. Service Fabric väntar på att slutföras runAsync() .

Kommentar

Att vänta runAsync på att slutföras är bara nödvändigt om den här repliken är en primär replik.

  1. När runAsync() tjänsten är klar anropas tjänstens StatefulServiceBase.onCloseAsync() metod. Det här anropet är en ovanlig åsidosättning, men det är tillgängligt.
  2. När StatefulServiceBase.onCloseAsync() tjänsten är klar förstörs tjänstobjektet.

Tillståndskänsliga primära tjänstbyten

Medan en tillståndskänslig tjänst körs öppnas kommunikationslyssnare runAsync och metoden anropas endast för de primära replikerna av dessa tillståndskänsliga tjänster. Sekundära repliker skapas, men inga ytterligare anrop visas. Medan en tillståndskänslig tjänst körs kan den replik som för närvarande är den primära ändringen. Livscykelhändelserna som en tillståndskänslig replik kan se beror på om det är repliken som degraderas eller höjs upp under växlingen.

För den degraderade primära

Service Fabric behöver den primära repliken som degraderats för att sluta bearbeta meddelanden och stoppa allt bakgrundsarbete. Det här steget liknar när tjänsten stängs av. En skillnad är att tjänsten inte förstörs eller stängs eftersom den förblir sekundär. Då inträffar följande händelser:

  1. Alla öppna lyssnare är stängda. CommunicationListener.closeAsync() anropas på varje lyssnare.
  2. Den annulleringstoken som skickades till runAsync() avbryts. En kontroll av annulleringstokens isCancelled() metod returnerar true. Om den anropas genererar tokenmetoden throwIfCancellationRequested() en OperationCanceledException. Service Fabric väntar på att slutföras runAsync() .
  3. Lyssnare som har markerats som listenOnSecondary = true öppnas.
  4. Tjänstens anropas StatefulServiceBase.onChangeRoleAsync() . Det här anropet åsidosättas vanligtvis inte i tjänsten.

För den upphöjda sekundära

På samma sätt behöver Service Fabric den sekundära replik som befordras för att börja lyssna efter meddelanden på tråden och starta eventuella bakgrundsuppgifter som den behöver slutföra. Den här processen liknar när tjänsten skapas. Skillnaden är att själva repliken redan finns. Då inträffar följande händelser:

  1. CommunicationListener.closeAsync() anropas för alla öppnade lyssnare (markerade med listenOnSecondary = true)
  2. Alla kommunikationslyssnare öppnas. CommunicationListener.openAsync() anropas på varje lyssnare.
  3. Sedan parallellt:
    • Tjänstens metod anropas StatefulServiceBase.runAsync() .
    • StatefulServiceBase.onChangeRoleAsync() anropas. Det här anropet åsidosättas vanligtvis inte i tjänsten.

Kommentar

createServiceReplicaListeners anropas bara en gång och anropas inte igen under replikhöjningen eller degraderingsprocessen. samma ServiceReplicaListener instanser används men nya CommunicationListener instanser skapas (genom att anropa ServiceReplicaListener.createCommunicationListener metoden) efter att de tidigare instanserna har stängts.

Vanliga problem vid tillståndskänslig tjänstavstängning och primär degradering

Service Fabric ändrar primärt för en tillståndskänslig tjänst av flera orsaker. De vanligaste orsakerna är ombalansering av kluster och programuppgradering. Under dessa åtgärder är det viktigt att tjänsten respekterar cancellationToken. Detta gäller även vid normal tjänstavstängning, till exempel om tjänsten togs bort.

Tjänster som inte hanterar annullering på ett rent sätt kan uppleva flera problem. De här åtgärderna är långsamma eftersom Service Fabric väntar på att tjänsterna ska stoppas på ett korrekt sätt. Detta kan i slutändan leda till misslyckade uppgraderingar som överskrider tidsgränsen och återställningen. Om annulleringstoken inte respekteras kan det också orsaka obalanserade kluster. Kluster blir obalanserade eftersom noderna blir heta. Tjänsterna kan dock inte balanseras om eftersom det tar för lång tid att flytta dem någon annanstans.

Eftersom tjänsterna är tillståndskänsliga är det också troligt att tjänsterna använder Reliable Collections. När en primär degraderas i Service Fabric är en av de första sakerna som händer att skrivåtkomsten till det underliggande tillståndet återkallas. Detta leder till en andra uppsättning problem som kan påverka tjänstens livscykel. Samlingarna returnerar undantag baserat på tidpunkten och om repliken flyttas eller stängs av. Det är viktigt att hantera dessa undantag på rätt sätt.

Undantag som genereras av Service Fabric är antingen permanenta (FabricException) eller tillfälliga (FabricTransientException). Permanenta undantag ska loggas och genereras. Tillfälliga undantag kan göras om baserat på logik för omförsök.

En viktig del av testning och validering av Reliable Services är att hantera de undantag som kommer från användning av ReliableCollections händelser i samband med tjänstlivscykel. Vi rekommenderar att du alltid kör tjänsten under belastning. Du bör också utföra uppgraderingar och kaostestning innan du distribuerar till produktion. De här grundläggande stegen hjälper till att säkerställa att tjänsten implementeras korrekt och att den hanterar livscykelhändelser korrekt.

Anteckningar om tjänstens livscykel

  • runAsync() Både metoden och anropen createServiceInstanceListeners/createServiceReplicaListeners är valfria. En tjänst kan ha en, båda eller ingen av dem. Om tjänsten till exempel utför allt sitt arbete som svar på användaranrop behöver den inte implementera runAsync(). Endast kommunikationslyssnare och deras associerade kod är nödvändiga. På samma sätt är det valfritt att skapa och returnera kommunikationslyssnare. Tjänsten kanske bara har bakgrundsarbete att göra, så den behöver bara implementera runAsync().
  • Det är giltigt för en tjänst att slutföras runAsync() och returneras från den. Detta anses inte vara ett feltillstånd. Den representerar bakgrundsarbetet för tjänstavslutningen. För tillståndskänsliga Reliable Services runAsync() anropas du igen om tjänsten degraderas från primär och sedan befordras tillbaka till primär.
  • Om en tjänst avslutas runAsync() genom att utlösa ett oväntat undantag är detta ett fel. Tjänstobjektet stängs av och ett hälsofel rapporteras.
  • Även om det inte finns någon tidsgräns för att återvända från dessa metoder förlorar du omedelbart möjligheten att skriva. Därför kan du inte slutföra något verkligt arbete. Vi rekommenderar att du återvänder så snabbt som möjligt när du tar emot annulleringsbegäran. Om tjänsten inte svarar på dessa API-anrop inom rimlig tid kan Service Fabric med två skäl avsluta tjänsten. Detta sker vanligtvis bara under programuppgraderingar eller när en tjänst tas bort. Tidsgränsen är som standard 15 minuter.
  • Fel i onCloseAsync() sökvägen leder till onAbort() att anropas. Det här anropet är en sista chans, bästa möjliga möjlighet för tjänsten att rensa och frigöra alla resurser som de har begärt. Detta kallas vanligtvis när ett permanent fel identifieras på noden, eller när Service Fabric inte på ett tillförlitligt sätt kan hantera tjänstinstansens livscykel på grund av interna fel.
  • OnChangeRoleAsync() anropas när den tillståndskänsliga tjänstrepliken ändrar roll, till exempel till primär eller sekundär. Primära repliker får skrivstatus (tillåts skapa och skriva till Reliable Collections). Sekundära repliker får lässtatus (kan bara läsas från befintliga tillförlitliga samlingar). De flesta arbeten i en tillståndskänslig tjänst utförs på den primära repliken. Sekundära repliker kan utföra skrivskyddad validering, rapportgenerering, datautvinning eller andra skrivskyddade jobb.

Nästa steg