|
|
Közzétéve 2018. 03. 15. 10:03:44
|
|
|
|
Az előző részben a Service Fabric két legalacsonyabb fogalmajáról beszéltünk, az egyik a Node típus és a Node hardverszinten. A másik az alkalmazás.
A Node típus egy csomópontok gyűjteménye, amelyek a betelepítő gépek fogalmi absztrakciói. A Service Fabric esetében a node lehet fizikai gép, virtuális gép vagy akár a legnépszerűbb konténer is.
A Node Type-en futni az Alkalmazás. Ez egy absztrakt megértés a rendszerszoftver szintjén. Egy alkalmazásban több mikroszolgáltatás is van. Még a Service Fabric összes alapszolgáltatása, mint például a FailoverManager Service és Naming Service, mikro szolgáltatások.
A Service Fabric összes elosztott funkciója megfelel a Micro Service telepítéseknek. Dinamikusan állíthatjuk be, hogy hány példányt kell futtatnia egy Micro Service-nek, hány csomóponton kell elosztani a terhelés nyomását vagy katasztrófa-helyreállítási mentéseket végezni. Minden példány egy másik portot hallgat, és a terheléskiegyenlő réteg különböző példányok között osztja el a kéréseket.
A tényleges forgatókönyv
Az állami szolgáltatás a mikroszolgáltatások egyike.
Mielőtt elkezdenénk bemutatni az Állapotos Szolgáltatást, vegyük figyelembe a következő gyakori üzleti forgatókönyveket.
Azon gondolkodik, hogy beépítesz egy bevásárlókosár funkciót a weboldaladra. Bejelentkezés után a felhasználók néhány terméket a bevásárlókosarukba helyeznek.
Legközelebb, amikor a felhasználó bejelentkezik, a recepciós oldal felhívja a bevásárlókosár szolgáltatást, és újra kell olvasnia a mentett bevásárlókosár adatait ebből a szolgáltatásból, valamint megjelenítenie azokat.
Ha igen, hogyan érted el?
Ha a felhasználók száma nem különösebben nagy, bedobókosar táblázatot adunk az adatbázisba, és összekapcsoljuk azt a felhasználói táblával. A kosar táblán lesz egy felhasználói azonosító mező, amely nagy mennyiségű felhasználói kosaradatot rögzít.
Ezután további problémák jelentkeznek.
Ha a felhasználók száma tovább nő, az adatbázis-táblák teljesítménye tovább romlik.
Az adatbázis tábla adatait rendszeresen le kell menteni az adatvesztés esetén
Ha probléma van az adatbázis teljesítményével, a táblát meg kell cáfolni vagy akár partosion is részt venni
A bevásárlókocsi rendszernek is kezelnie kell az adatbázis bármilyen módosítását, sőt, még azt is terheléselosztásra szoríthatja
Ennek a problémának az agya, hogy maga a rendszer eleve nem úgy lett tervezve, hogy skálázható legyen. Emellett az adatbázisok potenciális szűk keresztmetszetet és teljesítményveszélyt jelentenek.
Állami szolgálat
Vegyünk egy teljesen új architektúrát.
Kezdetektől fogva a bevásárlókocsi rendszer 36 al-szolgáltatást tartalmaz, amelyek minden kérést kezelnek (36, mert a felhasználói azonosító kezdőbetűi 0-9 a-z, összesen 36).
A felhasználó kérését a felhasználói azonosító kezdeti hash-je alapján dolgozzák fel egy adott al-szolgáltatáshoz.
Az alszolgáltatás a bevásárlókosár adatait egy könnyű adatbázison keresztül tárolja, és saját tárolóeszközén tárolja azokat.
Minden alszolgáltatásnak 3 biztonsági mentése van, amelyek folyamatosan szinkronizálják a tárolt adatokat, és ezek a mentések mindig különböző csomópontokon futnak.
Ugyanakkor csak egy biztonsági mentés felelős a kérések feldolgozásáért aktiválási állapotként, és ha probléma van a biztonsági mentés aktiválásával, a másik két biztonsági mentés aktiválja az ütemezési algoritmus szerint egyet.
A katasztrófa-helyreállítási alrendszer új biztonsági mentést hoz létre, hogy biztosítsa, hogy az alszolgáltatásnak mindig 3 egészséges biztonsági mentése legyen.
Az államszolgálat egy ilyen megoldás.
Visszatérve a fenti helyzethez: a bevásárlókocsi rendszer egy állapotos szolgáltatás.
A 36 alrendszer a Stateful Service 36 példánya, amelyet Partícióknak hívunk.
Minden alrendszer alatt a Replika található, és egy partícióban 3 replika található.
A jelenleg aktív mentés az Aktív Replika, a két inaktív készenléti biztonsági mentés pedig Másodlagos Replika.
Ugyanannak a Particiónak minden másolatának egy másik csomóponton kell futnia.
Az állapotos szolgáltatáskód <T>olyan interfészeket használ, mint az IReliableCollection, IReliableDictionary< T1 és T2 >adatmentésre és belső szinkronizálásra.
Ezen felül az állapotos szolgáltatás az alábbi funkciókat képes megvalósítani:
Az összes fenti számot vissza lehet állítani, és több száz partíciót lehet használni a kartusz rendszerében, hogy több terhelést terhelj. Akár 5 vagy több replika is lehet egy partíciónként, hogy nagyobb robusztust biztosíts.
A külső rendszereket nem érdekli, hány partíciója van a Stateful Service-nek, azokat a partíciós kulcs hívja meg. A partíciós kulcsot és a hozzá tartozó partíciót a Service Fabric mögöttes Micro Service oldja meg. Például a vállalkozásodban lehet, hogy néhány millió felhasználód van, de csak 5 partíciót hozol létre. Amikor a bevásárlókosarat Stateful Service-nek hívjuk, a külső rendszernek csak a felhasználói azonosítót (partíciós kulcsot) és a mentett adatokat kell tájékoztatnia. Ez a kérés automatikusan az öt partíció egyikéhez kerül leképezve a felhasználói azonosító és a hash algoritmus alapján.
Az adatműveletek az állapotos szolgáltatásokban támogatják a tranzakciókat. Így vissza tudsz indítani a sikertelenség esetén
Remélem, a fenti bevezetés segít jobban megérteni az állami szolgálatot.
Az alábbi szakaszokban részletesen bemutatjuk a Stateful Service kódjait. |
Előző:Remélem, meg tudtok beszélni erről egymássalKövetkező:Negyvenhét módja egy C# program optimalizálásának
|
