|
|
Zverejnené 15. 3. 2018 10:03:44
|
|
|
|
V predchádzajúcej časti sme hovorili o dvoch najnižších konceptoch Service Fabricu, jedným je typ uzla a uzol na hardvérovej úrovni. Druhým je aplikácia.
Typ uzla je kolekcia uzlov, ktoré sú konceptuálnymi abstrakciami nasadzovaných strojov. Pre Service Fabric môže byť uzol fyzický stroj, virtuálny stroj alebo dokonca najpopulárnejší kontajner v súčasnosti.
Bežiaci na type uzla je aplikácia. Je to abstraktné chápanie na úrovni systémového softvéru. V aplikácii je viacero mikroslužieb. Dokonca aj všetky základné služby Service Fabric, ako FailoverManager Service a Naming Service, sú mikro služby.
Všetky distribuované funkcie Service Fabric zodpovedajú nasadeniam mikro služieb. Môžeme dynamicky upravovať, koľko inštancií musí mikroslužba bežať na koľkých uzloch na rozloženie tlaku záťaže alebo vykonávanie záloh po havárii. Každá inštancia počúva iný port a vrstva vyvažovania záťaže rozdeľuje požiadavky na rôzne inštancie.
Skutočný scenár
Štátna služba je jednou z mikro služieb.
Skôr než začneme predstavovať štátnu službu, pozrime sa na nasledujúce bežné obchodné scenáre.
Uvažujete o implementácii funkcie nákupného košíka na vašej webovej stránke. Po prihlásení si používatelia uložia niektoré položky do svojho nákupného košíka.
Pri ďalšom prihlásení sa používateľ na recepcii zavolá službu nákupných košíkov a bude potrebné znovu prečítať uložené údaje o nákupnom košíku z tejto služby a zobraziť ich.
Ak áno, ako by ste to dosiahli?
Ak počet používateľov nie je obzvlášť veľký, pridáme do databázy tabuľku nákupných košíkov a priradíme ju k tabuľke používateľov. Tabuľka košíkov bude mať pole používateľského ID a zaznamenáva veľké množstvo údajov o vozíku.
Potom to prinesie ďalšie problémy.
Ak počet používateľov bude naďalej rásť, výkon databázových tabuliek bude naďalej klesať.
Údaje z databázových tabuliek je potrebné pravidelne zálohovať pre prípad straty údajov
Ak je problém s výkonom databázy, tabuľka musí byť vyvrátená alebo dokonca rozdelená na partie
Samotný systém nákupných košíkov musí zvládať akékoľvek úpravy databázy, a dokonca aj on môže byť potrebný vyvážiť záťaž
Koreň tohto problému spočíva v tom, že samotný systém nie je navrhnutý tak, aby bol škálovateľný. Okrem toho sú databázy potenciálnym úzkym miestom a hrozbou pre výkon.
Štátna služba
Pozrime sa na takúto úplne novú architektúru.
Od začiatku má systém nákupných košíkov 36 podslužieb, ktoré spracovávajú všetky požiadavky (36, pretože iniciály používateľského ID sú 0-9 a-z, spolu 36).
Požiadavka používateľa sa spracováva podľa počiatočného hashu používateľského ID pre konkrétnu podslužbu.
Podslužba ukladá údaje z nákupného košíka interne prostredníctvom ľahkej databázy a uchováva ich na vlastnom úložnom zariadení.
Každá podslužba má tiež 3 zálohy, ktoré neustále synchronizujú uložené dáta, a tieto zálohy bežia vždy na rôznych uzloch.
Zároveň je len jedna záloha zodpovedná za spracovanie požiadaviek ako stav aktivácie, a keď nastane problém s aktiváciou zálohy, ostatné dve zálohy aktivujú jednu podľa plánovacieho algoritmu.
Podsystém obnovy po havárii vytvára novú zálohu, aby sa zabezpečilo, že podslužba má vždy 3 zdravé zálohy.
Stavové doručenie je jedným z takýchto riešení.
Späť k vyššie uvedenému scenáru, systém nákupných košíkov je štátna služba.
36 podsystémov je 36 inštancií tejto stavovej služby, ktorú nazývame partície.
Záloha pod každým podsystémom je Replica a v partícii sú 3 repliky.
Aktuálne aktívna záloha je Active Replica a dve neaktívne záložné zálohy sú Secondary Replica.
Každá replika toho istého Partiionu musí bežať na inom uzle.
Kód stavovej služby používa <T>rozhrania ako IReliableCollection, IReliableDictionary< T1 a T2 >na ukladanie dát a internú synchronizáciu.
Okrem toho môže štátna služba implementovať nasledujúce funkcie:
Všetky vyššie uvedené čísla sa dajú resetovať a môžete mať stovky partícií v kartridžovom systéme, ktoré zaťažujú viac zaťaženia. Môžete mať dokonca 5 alebo viac replík na partíciu, aby ste zabezpečili väčšiu robustnosť.
Externé systémy neriešia, koľko partícií má Stateful Service, volajú sa podľa partíciového kľúča. Kľúč k rozdeleniu a zodpovedajúca partícia sú vyriešené základnou mikro službou Service Fabric. Napríklad vo vašom podnikaní môžete mať niekoľko miliónov používateľov, ale nastaviť len 5 partícií. Pri volaní stavovej služby nákupného košíka musí externý systém informovať len používateľské ID (partíciový kľúč) a uložené dáta. Táto požiadavka je automaticky mapovaná na jednu z piatich partícií na základe používateľského ID a hashovacieho algoritmu.
Dátové operácie v stavových službách podporujú transakcie. Aby ste mohli vrátiť späť po zlyhaní
Dúfam, že vyššie uvedený úvod vám pomôže lepšie pochopiť štátnu službu.
V nasledujúcich častiach sa budeme venovať príkladom predpisov pre štátne služby. |
Predchádzajúci:Dúfam, že sa o tom môžete medzi sebou porozprávaťBudúci:Štyridsaťsedem spôsobov, ako optimalizovať C# program
|
