Szeretne többet megtudni a Service Fabricről?

Az Azure Service Fabric egy elosztott rendszerplatform, amely megkönnyíti a skálázható és megbízható mikroszolgáltatások csomagolását, üzembe helyezését és kezelését. A Service Fabric azonban nagy felülettel rendelkezik, és sokat kell tanulnia. Ez a cikk a Service Fabric összefoglalóját tartalmazza, és ismerteti az alapvető fogalmakat, a programozási modelleket, az alkalmazás életciklusát, a tesztelést, a fürtöket és az állapotfigyelést. A bevezetéshez olvassa el az Áttekintés és Mik azok a mikroszolgáltatások? című cikket, és megtudhatja, hogyan használható a Service Fabric a mikroszolgáltatások létrehozásához. Ez a cikk nem tartalmaz átfogó tartalomlistát, de hivatkozik a Service Fabric minden területére vonatkozó áttekintő és első lépéseket ismertető cikkekre.

Alapfogalmak

A Service Fabric terminológiája, az alkalmazásmodell és a támogatott programozási modellek további fogalmakat és leírásokat nyújtanak, de íme az alapok.

• Service Fabric-fürt:Ebben a hivatkozásban oktatóvideóhoz juthat, amely bemutatja a Service Fabric architektúráját és alapvető fogalmait, és megismerkedhet a Service Fabric számos funkciójával.
• Futásidejű fogalmak:Tekintse meg ezt a hivatkozást, amely betanítási videót keres a Service Fabric futásidejű fogalmainak és ajánlott eljárásainak megismeréséhez.
• Tervezési típussal kapcsolatos fogalmak:Ezen a hivatkozáson talál egy oktatóvideót az alkalmazások, a csomagolás és az üzembe helyezés megismeréséhez; a Service Fabric legfontosabb terminológiájának, absztrakcióinak és fogalmainak megismeréséhez.

Tervezési idő: szolgáltatástípus, szolgáltatáscsomag és jegyzékfájl, alkalmazástípus, alkalmazáscsomag és jegyzékfájl

A szolgáltatástípus a szolgáltatás kódcsomagjaihoz, adatcsomagjaihoz és konfigurációs csomagjaihoz rendelt név/verzió. Ez egy ServiceManifest.xml fájlban van definiálva. A szolgáltatás típusa végrehajtható kódból és szolgáltatáskonfigurációs beállításokból áll, amelyek futásidőben töltődnek be, valamint a szolgáltatás által felhasznált statikus adatokból.

A szolgáltatáscsomagok a szolgáltatástípus ServiceManifest.xml fájlját tartalmazó lemezkönyvtárak, amelyek a szolgáltatástípus kódjára, statikus adataira és konfigurációs csomagjaira hivatkoznak. Egy szolgáltatáscsomag például hivatkozhat az adatbázis-szolgáltatást alkotó kódra, statikus adatokra és konfigurációs csomagokra.

Az alkalmazástípus a szolgáltatástípusok gyűjteményéhez rendelt név/verzió. Ez egy ApplicationManifest.xml fájlban van definiálva.

Az alkalmazáscsomag egy lemezkönyvtár, amely tartalmazza az alkalmazástípus ApplicationManifest.xml fájlját, amely az alkalmazástípust alkotó egyes szolgáltatástípusok szolgáltatáscsomagjaira hivatkozik. Egy e-mail-alkalmazástípus alkalmazáscsomagja például tartalmazhat egy üzenetsor-szolgáltatási csomagra, egy előtérbeli szolgáltatáscsomagra és egy adatbázis-szolgáltatási csomagra mutató hivatkozásokat.

Az alkalmazáscsomag könyvtárában lévő fájlokat a rendszer a Service Fabric-fürt lemezképtárolójába másolja. Ezután létrehozhat egy nevesített alkalmazást ebből az alkalmazástípusból, amely ezután a fürtön belül fut. Nevesített alkalmazás létrehozása után létrehozhat egy nevesített szolgáltatást az alkalmazástípus egyik szolgáltatástípusából.

Futtatási idő: fürtök és csomópontok, nevesített alkalmazások, nevesített szolgáltatások, partíciók és replikák

A Service Fabric-fürtök virtuális vagy fizikai gépek hálózattal csatlakoztatott készletei, amelyekbe a mikroszolgáltatások üzembe helyezése és kezelése történik. A fürtök több ezer gépre skálázhatók.

A fürtök részét képező gépeket vagy virtuális gépeket csomópontoknak nevezzük. Minden csomóponthoz hozzá van rendelve egy csomópontnév (egy sztring). A csomópontok jellemzőkkel, például elhelyezési tulajdonságokkal rendelkeznek. Minden gép vagy virtuális gép rendelkezik egy automatikus indítású Windows-szolgáltatással, amely indításkor elindul, FabricHost.exemajd elindít két végrehajtható fájlt: Fabric.exe és FabricGateway.exe. Ez a két végrehajtható fájl alkotja a csomópontot. Fejlesztési vagy tesztelési forgatókönyvek esetén több csomópontot is üzemeltethet egyetlen gépen vagy virtuális gépen a és FabricGateway.exetöbb példányának Fabric.exe futtatásával.

A nevesített alkalmazások nevesített szolgáltatások gyűjteményei, amelyek egy bizonyos függvényt vagy függvényt hajtanak végre. A szolgáltatások teljes és önálló függvényt hajtanak végre (más szolgáltatásoktól függetlenül indíthatók és futtathatók), és kódból, konfigurációból és adatokból állnak. Miután az alkalmazáscsomagot a rendszerképtárba másolta, az alkalmazás egy példányát a fürtben hozza létre az alkalmazáscsomag alkalmazástípusának megadásával (a nevével/verziójával). Minden alkalmazástípus-példányhoz hozzá van rendelve egy URI-név, amely a következőhöz hasonló: fabric:/MyNamedApp. Egy fürtön belül több elnevezett alkalmazást is létrehozhat egyetlen alkalmazástípusból. A nevesített alkalmazásokat különböző alkalmazástípusokból is létrehozhatja. Az egyes nevesített alkalmazások egymástól függetlenül kezelhetők és verziószámozottak.

A nevesített alkalmazás létrehozása után létrehozhat egy példányt az egyik szolgáltatástípusából (egy nevesített szolgáltatásból) a fürtben a szolgáltatástípus megadásával (a nevével/verziójával). Minden szolgáltatástípus-példányhoz hozzá van rendelve egy URI-név, amely a nevesített alkalmazás URI-ja alatt található. Ha például létrehoz egy "MyDatabase" nevű szolgáltatást egy "MyNamedApp" nevű alkalmazásban, az URI a következőképpen néz ki: fabric:/MyNamedApp/MyDatabase. Egy nevesített alkalmazásban létrehozhat egy vagy több nevesített szolgáltatást. Minden megnevezett szolgáltatás saját partíciósémával és példány/replikaszámokkal rendelkezhet.

Kétféle szolgáltatás létezik: állapot nélküli és állapotalapú. Az állapot nélküli szolgáltatások nem tárolják az állapotot a szolgáltatáson belül. Az állapot nélküli szolgáltatások egyáltalán nem rendelkeznek állandó tárhellyel, vagy állandó állapotot tárolnak egy külső tárolószolgáltatásban, például az Azure Storage-ban, a Azure SQL Database-ben vagy az Azure Cosmos DB-ben. Az állapotalapú szolgáltatás tárolja az állapotot a szolgáltatáson belül, és Reliable Collections vagy Reliable Actors programozási modellek használatával kezeli az állapotot.

Névvel ellátott szolgáltatás létrehozásakor meg kell adnia egy partíciósémát. A nagy mennyiségű állapotú szolgáltatások felosztják az adatokat a partíciók között. Minden partíció felelős a szolgáltatás teljes állapotának egy részéért, amely a fürt csomópontjai között oszlik el.

Az alábbi ábrán az alkalmazások és szolgáltatáspéldányok, partíciók és replikák közötti kapcsolat látható.

Particionálás, skálázás és rendelkezésre állás

A particionálás nem egyedi a Service Fabricben. A particionálás egy jól ismert formája az adatparticionálás vagy a horizontális skálázás. A nagy mennyiségű állapottal rendelkező állapotalapú szolgáltatások felosztják az adatokat a partíciók között. Minden partíció felelős a szolgáltatás teljes állapotának egy részéért.

Az egyes partíciók replikái el vannak osztva a fürt csomópontjai között, ami lehetővé teszi a megnevezett szolgáltatás állapotának skálázását. Az adatok növekedésével a partíciók növekednek, és a Service Fabric újra kiegyensúlyoz egy partíciót a csomópontok között a hardvererőforrások hatékony kihasználása érdekében. Ha új csomópontokat ad hozzá a fürthöz, a Service Fabric újra kiegyensúlyozhatja a partícióreplikákat a csomópontok megnövekedett száma között. Az alkalmazás általános teljesítménye javul, és csökken a memória-hozzáférésért való versengés. Ha a fürt csomópontjai nincsenek hatékonyan használatban, csökkentheti a fürtben lévő csomópontok számát. A Service Fabric újra kiegyensúlyozhatja a partícióreplikákat a csökkentett számú csomópont között, hogy jobban kihasználhassa az egyes csomópontokon található hardvereket.

Egy partíción belül az állapot nélküli nevesített szolgáltatások példányokkal rendelkeznek, míg az állapotalapú nevesített szolgáltatások replikákkal rendelkeznek. Az állapot nélküli nevesített szolgáltatások általában csak egy partícióval rendelkeznek, mivel nincsenek belső állapotuk, bár vannak kivételek. A partíciópéldányok biztosítják a rendelkezésre állást. Ha egy példány meghibásodik, a többi példány továbbra is a megszokott módon működik, majd a Service Fabric létrehoz egy új példányt. Az állapotalapú nevesített szolgáltatások fenntartják az állapotukat a replikákon belül, és minden partíció saját replikakészlettel rendelkezik. Az olvasási és írási műveletek egyetlen replikán (az úgynevezett Elsődlegesen) hajthatók végre. Az írási műveletek állapotváltozásait a rendszer több más replikára (active secondaries) replikálja. Ha egy replika meghibásodik, a Service Fabric létrehoz egy új replikát a meglévő replikákból.

Állapot nélküli és állapotalapú mikroszolgáltatások a Service Fabrichez

A Service Fabric segítségével mikroszolgáltatásokból vagy tárolókból álló alkalmazásokat építhet. Az állapot nélküli mikroszolgáltatások (például a protokollátjárók és webproxyk) nem tartanak fenn változtatható állapotot a kéréseken és a szolgáltatástól ezekre kapott válaszokon kívül. Az Azure Cloud Services feldolgozói szerepkörei például állapotmentes szolgáltatások. Az állapotalapú mikroszolgáltatások (például felhasználói fiókok, adatbázisok, eszközök, kosarak és üzenetsorok) változtatható, mérvadó állapotot tartanak fenn a kéréseken és a válaszokon kívül is. A modern webes alkalmazások állapot nélküli és állapotalapú mikroszolgáltatások kombinációjából állnak.

A Service Fabric fő különbsége az állapotalapú szolgáltatások létrehozására összpontosít, akár a beépített programozási modellekkel , akár tárolóalapú állapotalapú szolgáltatásokkal. Az alkalmazás-forgatókönyvek az állapotalapú szolgáltatások használatát mutatják be.

Miért vannak állapotalapú mikroszolgáltatások az állapot nélküli szolgáltatásokkal együtt? A két fő ok a következő:

• A kódot és az adatokat ugyanazon a gépen tárolva nagy átviteli sebességű, kis késésű, hibatűrő online tranzakciófeldolgozási (OLTP) szolgáltatásokat hozhat létre. Ilyenek például az interaktív áruházak, a keresés, az eszközök internetes hálózata (IoT), a kereskedési rendszerek, a hitelkártya-feldolgozási és csalásészlelési rendszerek, valamint a személyes rekordkezelés.
• Egyszerűbbé teheti az alkalmazástervezést. Az állapotalapú mikroszolgáltatások nem igényelnek további üzenetsorokat és gyorsítótárakat, amelyek hagyományosan szükségesek a tisztán állapot nélküli alkalmazások rendelkezésre állási és késési követelményeinek teljesítéséhez. Az állapotalapú szolgáltatások természetesen magas rendelkezésre állással és alacsony késéssel érhetők el, ami csökkenti az alkalmazás egészében kezelendő mozgó alkatrészek számát.

Támogatott programozási modellek

A Service Fabric többféle módot kínál a szolgáltatások írására és kezelésére. A szolgáltatások a Service Fabric API-kkal teljes mértékben kihasználhatják a platform funkcióit és alkalmazás-keretrendszereit. A szolgáltatások bármilyen nyelven írt és Service Fabric-fürtön üzemeltetett lefordított végrehajtható program lehetnek. További információ: Támogatott programozási modellek.

Tárolók

A Service Fabric alapértelmezés szerint folyamatként telepíti és aktiválja a szolgáltatásokat. A Service Fabric a szolgáltatásokat tárolókban is üzembe helyezheti. Fontos, hogy az ugyanabban az alkalmazásban lévő tárolókban lévő folyamatokban és szolgáltatásokban lévő szolgáltatásokat kombinálhatja. A Service Fabric támogatja a Linux-tárolók és a Windows-tárolók üzembe helyezését Windows Server 2016. Meglévő alkalmazásokat, állapot nélküli szolgáltatásokat vagy állapotalapú szolgáltatásokat helyezhet üzembe tárolókban.

Reliable Services

A Reliable Services egy egyszerű keretrendszer olyan szolgáltatások írásához, amelyek integrálhatók a Service Fabric platformmal, és kihasználják a platformfunkciók teljes készletét. A Reliable Services állapot nélküli lehet (hasonlóan a legtöbb szolgáltatásplatformhoz, például a webkiszolgálókhoz vagy az Azure Cloud Services feldolgozói szerepköreihez), ahol az állapot megmarad egy külső megoldásban, például az Azure DB-ben vagy az Azure Table Storage-ban. A Reliable Services állapotalapú is lehet, ahol az állapot közvetlenül a szolgáltatásban marad meg a Reliable Collections használatával. Az állapot magas rendelkezésre állásúvá válik a replikáción keresztül, és particionáláson keresztül osztja el, mindezt automatikusan a Service Fabric felügyeli.

Reliable Actors

A Reliable Servicesre épülő Reliable Aktor keretrendszer egy olyan alkalmazás-keretrendszer, amely az aktor tervezési mintája alapján implementálja a virtuális aktor mintát. A Reliable Aktor keretrendszer független számítási és állapotegységeket használ egyszálú végrehajtással, úgynevezett aktorokkal. A Reliable Aktor keretrendszer beépített kommunikációt biztosít az aktorokhoz, valamint az előre beállított állapotmegőrzési és vertikális felskálázási konfigurációkhoz.

ASP.NET Core

A Service Fabric első osztályú programozási modellként integrálható a ASP.NET Core webes és API-alkalmazások létrehozásához. ASP.NET Core kétféleképpen használható a Service Fabricben:

• Vendég végrehajtható fájlként üzemeltetve. Ez elsősorban meglévő ASP.NET Core-alkalmazások futtatására szolgál a Service Fabricen kódmódosítások nélkül.
• Futtassa a parancsot egy Reliable Service-ben. Ez jobb integrációt tesz lehetővé a Service Fabric-futtatókörnyezettel, és lehetővé teszi az állapotalapú ASP.NET Core szolgáltatásokat.

Vendég végrehajtható fájlok

A vendég végrehajtható fájl egy meglévő, tetszőleges végrehajtható fájl (bármilyen nyelven megírva) más szolgáltatások mellett egy Service Fabric-fürtön üzemeltetve. A vendég végrehajtható fájlok nem integrálhatók közvetlenül a Service Fabric API-kkal. A platform által kínált funkciók azonban továbbra is hasznosak, például az egyéni állapot- és terhelésjelentések, valamint a szolgáltatások felderíthetősége REST API-k meghívásával. Emellett teljes körű alkalmazás-életciklus-támogatással is rendelkeznek.

Alkalmazás-életciklus

Más platformokhoz hasonlóan a Service Fabricen futó alkalmazások általában a következő fázisokon mennek keresztül: tervezés, fejlesztés, tesztelés, üzembe helyezés, frissítés, karbantartás és eltávolítás. A Service Fabric első osztályú támogatást nyújt a felhőalkalmazások teljes alkalmazás-életciklusához, a fejlesztéstől kezdve az üzembe helyezésen, a napi felügyeleten és a karbantartáson át a végleges leszerelésig. A szolgáltatásmodell lehetővé teszi, hogy több különböző szerepkör egymástól függetlenül részt vegyen az alkalmazás életciklusában. A Service Fabric-alkalmazások életciklusa áttekintést nyújt az API-król, valamint arról, hogy a különböző szerepkörök hogyan használják őket a Service Fabric-alkalmazás életciklusának fázisai során.

Az alkalmazás teljes életciklusa kezelhető PowerShell-parancsmagokkal, CLI-parancsokkal, C# API-kkal, Java API-kkal és REST API-kkal. Folyamatos integrációs/folyamatos üzembehelyezési folyamatokat is beállíthat olyan eszközökkel, mint az Azure Pipelines vagy a Jenkins.

Az alkalmazás életciklusának kezelését ismertető oktatóvideóért tekintse meg ezt a hivatkozást:

Alkalmazások és szolgáltatások tesztelése

Ahhoz, hogy valóban felhőméretű szolgáltatásokat hozhasson létre, fontos ellenőrizni, hogy alkalmazásai és szolgáltatásai képesek-e ellenállni a valós hibáknak. A Hibaelemzési szolgáltatás a Service Fabricre épülő szolgáltatások tesztelésére lett kialakítva. A Hibaelemzési szolgáltatással jelentős hibákat idézhet elő, és teljes tesztelési forgatókönyveket futtathat az alkalmazásokon. Ezek a hibák és forgatókönyvek a szolgáltatás teljes élettartama során tapasztalt számos állapotot és átmenetet gyakorolnak és ellenőriznek, mindezt ellenőrzött, biztonságos és konzisztens módon.

A műveletek egy szolgáltatást céloznak meg az egyéni hibák használatával történő teszteléshez. A szolgáltatásfejlesztők ezeket építőelemként használhatják bonyolult forgatókönyvek írásához. Példák szimulált hibákra:

• Indítsa újra a csomópontot tetszőleges számú olyan helyzet szimulálásához, amikor egy gép vagy virtuális gép újraindul.
• Helyezze át az állapotalapú szolgáltatás replikáját a terheléselosztás, feladatátvétel vagy alkalmazásfrissítés szimulálásához.
• Az állapotalapú szolgáltatás kvórumvesztésének meghívásával olyan helyzetet teremthet, amikor az írási műveletek nem folytathatók, mert nincs elég "biztonsági mentési" vagy "másodlagos" replika az új adatok elfogadásához.
• Adatvesztést hívhat meg egy állapotalapú szolgáltatáson, hogy olyan helyzetet hozzon létre, amelyben az összes memóriabeli állapot teljesen törlődik.

A forgatókönyvek egy vagy több műveletből álló összetett műveletek. A Hibaelemzési szolgáltatás két beépített teljes forgatókönyvet kínál:

• Káoszforgatókönyv – folyamatos, egymást átjárt hibákat szimulál (mind kecses, mind nem biztonságos) a fürtben hosszabb időn keresztül.
• Feladatátvételi forgatókönyv – a káosztesztelési forgatókönyv egy verziója, amely egy adott szolgáltatáspartíciót céloz meg, miközben más szolgáltatásokat nem érint.

Fürtök

A Service Fabric-fürtök virtuális vagy fizikai gépek hálózattal csatlakoztatott készletei, amelyekbe a mikroszolgáltatások üzembe helyezése és kezelése történik. A fürtök több ezer gépre skálázhatók. A fürt részét képező gépet vagy virtuális gépet fürtcsomópontnak nevezzük. Minden csomóponthoz hozzá van rendelve egy csomópontnév (egy sztring). A csomópontok jellemzőkkel, például elhelyezési tulajdonságokkal rendelkeznek. Minden gép vagy virtuális gép rendelkezik egy automatikus indítási szolgáltatással, amely indításkor elindul, FabricHost.exemajd elindít két végrehajtható fájlt: Fabric.exe és FabricGateway.exe. Ez a két végrehajtható fájl alkotja a csomópontot. Tesztelési forgatókönyvek esetén több csomópontot is üzemeltethet egyetlen gépen vagy virtuális gépen a és FabricGateway.exetöbb példányának Fabric.exe futtatásával.

Service Fabric-fürtök Windows Servert vagy Linuxot futtató virtuális vagy fizikai gépeken hozhatók létre. Service Fabric-alkalmazásokat bármilyen olyan környezetben üzembe helyezhet és futtathat, ahol olyan Windows Server- vagy Linux-számítógépkészlettel rendelkezik, amelyek összekapcsolva vannak: a helyszínen, a Microsoft Azure-on vagy bármely felhőszolgáltatón.

Ezen a hivatkozáson talál egy oktatóvideót, amely ismerteti a Service Fabric architektúráját, alapvető fogalmait és sok más Service Fabric-funkciót

Fürtök az Azure-on

A Service Fabric-fürtök Azure-ban való futtatása integrációt biztosít más Azure-funkciókkal és szolgáltatásokkal, ami megkönnyíti és megbízhatóbbá teszi a fürt működését és felügyeletét. A fürt egy Azure-Resource Manager erőforrás, így a fürtöket az Azure többi erőforrásához hasonlóan modellezheti. Resource Manager a fürt által egyetlen egységként használt összes erőforrás egyszerű kezelését is biztosítja. Az Azure-beli fürtök integrálva vannak az Azure Diagnosztikai szolgáltatással és az Azure Monitor-naplókkal. A fürtcsomópont-típusok virtuálisgép-méretezési csoportok, így az automatikus skálázási funkciók be vannak építve.

Az Azure-ban a Azure Portal, sablonból vagy a Visual Studióból hozhat létre fürtöt.

A Linuxon futó Service Fabric lehetővé teszi magas rendelkezésre állású, nagy mértékben skálázható alkalmazások létrehozását, üzembe helyezését és kezelését Linux rendszeren, ugyanúgy, mint a Windows esetében. A Service Fabric-keretrendszerek (Reliable Services és Reliable Actors) a C# (.NET Core) mellett linuxos Javában is elérhetők. Bármilyen nyelven vagy keretrendszerrel létrehozhat vendég végrehajtható szolgáltatásokat is. A Docker-tárolók vezénylése is támogatott. A Docker-tárolók futtathatnak vendég végrehajtható fájlokat vagy natív Service Fabric-szolgáltatásokat, amelyek a Service Fabric-keretrendszereket használják. További információkért olvassa el a Linuxon futó Service Fabricről szóló cikket.

Vannak olyan funkciók, amelyek támogatottak a Windows rendszeren, Linuxon azonban nem. További információ: Különbségek a Service Fabric között Linux és Windows rendszeren.

Önálló fürtök

A Service Fabric egy telepítési csomagot biztosít, amellyel önálló Service Fabric-fürtöket hozhat létre a helyszínen vagy bármely felhőszolgáltatón. Az önálló fürtök lehetővé teszik, hogy bárhol üzemeltethesse a fürtöt. Ha az adatokra megfelelőségi vagy jogszabályi korlátozások vonatkoznak, vagy ha az adatokat helyi állapotban szeretné tartani, saját fürtöt és alkalmazásokat üzemeltethet. A Service Fabric-alkalmazások módosítás nélkül több üzemeltetési környezetben is futtathatók, így az alkalmazások készítésével kapcsolatos tudása átviszi az egyik üzemeltetési környezetből a másikba.

Az első önálló Service Fabric-fürt létrehozása

A linuxos önálló fürtök még nem támogatottak.

Fürtbiztonság

A fürtöket védeni kell, hogy megakadályozzák a jogosulatlan felhasználók csatlakozását a fürthöz, különösen akkor, ha éles számítási feladatok futnak rajta. Bár létrehozhat nem biztonságos fürtöt, ez lehetővé teszi a névtelen felhasználók számára, hogy csatlakozzanak hozzá, ha a felügyeleti végpontok elérhetővé válnak a nyilvános interneten. Később nem lehet engedélyezni a biztonságot egy nem biztonságos fürtön: a fürtbiztonság engedélyezve van a fürtlétrehozáskor.

A fürtbiztonsági forgatókönyvek a következők:

• Csomópontok között történő biztonság
• Ügyfél–csomópont biztonság
• Service Fabric szerepköralapú hozzáférés-vezérlés

További információkért olvassa el a Fürt biztonságossá tételét ismertető cikket.

Méretezés

Ha új csomópontokat ad hozzá a fürthöz, a Service Fabric újra kiegyensúlyozhatja a partícióreplikákat és -példányokat a megnövekedett számú csomópont között. Az alkalmazás általános teljesítménye javul, és csökken a memória-hozzáférésért való versengés. Ha a fürt csomópontjai nincsenek hatékonyan használatban, csökkentheti a fürtben lévő csomópontok számát. A Service Fabric ismét kiegyensúlyozhatja a partícióreplikákat és -példányokat a csökkentett számú csomóponton, hogy jobban kihasználhassa az egyes csomópontokon található hardvereket. A fürtöket manuálisan vagy programozott módon is skálázhatja az Azure-ban. Az önálló fürtök manuálisan méretezhetők.

Fürtfrissítések

A Service Fabric-futtatókörnyezet rendszeres időközönként új verziói jelennek meg. Futtasson futtatókörnyezeti vagy hálófrissítéseket a fürtön, hogy mindig támogatott verziót futtasson. A hálófrissítések mellett a fürtkonfigurációt is frissítheti, például tanúsítványokat vagy alkalmazásportokat.

A Service Fabric-fürtök olyan erőforrások, amelyeknek Ön a tulajdonosa, de részben a Microsoft kezeli. A Microsoft feladata a mögöttes operációs rendszer javítása és a hálófrissítések végrehajtása a fürtön. Beállíthatja, hogy a fürt automatikus hálófrissítéseket kapjon, amikor a Microsoft új verziót ad ki, vagy kiválaszthatja a kívánt támogatott hálóverziót. A háló- és konfigurációfrissítések a Azure Portal vagy Resource Manager keresztül állíthatók be. További információ: Service Fabric-fürt frissítése.

Az önálló fürtök olyan erőforrások, amelyek teljes egészében Öné. Ön felelős a mögöttes operációs rendszer javításáért és a hálófrissítések kezdeményezéséért. Ha a fürt csatlakozni tud a-hoz https://www.microsoft.com/download, beállíthatja, hogy a fürt automatikusan töltse le és építse ki az új Service Fabric-futtatókörnyezeti csomagot. Ezután kezdeményezheti a frissítést. Ha a fürt nem fér hozzá https://www.microsoft.com/download, manuálisan letöltheti az új futtatókörnyezeti csomagot egy internetkapcsolattal rendelkező gépről, majd kezdeményezheti a frissítést. További információ: Önálló Service Fabric-fürt frissítése.

Állapotfigyelés

A Service Fabric egy olyan állapotmodellt vezet be, amely meghatározott entitásokon (például fürtcsomópontokon és szolgáltatásreplikákon) megjelöli a nem kifogástalan állapotú fürtöket és alkalmazásfeltételeket. Az állapotmodell állapotjelentéseket (rendszerösszetevőket és figyelőket) használ. A cél egyszerű és gyors diagnosztika és javítás. A szolgáltatásíróknak előre kell gondolniuk az állapottal és az állapotjelentések tervezésének módjával kapcsolatban. Minden olyan állapotot, amely hatással lehet az állapotra, jelenteni kell, különösen akkor, ha segíthet megjelölni a gyökérhöz közeli problémákat. Az állapotinformációk időt és energiát takaríthatnak meg a hibakereséssel és a vizsgálattal, ha a szolgáltatás éles környezetben működik és működik.

A Service Fabric-riporterek figyelik az azonosított érdeklődési feltételeket. Ezekről a feltételekről a helyi nézetük alapján számolnak be. Az állapottároló az összes riporter által küldött állapotadatokat összesíti annak megállapításához, hogy az entitások globálisan kifogástalan állapotban vannak-e. A modell gazdag, rugalmas és könnyen használható. Az állapotjelentések minősége határozza meg a fürt állapotnézetének pontosságát. A tévesen kifogástalan állapotú problémákat mutató téves pozitív értékek negatív hatással lehetnek a frissítésekre vagy az állapotadatokat használó egyéb szolgáltatásokra. Ilyen szolgáltatások például a javítási szolgáltatások és a riasztási mechanizmusok. Ezért némi gondolkodásra van szükség ahhoz, hogy olyan jelentéseket nyújtsunk, amelyek a lehető legjobb módon rögzítik az érdeklődési feltételeket.

A jelentéskészítés a következő forrásból végezhető el:

• A figyelt Service Fabric-szolgáltatásreplika vagy -példány.
• Service Fabric-szolgáltatásként üzembe helyezett belső figyelők (például állapot nélküli Service Fabric-szolgáltatás, amely feltételeket figyel és jelentéseket ad ki). A figyelők az összes csomóponton üzembe helyezhetők, vagy a figyelt szolgáltatáshoz affinithatók.
• Belső figyelők, amelyek a Service Fabric-csomópontokon futnak, de nem Service Fabric-szolgáltatásként vannak implementálva.
• Külső figyelők, amelyek a Service Fabric-fürtön kívülről (például a Gomezhez hasonló monitorozási szolgáltatásból) ellenőrzik az erőforrást.

A Service Fabric-összetevők kívülről jelentik a fürt összes entitásának állapotát. A rendszerállapot-jelentések betekintést nyújtanak a fürt és az alkalmazás funkcióiba, és állapoton keresztül jelölik meg a problémákat. Alkalmazások és szolgáltatások esetében a rendszerállapot-jelentések ellenőrzik, hogy az entitások implementálva vannak-e, és megfelelően működnek-e a Service Fabric-futtatókörnyezet szempontjából. A jelentések nem biztosítják a szolgáltatás üzleti logikájának állapotmonitorozását, és nem észlelik a nem válaszoló folyamatokat. A szolgáltatás logikájára jellemző állapotinformációk hozzáadásához implementáljon egyéni állapotjelentéseket a szolgáltatásokban.

A Service Fabric több módot is kínál az állapottárolóban összesített állapotjelentések megtekintésére :

• Service Fabric Explorer vagy más vizualizációs eszközök.
• Állapot lekérdezések ( a PowerShell, a parancssori felület, a C# FabricClient API-k és a Java FabricClient API-k vagy REST API-k használatával).
• Általános lekérdezések, amelyek a tulajdonságok egyikeként állapotú entitások listáját adják vissza (a PowerShell, a parancssori felület, az API-k vagy a REST használatával).

Ezen az oldalon talál egy oktatóvideót, amely leírja a Service Fabric-állapotmodellt és annak használatát:

Monitorozás és diagnosztika

A monitorozás és a diagnosztika kritikus fontosságú az alkalmazások és szolgáltatások bármilyen környezetben történő fejlesztéséhez, teszteléséhez és üzembe helyezéséhez. A Service Fabric-megoldások akkor működnek a legjobban, ha monitorozást és diagnosztikát tervez és implementál, amelyek segítenek biztosítani, hogy az alkalmazások és szolgáltatások a várt módon működjenek egy helyi fejlesztési környezetben vagy éles környezetben.

A monitorozás és a diagnosztika fő célja:

• Hardver- és infrastruktúraproblémák észlelése és diagnosztizálása
• Szoftver- és alkalmazásproblémák észlelése, a szolgáltatás állásideje csökkentése
• Az erőforrás-használat ismertetése és a műveleti döntések elősegítése
• Az alkalmazások, a szolgáltatások és az infrastruktúra teljesítményének optimalizálása
• Üzleti megállapítások létrehozása és a fejlesztés területeinek azonosítása

A monitorozás és diagnosztika átfogó munkafolyamata három lépésből áll:

1. Eseménygenerálás: ide tartoznak az infrastruktúra (fürt), a platform és az alkalmazás/szolgáltatás szintjén található események (naplók, nyomkövetések, egyéni események)
2. Eseményösszesítés: a létrehozott eseményeket össze kell gyűjteni és összesíteni kell, mielőtt megjeleníthetők lennének
3. Elemzés: az eseményeket valamilyen formátumban kell megjeleníteni és elérni, hogy szükség szerint elemezhető és megjeleníthető legyen

Több termék áll rendelkezésre, amelyek lefedik ezt a három területet, és szabadon választhat különböző technológiákat mindegyikhez. További információ: Monitorozás és diagnosztika az Azure Service Fabrichez.

Következő lépések

• Megismerkedhet egy azure-beli fürt vagy egy önálló windowsbeli fürt létrehozásával.
• Próbáljon szolgáltatást létrehozni a Reliable Services vagy a Reliable Actors programozási modellek használatával.
• Megtudhatja, hogyan migrálhat Cloud Services.
• Megtudhatja, hogyan figyelheti és diagnosztizálhatja a szolgáltatásokat.
• Megtudhatja, hogyan tesztelheti alkalmazásait és szolgáltatásait.
• Megtudhatja, hogyan kezelheti és vezényelheti a fürterőforrásokat.
• Tekintse át a Service Fabric-mintákat.
• Tudnivalók a Service Fabric támogatási lehetőségeiről.
• Cikkekért és közleményekért olvassa el a csapat blogját .