A Reliable Services áttekintése

  • Cikk

Az Azure Service Fabric leegyszerűsíti az állapot nélküli és állapotalapú szolgáltatások írását és kezelését. Ez a témakör a következőkkel foglalkozik:

  • A Reliable Services programozási modell állapot nélküli és állapotalapú szolgáltatásokhoz.
  • A Reliable Service írása során meghozandó döntések.
  • Néhány forgatókönyv és példa arra, hogy mikor érdemes használni a Reliable Servicest, és hogyan kell megírni őket.

A Reliable Services a Service Fabricben elérhető egyik programozási modell. A másik a Reliable Actor programozási modell, amely a Reliable Services-modellen felül egy Virtual Actor alkalmazás-keretrendszert biztosít. További információ a Reliable Actorsről: Bevezetés a Service Fabric Reliable Actors használatába.

A Service Fabric kezeli a szolgáltatások élettartamát a kiépítéstől és az üzembe helyezéstől a frissítésen és törlésen keresztül a Service Fabric-alkalmazáskezelésen keresztül.

Mik azok a Reliable Services

A Reliable Services egyszerű, hatékony, legfelső szintű programozási modellt biztosít, amellyel kifejezheti az alkalmazás szempontjából fontos dolgokat. A Reliable Services programozási modellel a következőket érheti el:

  • Hozzáférés a Service Fabric API-khoz. A Vendég végrehajtható fájlokként modellezett Service Fabric-szolgáltatásoktól eltérően a Reliable Services közvetlenül használhatja a Service Fabric API-kat. Ez lehetővé teszi a szolgáltatások számára a következőket:
    • A rendszer lekérdezése
    • A fürt entitásainak állapotjelentése
    • Értesítések fogadása a konfigurációról és a kódmódosításokról
    • Keresés és kommunikáció más szolgáltatásokkal,
    • A Reliable Collections használata
    • Számos más képességhez is hozzáférhet, mindezt egy első osztályú programozási modellből, számos programozási nyelven.
  • Egy egyszerű modell a saját kód futtatásához, amely más ismerős programozási modellekhez hasonlóan működik. A kód jól meghatározott belépési ponttal és könnyen felügyelt életciklussal rendelkezik.
  • Egy csatlakoztatható kommunikációs modell. Használja a választott átvitelt, például a HTTP-t webes API-val, WebSocket-ekkel, egyéni TCP-protokollokkal vagy bármi másvalakivel. A Reliable Services nagyszerű beépített lehetőségeket kínál, de saját lehetőségeket is biztosít.
  • Állapotalapú szolgáltatások esetén a Reliable Services programozási modell lehetővé teszi az állapot következetes és megbízható tárolását közvetlenül a szolgáltatásban a Reliable Collections használatával. A Reliable Collections a magas rendelkezésre állású és megbízható gyűjteményosztályok egyszerű készlete, amely mindenki számára ismerős lesz, aki C#-gyűjteményeket használt. A szolgáltatásoknak hagyományosan külső rendszerekre volt szükségük a Reliable State Managementhez. A Reliable Collections segítségével a számítás mellett tárolhatja az állapotát ugyanazzal a magas rendelkezésre állással és megbízhatósággal, mint amit a magas rendelkezésre állású külső tárolóktól elvárt. Ez a modell a késést is javítja, mivel a számítást és a működéshez szükséges állapotot társmeghatározással javítja.

Mitől különbözik a Reliable Services?

A Reliable Services különbözik a korábban megírt szolgáltatásoktól, mivel a Service Fabric a következőket biztosítja:

  • Megbízhatóság – A szolgáltatás akkor is működik, ha a gépek meghibásodnak vagy hálózati problémákba ütköznek, vagy ha a szolgáltatások maguk is hibákat tapasztalnak, és összeomlanak vagy meghibásodnak. Állapotalapú szolgáltatások esetén az állapot még hálózati vagy egyéb hibák esetén is megmarad.
  • Rendelkezésre állás – A szolgáltatás elérhető és rugalmas. A Service Fabric fenntartja a kívánt számú futó példányt.
  • Méretezhetőség – A szolgáltatások egyes hardverektől függetlenítve, és szükség szerint növekedhetnek vagy zsugorodhatnak a hardverek vagy egyéb erőforrások hozzáadásával vagy eltávolításával. A szolgáltatások könnyen particionálhatók (különösen állapotalapú esetben), hogy a szolgáltatás képes legyen a részleges hibák skálázására és kezelésére. A szolgáltatások dinamikusan, kódon keresztül hozhatók létre és törölhetők, így szükség szerint további példányok hozhatók létre, például ügyfélkérésekre reagálva. Végül a Service Fabric arra ösztönzi a szolgáltatásokat, hogy egyszerűek legyenek. A Service Fabric több ezer szolgáltatás egyetlen folyamaton belül történő kiépítését teszi lehetővé, ahelyett, hogy teljes operációsrendszer-példányokat vagy folyamatokat kellene egy szolgáltatás egyetlen példányának megadnia vagy dedikálnia.
  • Konzisztencia – A Reliable Service-ben tárolt információk garantáltan konzisztensek. Ez a szolgáltatáson belüli több megbízható gyűjteményre is igaz. A szolgáltatáson belüli gyűjtemények módosításai tranzakcióslag atomi módon is elvégezhetők.

Ezen az oldalon talál egy oktatóvideót, amelyből megismerheti a Service Fabric reliable services programozási modelljét, és hogy ezzel a .NET-programozási modellel az alkalmazás hogyan integrálható szorosabban a Service Fabric-futtatókörnyezettel:

Szolgáltatás életciklusa

Függetlenül attól, hogy a szolgáltatás állapotalapú vagy állapot nélküli, a Reliable Services egyszerű életciklust biztosít, amellyel gyorsan csatlakoztathatja a kódot, és megkezdheti az első lépéseket. Az új szolgáltatás üzembe helyezéséhez két módszert kell implementálnia:

  • CreateServiceReplicaListeners/CreateServiceInstanceListeners – Ebben a metódusban határozza meg a szolgáltatás a használni kívánt kommunikációs verem(ek)et. A kommunikációs verem, például a Webes API, határozza meg a szolgáltatás figyelési végpontját vagy végpontját (az ügyfelek a szolgáltatás elérésének módját). Azt is meghatározza, hogy a megjelenő üzenetek hogyan használják a szolgáltatáskód többi részét.
  • RunAsync – Ez a módszer futtatja a szolgáltatás üzleti logikáját, és ahol elindítja a szolgáltatás teljes élettartama alatt futtatandó háttérfeladatokat. A megadott lemondási jogkivonat jelzi, hogy mikor kell leállnia a munkának. Ha például a szolgáltatásnak ki kell húznia az üzeneteket egy Reliable Queue üzenetsorból, és fel kell dolgoznia őket, ez a munka történik.

Ha első alkalommal ismerkedik meg a megbízható szolgáltatásokkal, olvasson tovább! Ha a megbízható szolgáltatások életciklusának részletes ismertetését keresi, tekintse meg a Reliable Services életciklusának áttekintését.

Példaszolgáltatások

Vizsgáljuk meg közelebbről, hogyan működik a Reliable Services modell állapot nélküli és állapotalapú szolgáltatásokkal is.

Állapot nélküli Reliable Services

Az állapot nélküli szolgáltatások olyan szolgáltatások , ahol a hívások között nincs állapot fenntartva a szolgáltatásban. A jelen lévő állapotok teljes mértékben eldobhatók, és nem igényelnek szinkronizálást, replikációt, adatmegőrzést vagy magas rendelkezésre állást.

Vegyünk például egy olyan számológépet, amely nem rendelkezik memóriával, és megkapja az egyszerre végrehajtandó összes feltételt és műveletet.

Ebben az esetben a RunAsync() szolgáltatás (C#) vagy runAsync() (Java) üres lehet, mivel nincs olyan háttérfeladat-feldolgozás, amelyet a szolgáltatásnak el kell végeznie. A számológép szolgáltatás létrehozásakor egy ICommunicationListener (C#) vagy CommunicationListener (Java) (például webes API) értéket ad vissza, amely egy figyelési végpontot nyit meg egy porton. Ez a figyelési végpont a számológép nyilvános API-ját meghatározó különböző számítási módszerekhez (például "Add(n1, n2)") csatlakozik.

Amikor hívást kezdeményez egy ügyfélről, a megfelelő metódus lesz meghívva, és a számológép szolgáltatás végrehajtja a műveleteket a megadott adatokon, és visszaadja az eredményt. Nem tárol semmilyen állapotot.

Ha nem tárol belső állapotot, ez a példakalkulátor egyszerűvé válik. De a legtöbb szolgáltatás nem igazán állapot nélküli. Ehelyett egy másik áruházba helyezik ki az állapotukat. (Például az olyan webalkalmazások, amelyek a munkamenet állapotának háttértárban vagy gyorsítótárban való tartására támaszkodnak, nem állapot nélküliek.)

Gyakori példa arra, hogyan használják az állapot nélküli szolgáltatásokat a Service Fabricben olyan előtérként, amely elérhetővé teszi egy webalkalmazás nyilvános api-ját. Az előtér-szolgáltatás ezután az állapotalapú szolgáltatásokkal beszél egy felhasználói kérés teljesítéséhez. Ebben az esetben az ügyfelek hívásai egy ismert portra, például a 80-as portra irányulnak, ahol az állapot nélküli szolgáltatás figyel. Ez az állapot nélküli szolgáltatás fogadja a hívást, és meghatározza, hogy a hívás megbízható féltől származik-e, és hogy melyik szolgáltatásra irányul. Ezután az állapot nélküli szolgáltatás továbbítja a hívást az állapotalapú szolgáltatás megfelelő partíciójára, és megvárja a választ. Amikor az állapot nélküli szolgáltatás választ kap, válaszol az eredeti ügyfélnek. Ilyen szolgáltatás például a Service Fabric Első lépések minta (C# / Java), az adattárban található egyéb Service Fabric-minták mellett.

Állapotalapú Reliable Services

Az állapotalapú szolgáltatásnak konzisztens állapotúnak és jelen lévőnek kell lennie ahhoz, hogy a szolgáltatás működjön. Vegyünk egy olyan szolgáltatást, amely folyamatosan kiszámítja bizonyos értékek gördülő átlagát a kapott frissítések alapján. Ehhez rendelkeznie kell a feldolgozandó bejövő kérések aktuális készletével és az aktuális átlagával. Minden olyan szolgáltatás, amely külső tárolóban (például azure-blobban vagy table store-ban) lévő információkat kér le, dolgoz fel és tárol, állapotalapú. Csak a külső állapottárolóban tartja az állapotát.

A legtöbb szolgáltatás jelenleg külsőleg tárolja az állapotát, mivel a külső tároló biztosítja az adott állapot megbízhatóságát, rendelkezésre állását, méretezhetőségét és konzisztenciáját. A Service Fabricben a szolgáltatásoknak nem kell külsőleg tárolniuk az állapotukat. A Service Fabric gondoskodik ezekről a követelményekről mind a szolgáltatáskód, mind a szolgáltatásállapot tekintetében.

Tegyük fel, hogy olyan szolgáltatást szeretnénk írni, amely képeket dolgoz fel. Ehhez a szolgáltatás egy rendszerképet és a képen végrehajtandó átalakítások sorozatát veszi fel. Ez a szolgáltatás egy kommunikációs figyelőt ad vissza (tegyük fel, hogy ez egy WebAPI), amely egy olyan API-t tesz elérhetővé, mint a ConvertImage(Image i, IList<Conversion> conversions). Amikor kérést kap, a szolgáltatás tárolja azt egy IReliableQueue,-ban, és visszaad egy azonosítót az ügyfélnek, hogy nyomon tudja követni a kérést.

Ebben a szolgáltatásban RunAsync() összetettebb lehet. A szolgáltatásban van egy hurok RunAsync() , amely lekéri IReliableQueue a kéréseket, és végrehajtja a kért átalakításokat. Az eredmények tárolása egy IReliableDictionary helyen történik, így amikor az ügyfél visszatér, lekérheti a konvertált rendszerképeket. Annak biztosítása érdekében, hogy még ha valami sem sikerül, a rendszerkép ne vesszenek el, ez a Reliable Service kihúzza az üzenetsort, végrehajtja a konverziókat, és egyetlen tranzakcióban tárolja az eredményt. Ebben az esetben az üzenet el lesz távolítva az üzenetsorból, és az eredmények csak akkor lesznek tárolva az eredményszótárban, ha a konvertálások befejeződnek. Másik lehetőségként a szolgáltatás kihúzhatja a rendszerképet az üzenetsorból, és azonnal tárolhatja egy távoli tárolóban. Ez csökkenti a szolgáltatás által kezelni kívánt állapot mennyiségét, de növeli az összetettség mértékét, mivel a szolgáltatásnak meg kell őriznie a távoli tároló kezeléséhez szükséges metaadatokat. Bármelyik megközelítés esetén, ha valami nem sikerült középen, a kérés a feldolgozásra váró üzenetsorban marad.

Bár ez a szolgáltatás egy tipikus .NET-szolgáltatásnak hangzik, a különbség az, hogy a használt (IReliableQueue és IReliableDictionary) adatstruktúrákat a Service Fabric biztosítja, és rendkívül megbízhatóak, elérhetők és konzisztensek.

Mikor érdemes a Reliable Services API-kat használni?

Fontolja meg a Reliable Services API-kat, ha:

  • Azt szeretné, hogy a szolgáltatás kódja (és opcionálisan állapota) magas rendelkezésre állású és megbízható legyen.
  • Tranzakciós garanciákra van szüksége több államegységre (például megrendelésekre és rendeléssorelemekre).
  • Az alkalmazás állapota természetesen megbízható szótárakként és üzenetsorokként modellezhető.
  • Az alkalmazások kódnak vagy állapotnak magas rendelkezésre állásúnak kell lenniük, alacsony késésű olvasási és írási késéssel.
  • Az alkalmazásnak szabályoznia kell a végrehajtott műveletek egyidejűségét vagy részletességét egy vagy több megbízható gyűjteményben.
  • Kezelni szeretné a kommunikációt, vagy szabályozni szeretné a szolgáltatás particionálási sémáját.
  • A kódhoz egy ingyenes szálon futó futtatókörnyezetre van szükség.
  • Az alkalmazásnak futásidőben dinamikusan létre kell hoznia vagy meg kell semmisítenie a Reliable Dictionaries vagy a Queues vagy a teljes szolgáltatásokat.
  • Programozott módon kell szabályoznia a Service Fabric által biztosított biztonsági mentési és visszaállítási funkciókat a szolgáltatás állapotához.
  • Az alkalmazásnak meg kell őriznie az állapotegységek változási előzményeit.
  • Külső gyártó által fejlesztett, egyéni állapotszolgáltatókat szeretne fejleszteni vagy használni.

Következő lépések