Dela via

Reliable Services-livscykel – översikt

  • Artikel

När du tänker på livscykeln för Azure Service Fabric Reliable Services är grunderna i livscykeln de viktigaste. I allmänhet innehåller livscykeln följande:

  • Under starten:
    • Tjänster skapas.
    • Tjänsterna har möjlighet att skapa och returnera noll eller fler lyssnare.
    • Alla returnerade lyssnare öppnas, vilket möjliggör kommunikation med tjänsten.
    • Tjänstens RunAsync-metod anropas, vilket gör att tjänsten kan utföra långvariga uppgifter eller bakgrundsarbete.
  • Under avstängning:
    • Annulleringstoken som skickas till RunAsync avbryts och lyssnarna stängs.
    • När lyssnarna har stängts förstörs själva tjänstobjektet.

Det finns information om den exakta ordningen på dessa händelser. Händelseordningen kan ändras något beroende på om Reliable Service är tillståndslös eller tillståndskänslig. För tillståndskänsliga tjänster måste vi dessutom hantera scenariot primär växling. Under den här sekvensen överförs rollen Primär till en annan replik (eller kommer tillbaka) utan att tjänsten stängs av. Slutligen måste vi tänka på fel- eller feltillstånd.

Tillståndslös tjänststart

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

  1. Tjänsten är konstruerad.
  2. StatelessService.CreateServiceInstanceListeners() anropas och alla returnerade lyssnare öppnas. ICommunicationListener.OpenAsync() anropas på varje lyssnare.
  3. Sedan händer två saker parallellt -
    • Tjänstens metod anropas StatelessService.RunAsync() .
    • Om den finns anropas tjänstens StatelessService.OnOpenAsync() metod. Det här anropet är en ovanlig åsidosättning, men det är tillgängligt. Utökade initieringsuppgifter för tjänsten kan startas just nu.

Tillståndslös tjänstavstängning

För att stänga av en tillståndslös tjänst följs samma mönster, omvänt:

  1. Alla öppna lyssnare är stängda. ICommunicationListener.CloseAsync() anropas på varje lyssnare.
  2. Annulleringstoken som skickas till RunAsync() avbryts. En kontroll av egenskapen för annulleringstoken IsCancellationRequested returnerar true, och om den anropas genererar tokenmetoden ThrowIfCancellationRequested en OperationCanceledException. Service Fabric väntar på att slutföras RunAsync() .
  3. När RunAsync() den är klar anropas tjänstens StatelessService.OnCloseAsync() metod, om den finns. OnCloseAsync anropas när den tillståndslösa tjänstinstansen kommer att stängas av korrekt. Detta kan inträffa när tjänstens kod uppgraderas, tjänstinstansen flyttas på grund av belastningsutjämning eller ett tillfälligt fel identifieras. Det är ovanligt att åsidosätta StatelessService.OnCloseAsync(), 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 av 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 liknande mönster som tillståndslösa tjänster, med några ändringar. För att starta en tillståndskänslig tjänst är händelseordningen följande:

  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. ICommunicationListener.OpenAsync() anropas på varje lyssnare.
    • Om tjänsten är en sekundär tjänst är det bara de 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. ICommunicationListener.CloseAsync() anropas på varje lyssnare.

  2. StatefulServiceBase.OnCloseAsync() -metoden anropas. Det här anropet är en ovanlig åsidosättning, men är tillgänglig.

  3. Annulleringstoken som skickas till RunAsync() avbryts. En kontroll av egenskapen för annulleringstoken IsCancellationRequested returnerar true, och om den anropas genererar tokenmetoden ThrowIfCancellationRequested en OperationCanceledException. Service Fabric väntar på att slutföras RunAsync() .

    Kommentar

    Du behöver bara vänta tills RunAsync har slutförts om repliken är en primär replik.

  4. När StatefulServiceBase.RunAsync() 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 är det bara de primära replikerna av de tillståndskänsliga tjänsterna som har sina kommunikationslyssnare öppnade och deras RunAsync-metod anropad. Sekundära repliker skapas, men inga ytterligare anrop visas. När en tillståndskänslig tjänst körs kan den replik som för närvarande är primär ändras till följd av fel- eller klusterbalanseringsoptimering. Vad innebär detta när det gäller livscykelhändelser som en replik kan se? Det beteende som den tillståndskänsliga repliken ser beror på om det är repliken som degraderas eller höjs upp under växlingen.

För den primära som degraderats

För den primära repliken som degraderas behöver Service Fabric den här repliken för att sluta bearbeta meddelanden och avsluta allt bakgrundsarbete som den utför. Därför ser det här steget ut som 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. Följande API:er anropas:

  1. Alla öppna lyssnare är stängda. ICommunicationListener.CloseAsync() anropas på varje lyssnare.
  2. Annulleringstoken som skickas till RunAsync() avbryts. En kontroll av egenskapen för annulleringstoken IsCancellationRequested returnerar true, och 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 sekundära som har befordrats

På samma sätt behöver Service Fabric den sekundära repliken som höjs upp för att börja lyssna efter meddelanden på tråden och starta eventuella bakgrundsuppgifter som den behöver slutföra. Därför ser den här processen ut som den gjorde när tjänsten skapades, förutom att själva repliken redan finns. Följande API:er anropas:

  1. ICommunicationListener.CloseAsync() anropas för alla öppnade lyssnare (markerade med ListenOnSecondary = true).
  2. Alla kommunikationslyssnare öppnas. ICommunicationListener.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 ICommunicationListener 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 olika orsaker. De vanligaste är ombalansering av kluster och programuppgradering. Under dessa åtgärder (samt under normal tjänstavstängning, som du skulle se om tjänsten togs bort), är det viktigt att tjänsten respekterar CancellationToken.

Tjänster som inte hanterar annullering rent 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älls. Om annulleringstoken inte respekteras kan det också orsaka obalanserade kluster. Kluster blir obalanserade eftersom noderna blir heta, men tjänsterna kan 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 de 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. Dessa undantag bör hanteras korrekt. Undantag som genereras av Service Fabric delas in i permanenta (FabricException) och tillfälliga (FabricTransientException) kategorier. Permanenta undantag ska loggas och genereras medan de tillfälliga undantagen kan göras om baserat på viss logik för återförsök.

Att hantera de undantag som kommer från användning av händelser i samband med tjänstlivscykeln är en viktig del av testning och validering av ReliableCollections en tillförlitlig tjänst. Vi rekommenderar att du alltid kör tjänsten under belastning när du utför 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 hanterar livscykelhändelser korrekt.

Anteckningar om tjänstens livscykel

  • RunAsync() Både metoden och anropen CreateServiceReplicaListeners/CreateServiceInstanceListeners är valfria. En tjänst kan ha en av dem, 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, eftersom tjänsten bara kan ha bakgrundsarbete att göra, och därför behöver bara implementera RunAsync().
  • Det är giltigt för en tjänst att slutföras RunAsync() och returneras från den. Slutförandet är inte ett feltillstånd. Slutförande RunAsync() anger att tjänstens bakgrundsarbete har slutförts. För tillståndskänsliga tillförlitliga tjänster RunAsync() anropas den igen om repliken degraderas från primär till sekundär och sedan befordras tillbaka till Primär.
  • Om en tjänst avslutas RunAsync() genom att utlösa ett oväntat undantag utgö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 till Reliable Collections och kan därför inte slutföra något verkligt arbete. Vi rekommenderar att du återvänder så snabbt som möjligt när du tar emot begäran om annullering. 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 resulterar i OnAbort() att anropas, vilket är en bästa 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