I forrige avsnitt snakket vi om de to laveste konseptene i Service Fabric, det ene er nodetype og node på maskinvarenivå. Den andre er Applikasjon.
Node Type er en samling av noder, som er konseptuelle abstraksjoner av maskiner som deployerer dem. For Service Fabric kan en node være en fysisk maskin, en virtuell maskin, eller til og med den mest populære containeren nå.
Kjører på nodetype er applikasjon. Det er en abstrakt forståelse på systemprogramvarenivå. Det finnes flere mikrotjenester i en applikasjon. Selv alle underliggende tjenester i Service Fabric, som FailoverManager Service og Naming Service, er mikrotjenester.
Alle distribuerte funksjoner i Service Fabric tilsvarer Micro Service-distribusjoner. Vi kan dynamisk justere hvor mange instanser en mikrotjeneste må kjøre, hvor mange noder for å fordele belastningspresset eller utføre katastrofegjenopprettingssikkerhetskopier. Hver instans lytter til en forskjellig port, og lastbalanseringslaget distribuerer forespørsler til forskjellige instanser.
Faktisk scenario
Stateful Service er en av mikrotjenestene.
Før vi begynner å introdusere Stateful Service, la oss vurdere følgende vanlige forretningsscenarier.
Du vurderer å implementere en handlekurvfunksjon på nettsiden din. Etter innlogging legger brukerne noen varer i handlekurven.
Neste gang brukeren logger inn, vil resepsjonssiden ringe handlekurvtjenesten, og du må lese de lagrede handlekurvdataene fra denne tjenesten på nytt og vise dem.
Hvis ja, hvordan ville du oppnådd det?
Hvis antall brukere ikke er spesielt stort, legger vi til en handlekurvtabell i databasen og knytter den til brukertabellen. Vogntabellen vil ha et bruker-ID-felt og registrere store mengder brukervogndata.
Dette vil føre til noen oppfølgingsproblemer.
Hvis antallet brukere fortsetter å øke, vil ytelsen til databasetabellene fortsette å forringes.
Data i databasetabeller må sikkerhetskopieres regelmessig i tilfelle datatap
Hvis det oppstår problemer med databaseytelsen, må tabellen avkreftes eller til og med partisjoneres
Handlekurvsystemet må håndtere alle justeringer i databasen, og det kan også være lastbalansert
Roten til dette problemet er at systemet i seg selv ikke er designet for å være skalerbart i utgangspunktet. I tillegg er databaser en potensiell flaskehals og trussel mot ytelsen.
Statlig tjeneste
La oss vurdere en helt ny arkitektur.
Fra starten av har handlekurvsystemet 36 undertjenester som håndterer alle forespørsler (36 fordi initialene i bruker-ID-en er 0-9 a-z, totalt 36).
Brukerens forespørsel behandles i henhold til den opprinnelige hashen av bruker-ID-en til en spesifikk undertjeneste.
Undertjenesten lagrer handlevogndataene internt gjennom en lettvektsdatabase og lagrer dem på sin egen lagringsenhet.
Hver undertjeneste har også 3 sikkerhetskopier, som kontinuerlig synkroniserer de lagrede dataene, og disse sikkerhetskopiene kjører alltid på forskjellige noder.
Samtidig er det kun én sikkerhetskopi som er ansvarlig for å behandle forespørsler som aktiveringstilstand, og når det oppstår problemer med å aktivere sikkerhetskopien, aktiverer de to andre sikkerhetskopiene én i henhold til planleggingsalgoritmen.
Katastrofegjenopprettingsundersystemet oppretter en ny backup for å sikre at undertjenesten alltid har 3 friske sikkerhetskopier.
Stateful Service er en slik løsning.
Tilbake til det ovennevnte scenariet, handlekurvsystemet er en stateful tjeneste.
De 36 delsystemene er de 36 instansene av denne Stateful Service, som vi kaller partisjoner.
Sikkerhetskopien under hvert delsystem er Replica, og det er 3 Replicas i en partisjon.
Den nåværende aktive backupen er Active Replica, og de to inaktive standby-backupene er Secondary Replica.
Hver replika av samme Partiion må kjøre på en annen node.
Stateful Service-koden bruker <T>grensesnitt som IReliableCollection, IReliableDictionary< T1 og T2 >for å lagre data og synkronisere internt.
I tillegg kan Stateful Service implementere følgende funksjoner:
Alle de ovennevnte tallene kan nullstilles, og du kan ha hundrevis av partisjoner i vognsystemet for å belaste mer belastning. Du kan til og med ha 5 eller flere replikaer per partisjon for å sikre mer robusthet.
Eksterne systemer bryr seg ikke om hvor mange partisjoner Stateful Service har, de kalles med partisjonsnøkkel. Partisjonsnøkkelen og den tilsvarende partisjonen løses av den underliggende Micro Service of Service Fabric. For eksempel, i din virksomhet kan du ha noen millioner brukere, men bare sette opp 5 partisjoner. Når handlevognen kalles Stateful Service, trenger det eksterne systemet bare å informere bruker-ID (partisjonsnøkkel) og lagrede data. Denne forespørselen mappes automatisk til en av de fem partisjonene basert på bruker-ID og hash-algoritmen.
Dataoperasjoner i Stateful Services støtter transaksjoner. Så du kan rulle tilbake ved feil
Jeg håper introduksjonen ovenfor kan hjelpe deg å forstå Stateful Service bedre.
Vi vil dekke kodeeksempler for Stateful Service i følgende avsnitt. |
Publisert på 15.03.2018 10:03:44
|
|
|
|
