Megbízható szolgáltatások életciklusának áttekintése

• C# Windowson
• Java Linuxon

Amikor az Azure Service Fabric Reliable Services életciklusára gondol, az életciklus alapjai a legfontosabbak. Az életciklus általában a következőket tartalmazza:

• Indításkor:
  • A szolgáltatások létre lettek építve.
  • A szolgáltatásoknak lehetőségük van nulla vagy több figyelő létrehozására és visszaadására.
  • A visszaadott figyelők megnyílnak, lehetővé téve a szolgáltatással való kommunikációt.
  • A rendszer meghívja a szolgáltatás RunAsync metódusát, amely lehetővé teszi, hogy a szolgáltatás hosszú ideig futó feladatokat vagy háttérmunkát végez.
• Leállítás során:
  • A RunAsyncnek átadott lemondási jogkivonat megszakad, és a figyelők le lesznek zárva.
  • A figyelők bezárása után maga a szolgáltatásobjektum is megszűnik.

Az események pontos sorrendje körül vannak részletek. Az események sorrendje kissé változhat attól függően, hogy a Reliable Service állapot nélküli vagy állapotalapú. Emellett az állapotalapú szolgáltatások esetében az elsődleges felcserélési forgatókönyvvel kell foglalkoznunk. Ebben a sorozatban az elsődleges szerepkör átkerül egy másik replikába (vagy visszatér), a szolgáltatás leállítása nélkül. Végül gondolnunk kell a hibákra vagy a hibákra.

Állapot nélküli szolgáltatás indítása

Az állapot nélküli szolgáltatások életciklusa egyszerű. Az események sorrendje a következő:

1. A szolgáltatás létre van építve.
2. StatelessService.CreateServiceInstanceListeners() a rendszer meghívja, és minden visszaadott figyelő megnyílik. ICommunicationListener.OpenAsync() minden figyelőn meghívja.
3. Aztán, párhuzamosan, két dolog történik -
   • A szolgáltatás metódusának meghívása StatelessService.RunAsync() .
   • Ha van ilyen, a szolgáltatás metódusának meghívása StatelessService.OnOpenAsync() történik. Ez a hívás nem gyakori felülbírálás, de elérhető. A kiterjesztett szolgáltatás inicializálási feladatai jelenleg elindíthatók.

Állapot nélküli szolgáltatás leállítása

Az állapot nélküli szolgáltatások leállításához ugyanazt a mintát követi a rendszer, csak fordított sorrendben:

1. A nyitott figyelők zárva vannak. ICommunicationListener.CloseAsync() minden figyelőn meghívja.
2. Az átadott RunAsync() lemondási jogkivonat le lesz mondva. A lemondási jogkivonat tulajdonságának IsCancellationRequested ellenőrzése igaz értéket ad vissza, és ha meghívják, a jogkivonat metódusa ThrowIfCancellationRequested egy OperationCanceledException. A Service Fabric megvárja a RunAsync() befejezést.
3. A befejezés után RunAsync() a szolgáltatás metódusának meghívása StatelessService.OnCloseAsync() történik, ha van ilyen. Az OnCloseAsync akkor lesz meghívva, ha az állapot nélküli szolgáltatáspéldány kecsesen le lesz állítva. Ez akkor fordulhat elő, ha a szolgáltatás kódját frissítik, a szolgáltatáspéldányt terheléselosztás miatt áthelyezik, vagy átmeneti hibát észlelnek. Nem gyakori a felülbírálás StatelessService.OnCloseAsync(), de használható az erőforrások biztonságos bezárására, a háttérfeldolgozás leállítására, a külső állapot mentésének befejezésére vagy a meglévő kapcsolatok bezárására.
4. A befejezés után StatelessService.OnCloseAsync() a szolgáltatásobjektum fel lesz bontva.

Állapotalapú szolgáltatás indítása

Az állapotalapú szolgáltatások mintázata az állapot nélküli szolgáltatásokhoz hasonló, néhány módosítással. Állapotalapú szolgáltatás indításához az események sorrendje a következő:

1. A szolgáltatás létre van építve.

2. StatefulServiceBase.OnOpenAsync() meghívva. Ez a hívás általában nem felül van bírálva a szolgáltatásban.

3. StatefulServiceBase.CreateServiceReplicaListeners() meghívásra kerül.

   • Ha a szolgáltatás elsődleges szolgáltatás, az összes visszaadott figyelő megnyílik. ICommunicationListener.OpenAsync() minden figyelőn meghívja.
   • Ha a szolgáltatás másodlagos szolgáltatás, akkor csak azok a figyelők nyílnak meg, akik megjelöltek.ListenOnSecondary = true A másodfokon megnyitott figyelők kevésbé gyakoriak.

4. Ezután párhuzamosan:

   • Ha a szolgáltatás jelenleg elsődleges, a szolgáltatás metódusának meghívása StatefulServiceBase.RunAsync() történik.
   • StatefulServiceBase.OnChangeRoleAsync() meghívva. Ez a hívás általában nem felül van bírálva a szolgáltatásban.

   Feljegyzés

   Egy új másodlagos replika StatefulServiceBase.OnChangeRoleAsync() esetében a rendszer kétszer hívja meg. A 2. lépés után egyszer, amikor inaktív másodlagossá válik, majd a 4. lépésben, amikor aktív másodlagossá válik. A replikával és a példány életciklusával kapcsolatos további információkért olvassa el a replika és a példány életciklusát.

Állapotalapú szolgáltatás leállítása

Az állapot nélküli szolgáltatásokhoz hasonlóan a leállítás alatti életciklus-események is ugyanazok, mint az indításkor, de fordítottak. Állapotalapú szolgáltatás leállítása esetén a következő események következnek be:

1. A nyitott figyelők zárva vannak. ICommunicationListener.CloseAsync() minden figyelőn meghívja.

2. StatefulServiceBase.OnCloseAsync() metódus meghívása. Ez a hívás nem gyakori felülbírálás, de elérhető.

3. Az átadott RunAsync() lemondási jogkivonat le lesz mondva. A lemondási jogkivonat tulajdonságának IsCancellationRequested ellenőrzése igaz értéket ad vissza, és ha meghívják, a jogkivonat metódusa ThrowIfCancellationRequested egy OperationCanceledException. A Service Fabric megvárja a RunAsync() befejezést.

   Feljegyzés

   A RunAsync befejezésére csak akkor van szükség, ha ez a replika elsődleges replika.

4. A befejezés után StatefulServiceBase.RunAsync() a szolgáltatásobjektum fel lesz bontva.

Állapotalapú szolgáltatás elsődleges felcserélése

Miközben egy állapotalapú szolgáltatás fut, csak az állapotalapú szolgáltatások elsődleges replikái nyitották meg a kommunikációs figyelőket, és meghívták a RunAsync metódust. A másodlagos replikák létre lettek állítva, de nem látnak további hívásokat. Miközben egy állapotalapú szolgáltatás fut, az elsődleges replika a hiba vagy a fürtelosztás optimalizálása miatt változhat. Mit jelent ez a replika által látható életciklus-események szempontjából? Az állapotalapú replika viselkedése attól függ, hogy lefokozzák vagy előléptetik-e a replikát a felcserélés során.

A lefokozott elsődleges esetében

A lefokozott elsődleges replika esetében a Service Fabricnek szüksége van erre a replikára, hogy leállítja az üzenetek feldolgozását, és kilépjen az általa végzett háttérmunkákból. Ennek eredményeképpen ez a lépés úgy néz ki, mint a szolgáltatás leállásakor. Az egyik különbség az, hogy a szolgáltatás nem destrukált vagy bezárt, mert másodlagos marad. A rendszer a következő API-kat hívja meg:

1. A nyitott figyelők zárva vannak. ICommunicationListener.CloseAsync() minden figyelőn meghívja.
2. Az átadott RunAsync() lemondási jogkivonat le lesz mondva. A lemondási jogkivonat tulajdonságának IsCancellationRequested ellenőrzése igaz értéket ad vissza, és ha meghívják, a jogkivonat metódusa ThrowIfCancellationRequested egy OperationCanceledException. A Service Fabric megvárja a RunAsync() befejezést.
3. A ListenOnSecondary = true értékként megjelölt figyelők meg vannak nyitva.
4. A szolgáltatás StatefulServiceBase.OnChangeRoleAsync() neve. Ez a hívás általában nem felül van bírálva a szolgáltatásban.

A másodlagos előléptetett

Hasonlóképpen, a Service Fabricnek szüksége van a másodlagos replikára, amely elő van léptetve ahhoz, hogy elkezdje figyelni a vezetéken lévő üzeneteket, és elindítsa a szükséges háttérfeladatokat. Ennek eredményeképpen ez a folyamat úgy néz ki, mint a szolgáltatás létrehozásakor, kivéve, hogy maga a replika már létezik. A rendszer a következő API-kat hívja meg:

1. ICommunicationListener.CloseAsync() a rendszer az összes megnyitott figyelőhöz meghívja (a ListenOnSecondary = true jelöléssel van megjelölve).
2. Minden kommunikációs figyelő meg van nyitva. ICommunicationListener.OpenAsync() minden figyelőn meghívja.
3. Ezután párhuzamosan:
   • A szolgáltatás metódusának meghívása StatefulServiceBase.RunAsync() .
   • StatefulServiceBase.OnChangeRoleAsync() meghívva. Ez a hívás általában nem felül van bírálva a szolgáltatásban.

Feljegyzés

CreateServiceReplicaListeners a rendszer csak egyszer hívja meg, és nem hívja meg újra a replika előléptetése vagy lefokozása során; ugyanazokat ServiceReplicaListener a példányokat használja a rendszer, de az előző példányok bezárása után új ICommunicationListener példányok jönnek létre (a ServiceReplicaListener.CreateCommunicationListener metódus meghívásával).

Gyakori problémák az állapotalapú szolgáltatás leállítása és az elsődleges lefokozás során

A Service Fabric számos okból módosítja egy állapotalapú szolgáltatás elsődleges szolgáltatását. A leggyakoribbak a fürtök újraegyensúlyozása és az alkalmazások frissítése. Ezen műveletek során (valamint a normál szolgáltatásleállítás során, például a szolgáltatás törlésekor) fontos, hogy a szolgáltatás tiszteletben tartsa a CancellationToken.

Azok a szolgáltatások, amelyek nem kezelik tisztán a lemondást, számos problémát tapasztalhatnak. Ezek a műveletek lassúak, mert a Service Fabric megvárja, amíg a szolgáltatások kecsesen leállnak. Ez végső soron a sikertelen frissítésekhez vezethet, amelyek időtúllépést okoznak, és visszaválthatnak. A lemondási jogkivonat be nem tartása kiegyensúlyozatlan fürtöket is okozhat. A fürtök kiegyensúlyozatlanná válnak, mert a csomópontok felforrósodnak, de a szolgáltatások nem egyensúlyozhatók újra, mert túl sokáig tart máshová áthelyezni őket.

Mivel a szolgáltatások állapotalapúak, valószínű, hogy a Reliable Collections szolgáltatást használják. A Service Fabricben az elsődleges lefokozásakor az egyik első dolog, hogy visszavonják az alapul szolgáló állapot írási hozzáférését. Ez a szolgáltatás életciklusát befolyásoló problémák második csoportjához vezet. A gyűjtemények kivételeket adnak vissza az időzítés és a replika áthelyezése vagy leállítása alapján. Ezeket a kivételeket helyesen kell kezelni. A Service Fabric által kidobott kivételek állandó (FabricException) és átmeneti (FabricTransientException) kategóriákba sorolhatók. Az állandó kivételeket naplózni és dobni kell, míg az átmeneti kivételeket újra lehet próbálkozni egy újrapróbálkozási logika alapján.

A megbízható szolgáltatás tesztelésének és érvényesítésének fontos része a ReliableCollections szolgáltatás életciklus-eseményekkel együtt történő használatából eredő kivételek kezelése. Javasoljuk, hogy az éles üzembe helyezés előtt mindig a terhelés alatt futtassa a szolgáltatást a frissítések és a káosz tesztelése során. Ezek az alapvető lépések segítenek biztosítani, hogy a szolgáltatás megfelelően implementálva legyen, és megfelelően kezelje az életciklus-eseményeket.

Megjegyzések a szolgáltatás életciklusáról

• RunAsync() A metódus és a CreateServiceReplicaListeners/CreateServiceInstanceListeners hívások nem kötelezőek. Egy szolgáltatáshoz tartozhat mindkettő, vagy egyik sem. Ha például a szolgáltatás minden munkáját a felhasználói hívásokra válaszul végzi, nincs szükség a implementálásra RunAsync(). Csak a kommunikációs figyelőkre és a hozzájuk tartozó kódra van szükség. Hasonlóképpen a kommunikációs figyelők létrehozása és visszaadása nem kötelező, mivel a szolgáltatásnak csak háttérmunkával kell rendelkeznie, ezért csak implementálnia RunAsync()kell.
• Érvényes, hogy egy szolgáltatás sikeresen befejeződik RunAsync() , és visszatér onnan. A befejezés nem hibafeltétel. A befejezés RunAsync() azt jelzi, hogy a szolgáltatás háttérmunka befejeződött. Állapotalapú megbízható szolgáltatások esetén a rendszer újra meghívja, RunAsync() ha a replikát lefokozták az elsődlegesről a másodlagosra, majd előléptetik az elsődlegesre.
• Ha egy szolgáltatás váratlan kivétellel lép ki a rendszerből RunAsync() , az hibát jelent. A szolgáltatásobjektum le van állítva, és állapothiba jelenik meg.
• Bár ezekből a módszerekből nincs időkorlát, azonnal elveszíti a megbízható gyűjteményekbe való írás képességét, ezért nem tud valódi munkát végezni. Javasoljuk, hogy a lemondási kérelem beérkezésekor a lehető leggyorsabban térjen vissza. Ha a szolgáltatás ésszerű időn belül nem válaszol ezekre az API-hívásokra, a Service Fabric kényszerítve megszüntetheti a szolgáltatást. Ez általában csak az alkalmazásfrissítések vagy egy szolgáltatás törlése során történik. Ez az időkorlát alapértelmezés szerint 15 perc.
• Az elérési út hibáinak OnCloseAsync() meghívása OnAbort() az utolsó esély arra, hogy a szolgáltatás megtisztítsa és felszabadítsa az általuk igényelt erőforrásokat. Ezt általában akkor hívják, ha a csomóponton állandó hiba észlelhető, vagy ha a Service Fabric belső hibák miatt nem tudja megbízhatóan kezelni a szolgáltatáspéldány életciklusát.
• OnChangeRoleAsync() a rendszer akkor hívja meg, ha az állapotalapú szolgáltatásreplika szerepkört módosít, például elsődleges vagy másodlagos. Az elsődleges replikák írási állapotot kapnak (a megbízható gyűjtemények létrehozása és írása engedélyezett). A másodlagos replikák olvasási állapotban vannak (csak meglévő megbízható gyűjteményekből olvashatók). Az állapotalapú szolgáltatásban a legtöbb munka az elsődleges replikán történik. A másodlagos replikák írásvédett ellenőrzést, jelentéskészítést, adatbányászatot vagy más írásvédett feladatokat is végrehajthatnak.

Következő lépések

• A Reliable Services bemutatása
• Reliable Services – gyors üzembe helyezés
• Replikák és példányok