|
|
Zveřejněno 15.03.2018 10:03:44
|
|
|
|
V předchozí části jsme mluvili o dvou nejnižších konceptech Service Fabric, jedním je typ uzlu a uzel na hardwarové úrovni. Druhým je aplikace.
Typ uzlu je soubor uzlů, což jsou konceptuální abstrakce nasazovaných strojů. Pro Service Fabric může být uzelem fyzický stroj, virtuální stroj nebo dokonce nejoblíbenější kontejner v současnosti.
Na typu uzlu běží aplikace. Jedná se o abstraktní chápání na úrovni systémového softwaru. V aplikaci je více mikro služeb. Dokonce i všechny základní služby Service Fabric, jako jsou FailoverManager Service a Naming Service, jsou mikro služby.
Všechny distribuované funkce Service Fabric odpovídají nasazením mikro služeb. Můžeme dynamicky upravovat, kolik instancí mikro služba potřebuje spustit na kolik uzlech pro rozložení tlaku zátěže nebo provádění záloh po havárii. Každá instance poslouchá jiný port a vrstva vyvažování zátěže distribuuje požadavky na různé instance.
Skutečný scénář
Státní služba je jednou z mikro služeb.
Než začneme představovat státní službu, podívejme se na následující běžné obchodní scénáře.
Přemýšlíte o zavedení funkce nákupního košíku na svém webu. Po přihlášení uživatelé vloží některé položky do svého nákupního košíku.
Při dalším přihlášení uživatel zavolá na recepci službu nákupních košíků a bude potřeba znovu přečíst uložená data nákupního košíku z této služby a zobrazit je.
Pokud ano, jak byste toho dosáhli?
Pokud počet uživatelů není příliš velký, přidáme do databáze tabulku nákupního košíku a přiřadíme ji k uživatelské tabulce. Tabulka cart bude mít pole User ID a zaznamenává velké množství dat z cart.
To pak přinese další problémy.
Pokud počet uživatelů bude nadále růst, výkon databázových tabulek bude nadále klesat.
Data z databázových tabulek je třeba pravidelně zálohovat pro případ ztráty dat
Pokud je problém s výkonem databáze, je třeba tabulku vyvrátit nebo dokonce rozdělit na partition
Samotný systém nákupních košíků musí zvládat jakékoli úpravy databáze, a i ten může být potřeba být vyvážený
Kořenem tohoto problému je, že samotný systém není navržen tak, aby byl škálovatelný. Kromě toho jsou databáze potenciální úzkým hrdlem a hrozbou pro výkon.
Státní služba
Pojďme si představit zcela novou architekturu.
Od začátku má systém nákupních košíků 36 podslužeb, které zpracovávají všechny požadavky (36, protože iniciály uživatelského ID jsou 0-9 a-z, celkem 36).
Uživatelův požadavek je zpracováván podle počátečního hashe uživatelského ID ke konkrétní podslužbě.
Podslužba ukládá data z nákupního košíku interně prostřednictvím lehké databáze a uchovává je na svém vlastním úložném zařízení.
Každá podslužba má také 3 zálohy, které neustále synchronizují uložená data, a tyto zálohy běží vždy na různých uzlech.
Současně je pouze jedna záloha odpovědná za zpracování požadavků jako aktivačního stavu, a když nastane problém s aktivací zálohy, další dvě zálohy aktivují jednu podle plánovacího algoritmu.
Subsystém obnovy po havárii vytváří novou zálohu, aby zajistil, že podslužba má vždy 3 zdravé zálohy.
Stavové doručení je jedním z takových řešení.
Zpět k výše uvedenému scénáři, systém nákupních košíků je stavová služba.
36 podsystémů tvoří 36 instancí této stavové služby, kterou nazýváme Partitions.
Záloha pod každým podsystémem je Replica a v jedné partition jsou 3 repliky.
Aktuálně aktivní záloha je Active Replica a dvě neaktivní záložní zálohy jsou Secondary Replica.
Každá replika stejného Partiionu musí běžet na jiném uzlu.
Kód stavové služby využívá <T>rozhraní jako IReliableCollection, IReliableDictionary< T1 a T2 >k ukládání dat a interní synchronizaci.
Kromě toho může stavová služba implementovat následující funkce:
Všechny výše uvedené hodnoty lze resetovat a můžete mít stovky oddílů v systému cart, které nakládají větší zatížení. Můžete mít dokonce 5 nebo více replik na oddíl, abyste zajistili větší robustnost.
Externí systémy nezajímají, kolik oddílů má stavová služba, jsou volány podle oddílového klíče. Klíč oddílu a odpovídající oddíl jsou vyřešeny podkladovou mikro službou Service Fabric. Například ve vašem podnikání můžete mít několik milionů uživatelů, ale nastavit jen 5 oddílů. Při volání stavové služby nákupního košíku musí externí systém pouze informovat uživatelské ID (klíč oddílu) a uložená data. Tento požadavek je automaticky mapován na jednu z pěti oddílů na základě uživatelského ID a hashovacího algoritmu.
Datové operace ve stavových službách podporují transakce. Takže můžete vrátit zpět po selhání
Doufám, že výše uvedený úvod vám pomůže lépe pochopit státní službu.
Příklady kódů pro státní službu pokryjeme v následujících sekcích. |
Předchozí:Doufám, že si o tom můžete mezi sebou probratDalší:Čtyřicet sedm způsobů, jak optimalizovat program v C#
|
