|
|
Opslået på 15/03/2018 10.03.44
|
|
|
|
I det forrige afsnit talte vi om de to laveste begreber inden for Service Fabric, det ene er Node-type og Node på hardware-niveau. Den anden er Anvendelse.
Node Type er en samling af noder, som er konceptuelle abstraktioner af deployerende maskiner. For Service Fabric kan en node være en fysisk maskine, en virtuel maskine eller endda den mest populære container nu.
Kørende på nodetype er Application. Det er en abstrakt forståelse på systemsoftware-niveau. Der er flere mikrotjenester i en applikation. Selv alle de underliggende tjenester i Service Fabric, såsom FailoverManager Service og Naming Service, er mikrotjenester.
Alle distribuerede funktioner i Service Fabric svarer til Micro Service-udrulninger. Vi kan dynamisk justere, hvor mange instanser en Micro Service skal køre på, hvor mange noder der skal fordeles belastningen eller udføre disaster recovery-backups. Hver instans lytter til en forskellig port, og load balancing-laget distribuerer anmodninger til forskellige instanser.
Faktisk scenarie
Stateful Service er en af mikrotjenesterne.
Før vi begynder at introducere Stateful Service, lad os overveje følgende almindelige forretningsscenarier.
Du overvejer at implementere en indkøbskurv-funktion på din hjemmeside. Efter login-login vil brugerne lægge nogle varer i deres indkøbskurv.
Næste gang brugeren logger ind, vil receptionen kalde indkøbsvognsservicen og skal genlæse de gemte indkøbskurvdata fra denne tjeneste og vise dem.
Hvis ja, hvordan ville du opnå det?
Hvis antallet af brugere ikke er særligt stort, tilføjer vi en indkøbskurvtabel til databasen og knytter den til brugertabellen. Vogntabellen vil have et bruger-ID-felt og registrere en stor mængde brugervogndata.
Så vil det give nogle opfølgende problemer.
Hvis antallet af brugere fortsætter med at stige, vil ydeevnen af databasetabellerne fortsætte med at forringes.
Datadata i databasetavlen skal sikkerhedskopieres regelmæssigt i tilfælde af datatab
Hvis der er et problem med databasens ydeevne, skal tabellen afkræftes eller endda partitioneres
Indkøbskurvssystemet skal selv håndtere eventuelle justeringer i databasen, og det kan endda have brug for load balanced.
Roden til dette problem er, at systemet i sig selv ikke er designet til at være skalerbart til at begynde med. Derudover er databaser en potentiel flaskehals og trussel mod ydeevnen.
Statslig tjeneste
Lad os overveje en helt ny arkitektur.
Fra starten har indkøbskurvsystemet 36 undertjenester, der håndterer alle forespørgsler (36 fordi initialerne i bruger-ID'et er 0-9 a-z, i alt 36).
Brugerens anmodning behandles i henhold til den indledende hash af bruger-ID'et til en specifik undertjeneste.
Undertjenesten gemmer indkøbskurvens data internt gennem en letvægtsdatabase og lagrer dem på sin egen lagringsenhed.
Hver underservice har også 3 backups, som konstant synkroniserer de lagrede data, og disse backups kører altid på forskellige noder.
Samtidig er kun én backup ansvarlig for at behandle anmodninger som en aktiveringstilstand, og når der opstår problemer med at aktivere backup'en, aktiverer de to andre backups én i henhold til planlægningsalgoritmen.
Katastrofegendannelsessubsystemet opretter en ny backup for at sikre, at undertjenesten altid har 3 sunde backups.
Stateful Service er en sådan løsning.
Tilbage til ovenstående scenarie: indkøbskurvsystemet er en stateful service.
De 36 delsystemer er de 36 instanser af denne Stateful Service, som vi kalder Partitioner.
Backupen under hvert subsystem er Replica, og der er 3 Replicas i en partition.
Den nuværende aktive backup er Active Replica, og de to inaktive standby-backups er Secondary Replica.
Hver replika af den samme Partiion skal køre på en forskellig node.
Stateful Service-koden bruger <T>grænseflader som IReliableCollection, IReliableDictionary< T1 og T2 >til at gemme data og synkronisere internt.
Derudover kan Stateful Service implementere følgende funktioner:
Alle ovenstående tal kan nulstilles, og du kan have hundredvis af partitioner i cart-systemet til at belaste mere belastning. Du kan endda have 5 eller flere replikaer pr. partition for at sikre mere robusthed.
Eksterne systemer er ligeglade med, hvor mange partitioner Stateful Service har, de kaldes med partitionsnøgle. Partitionnøglen og den tilsvarende partition løses af den underliggende Micro Service of Service Fabric. For eksempel kan du i din virksomhed have et par millioner brugere, men kun sætte 5 partitioner op. Når indkøbskurven kaldes Stateful Service, behøver det eksterne system kun at informere bruger-ID (partitionsnøgle) og de gemte data. Denne anmodning kortlægges automatisk til en af de fem partitioner baseret på bruger-ID og hash-algoritmen.
Dataoperationer i Stateful Services understøtter transaktioner. Så du kan rulle tilbage, hvis du fejler.
Jeg håber, at ovenstående introduktion kan hjælpe dig med bedre at forstå Stateful Service.
Vi vil gennemgå eksempler på regler for Stateful Service i de følgende afsnit. |
Tidligere:Jeg håber, I kan diskutere det med hinandenNæste:Syvogfyrre måder at optimere et C#-program på
|
