|
|
Publicēts 15.03.2018 10:03:44
|
|
|
|
Iepriekšējā sadaļā mēs runājām par diviem zemākajiem Service Fabric jēdzieniem, viens ir mezgla tips un mezgls aparatūras līmenī. Otrs ir pielietojums.
Mezgla tips ir mezglu kolekcija, kas ir konceptuālas mašīnu izvietošanas abstrakcijas. Service Fabric mezgls var būt fiziska mašīna, virtuālā mašīna vai pat populārākais konteiners.
Darbojas ar mezgla tipu ir lietojumprogramma. Tā ir abstrakta izpratne sistēmas programmatūras līmenī. Lietojumprogrammā ir vairāki mikro pakalpojumi. Pat visi Service Fabric pamatā esošie pakalpojumi, piemēram, FailoverManager pakalpojums un nosaukumu pakalpojums, ir mikro pakalpojumi.
Visas Service Fabric izplatītās funkcijas atbilst Micro Service izvietojumiem. Mēs varam dinamiski pielāgot, cik instancēs mikro pakalpojumam ir jādarbojas, cik mezglos, lai sadalītu slodzes spiedienu vai veiktu katastrofas atjaunošanas dublējumus. Katra instance klausās citu portu, un slodzes balansēšanas slānis sadala pieprasījumus dažādām instancēm.
Faktiskais scenārijs
Stateful pakalpojums ir viens no mikro pakalpojumiem.
Pirms sākam ieviest Stateful Service, aplūkosim tālāk norādītos izplatītākos biznesa scenārijus.
Jūs domājat par iepirkumu groza funkcijas ieviešanu savā tīmekļa vietnē. Pēc pieteikšanās lietotāji ievietos dažas preces savā iepirkumu grozā.
Nākamreiz, kad lietotājs pieteiksies, reģistratūras lapa piezvanīs iepirkumu groza pakalpojumam, un tam būs atkārtoti jānolasa saglabātie iepirkumu groza dati no šī pakalpojuma un jāparāda tie.
Ja jā, kā jūs to sasniegtu?
Ja lietotāju skaits nav īpaši liels, mēs datu bāzei pievienosim iepirkumu groza tabulu un saistīsim to ar lietotāju tabulu. Grozu tabulā būs lietotāja ID lauks, un tajā tiks ierakstīts liels lietotāju grozu datu apjoms.
Tad tas radīs dažas turpmākas problēmas.
Ja lietotāju skaits turpina palielināties, datu bāzes tabulu veiktspēja turpinās pasliktināties.
Datu bāzes tabulu dati ir regulāri jādublē datu zuduma gadījumā
Ja rodas problēmas ar datu bāzes veiktspēju, tabula ir jāatmasko vai pat jāsadala
Pašai iepirkumu grozu sistēmai ir jārīkojas ar jebkādām datu bāzes korekcijām, un pat tai var būt jābūt līdzsvarotai slodzei
Šīs problēmas sakne ir tāda, ka pati sistēma nav paredzēta mērogojamai. Turklāt datu bāzes ir potenciāls vājš kakls un drauds veiktspējai.
Stāvokļa pakalpojums
Apskatīsim šādu pilnīgi jaunu arhitektūru.
Jau no paša sākuma iepirkumu grozu sistēmā ir 36 apakšpakalpojumi, kas apstrādā visus pieprasījumus (36, jo lietotāja ID iniciāļi ir 0-9 a-z, kopā 36).
Lietotāja pieprasījums tiek apstrādāts saskaņā ar lietotāja ID sākotnējo jaucējkodu konkrētam apakšpakalpojumam.
Apakšpakalpojums glabā iepirkumu groza datus iekšienē, izmantojot vieglu datu bāzi, un saglabā tos savā atmiņas ierīcē.
Katram apakšpakalpojumam ir arī 3 dublējumi, kas pastāvīgi sinhronizē saglabātos datus, un šie dublējumi vienmēr darbojas dažādos mezglos.
Tajā pašā laikā tikai viens dublējums ir atbildīgs par pieprasījumu apstrādi kā aktivizācijas stāvokli, un, ja rodas problēmas ar dublējuma aktivizēšanu, pārējie divi dublējumi aktivizē vienu saskaņā ar plānošanas algoritmu.
Katastrofas atkopšanas apakšsistēma izveido jaunu dublējumu, lai nodrošinātu, ka apakšpakalpojumam vienmēr ir 3 veselīgi dublējumi.
Valsts dienests ir viens no šādiem risinājumiem.
Atgriežoties pie iepriekš minētā scenārija, iepirkumu grozu sistēma ir stāvokļa pakalpojums.
36 apakšsistēmas ir 36 šī stāvokļa pakalpojuma gadījumi, ko mēs saucam par nodalījumiem.
Dublējums katrā apakšsistēmā ir Replica, un nodalījumā ir 3 Replicas.
Pašlaik aktīvais dublējums ir Active Replica, un divi neaktīvie gaidstāves dublējumi ir Secondary Replica.
Katrai viena un tā paša Partiion kopijai jādarbojas citā mezglā.
Stāvokļa pakalpojuma kods izmanto <T>tādus interfeisus kā IReliableCollection, IReliableDictionary< T1 un T2 >lai saglabātu datus un sinhronizētu iekšēji.
Turklāt Stateful Service var ieviest šādus līdzekļus:
Visus iepriekš minētos numurus var atiestatīt, un grozu sistēmā var būt simtiem starpsienu, lai ielādētu lielāku stresu. Katrā nodalījumā var būt pat 5 vai vairāk replikas, lai nodrošinātu lielāku izturību.
Ārējām sistēmām ir vienalga, cik nodalījumu ir Stateful Service, tās tiek izsauktas ar nodalījuma atslēgu. Nodalījuma atslēgu un atbilstošo nodalījumu atrisina pamatā esošais Service Fabric mikropakalpojums. Piemēram, jūsu biznesā jums var būt daži miljoni lietotāju, bet iestatiet tikai 5 nodalījumus. Izsaucot iepirkumu grozu Stateful Service, ārējai sistēmai ir jāinformē tikai lietotāja ID (nodalījuma atslēga) un saglabātie dati. Šis pieprasījums tiek automātiski kartēts uz vienu no pieciem nodalījumiem, pamatojoties uz lietotāja ID un jaucējalgoritmu.
Datu operācijas Stateful Services atbalsta transakcijas. Tātad jūs varat atgriezties kļūmes gadījumā
Es ceru, ka iepriekš minētais ievads var palīdzēt jums labāk izprast Stateful Service.
Nākamajās sadaļās aplūkosim stāvokļa pakalpojuma koda piemērus. |
Iepriekšējo:Es ceru, ka jūs varat to apspriest savā starpāNākamo:Četrdesmit septiņi veidi, kā optimizēt C# programmu
|
