Azure Service Fabric alkalmazás tervezésének legjobb gyakorlatai

  • Cikk

Ez a cikk gyakorlati tanácsokat nyújt az alkalmazások és szolgáltatások Azure Service Fabricen való létrehozásához.

Ismerkedés a Service Fabric szolgáltatással

Alkalmazástervezési útmutató

Ismerje meg a Service Fabric-alkalmazások általános architektúráját és azok tervezési szempontjait.

API-átjáró kiválasztása

Használjon olyan API-átjárószolgáltatást, amely kommunikál a háttérszolgáltatásokkal, amelyek aztán felskálázhatók. A leggyakrabban használt API-átjárószolgáltatások a következők:

Állapot nélküli szolgáltatások

Javasoljuk, hogy mindig az állapot nélküli szolgáltatások kiépítésével kezdje a Reliable Services használatával, és tárolja az állapotot egy Azure-adatbázisban, az Azure Cosmos DB-ben vagy az Azure Storage-ban. A külső állapot a legtöbb fejlesztő számára ismerősebb megközelítés. Ez a megközelítés lehetővé teszi a lekérdezési képességek kihasználását is az áruházban.

Mikor érdemes állapotalapú szolgáltatásokat használni?

Fontolja meg az állapotalapú szolgáltatásokat, ha alacsony késésű forgatókönyvvel rendelkezik, és az adatokat közel kell tartania a számításhoz. Néhány példaforgatókönyv például az IoT-digitális ikereszközök, a játék állapota, a munkamenet állapota, az adatok adatbázisból való gyorsítótárazása, valamint a más szolgáltatások felé irányuló hívások nyomon követésére szolgáló, hosszú ideig futó munkafolyamatok.

Döntse el az adatmegőrzési időkeretet:

  • Gyorsítótárazott adatok. Gyorsítótárazást akkor használjon, ha a külső tárolók késése problémát jelent. Használjon állapotalapú szolgáltatást saját adatgyorsítótárként, vagy fontolja meg a nyílt forráskódú SoCreate Service Fabric elosztott gyorsítótár használatát. Ebben a forgatókönyvben nem kell aggódnia, ha elveszíti a gyorsítótárban lévő összes adatot.
  • Időhöz kötött adatok. Ebben a forgatókönyvben az adatoknak egy ideig a számítás közelében kell maradniuk a késés érdekében, de megengedheti magának, hogy vészesen elveszítse az adatokat. Sok IoT-megoldásban például az adatoknak közel kell lenniük a számításhoz, például az elmúlt napok átlaghőmérsékletének kiszámításakor, de ha ezek az adatok elvesznek, a rögzített adatpontok nem annyira fontosak. Ebben a forgatókönyvben általában nem érdekli az egyes adatpontok biztonsági mentése. Csak a külső tárolóba rendszeresen írt számított átlagos értékekről készít biztonsági másolatot.
  • Hosszú távú adatok. A megbízható gyűjtemények véglegesen tárolhatják az adatokat. Ebben az esetben azonban fel kell készülnie a vészhelyreállításra, beleértve a fürtök rendszeres biztonsági mentési szabályzatainak konfigurálását is. Valójában konfigurálja, hogy mi történik, ha a fürt vészesen megsemmisül, ahol létre kell hoznia egy új fürtöt, és hogyan helyezhet üzembe új alkalmazáspéldányokat, és hogyan állíthatja helyre a legújabb biztonsági mentést.

Költségek megtakarítása és a rendelkezésre állás javítása:

  • Az állapotalapú szolgáltatások használatával csökkentheti a költségeket, mert nem jár adathozzáférési és tranzakciós költségekkel a távoli tárolóból, és mivel nem kell más szolgáltatást használnia, például az Azure Cache for Redist.
  • Az állapotalapú szolgáltatások használata elsősorban a tároláshoz és nem a számításhoz költséges, ezért nem javasoljuk. Az állapotalapú szolgáltatásokra úgy gondoljon, mint az olcsó helyi tárolással rendelkező számításra.
  • A más szolgáltatásoktól való függőségek eltávolításával javíthatja a szolgáltatás rendelkezésre állását. Az állapot fürtbeli HA-val való kezelése elkülöníti Önt más szolgáltatás állásidőktől vagy késési problémáktól.

A Reliable Services használata

A Service Fabric Reliable Services segítségével egyszerűen hozhat létre állapot nélküli és állapotalapú szolgáltatásokat. További információkért tekintse meg a Reliable Services bemutatása című témakört.

  • A lemondási jogkivonatot mindig tiszteletben kell tartani az RunAsync() állapot nélküli és állapotalapú szolgáltatások, valamint az ChangeRole() állapotalapú szolgáltatások metódusában. Ha nem, a Service Fabric nem tudja, hogy a szolgáltatás bezárható-e. Ha például nem tartja be a lemondási jogkivonatot, sokkal hosszabb alkalmazásfrissítési idők fordulhatnak elő.
  • A kommunikációs figyelőket időben nyithatja meg és zárhatja be, és tiszteletben tarthatja a lemondási jogkivonatokat.
  • Soha ne keverje a szinkronizálási kódot az aszinkron kóddal. Például ne használja .GetAwaiter().GetResult() az aszinkron hívásokban. Használja az aszinkront a hívásveremen keresztül.

A Reliable Actors működése

A Service Fabric Reliable Actors segítségével egyszerűen hozhat létre állapotalapú, virtuális szereplőket. További információ: A Reliable Actors bemutatása.

  • Komolyan fontolja meg a pub/sub messaging használatát a szereplők között az alkalmazás skálázására. A szolgáltatást biztosító eszközök közé tartozik a nyílt forráskódú SoCreate Service Fabric Pub/Sub és az Azure Service Bus.
  • A lehető legrészletesebbé teheti a színész állapotát.
  • A színész életciklusának kezelése. Törölje a színészeket, ha nem fogja újra használni őket. A szükségtelen szereplők törlése különösen fontos az illékony állapotszolgáltató használatakor, mivel az összes állapot a memóriában van tárolva.
  • A fordulásalapú egyidejűségük miatt a szereplőket érdemes független objektumként használni. Ne hozzon létre diagramokat több-aktoros, szinkron metódushívásokról (amelyek mindegyike valószínűleg külön hálózati hívássá válik), és ne hozzon létre körkörös aktorkéréseket. Ezek jelentősen befolyásolják a teljesítményt és a skálázást.
  • Ne keverje a szinkronizálási kódot az aszinkron kóddal. A teljesítményproblémák megelőzése érdekében használja következetesen az aszinkront.
  • Ne kezdeményezz hosszú ideig futó hívásokat a színészekben. A hosszan futó hívások a turn-alapú egyidejűség miatt blokkolják az ugyanazon szereplőhöz érkező egyéb hívásokat.
  • Ha a Service Fabric-remoting használatával kommunikál más szolgáltatásokkal, és létrehoz egy ServiceProxyFactorypéldányt, hozza létre a gyárat az aktor-szolgáltatás szintjén, nem pedig az aktor szintjén.

Alkalmazásdiagnosztika

Alaposan vegye fel az alkalmazásnaplózást a szolgáltatáshívásokban. Segít diagnosztizálni azokat a forgatókönyveket, amelyekben a szolgáltatások meghívják egymást. Ha például a B hívás C-t hív, a hívás bárhol meghiúsulhat. Ha nincs elég naplózása, a hibákat nehéz diagnosztizálni. Ha a szolgáltatások túl sokat naplóznak a híváskötetek miatt, ügyeljen arra, hogy legalább naplóhibákat és figyelmeztetéseket naplózzanak.

Tervezési útmutató az Azure-ban