În secțiunea anterioară, am discutat despre cele două concepte cele mai de bază ale Service Fabric, unul fiind Tipul de Nod și Nodul la nivel hardware. Celălalt este Aplicarea.
Node Type este o colecție de Noduri, care sunt abstracții conceptuale ale mașinilor de desfășurare. Pentru Service Fabric, un nod poate fi o mașină fizică, o mașină virtuală sau chiar cel mai popular container în prezent.
Rulând pe tipul nodului este Aplicație. Este o înțelegere abstractă la nivelul software-ului de sistem. Există mai multe Microservicii într-o aplicație. Chiar și toate serviciile de bază ale Service Fabric, cum ar fi FailoverManager Service și Naming Service, sunt Micro Servicii.
Toate funcțiile distribuite ale Service Fabric corespund implementărilor Micro Service. Putem ajusta dinamic câte instanțe trebuie să ruleze un serviciu micro pe câte noduri să distribuie presiunea de încărcare sau să efectueze backup-uri de recuperare în caz de dezastru. Fiecare instanță ascultă un port diferit, iar stratul de echilibrare a încărcării distribuie cererile către instanțe diferite.
Scenariul real
Stateful Service este unul dintre Micro Servicii.
Înainte să începem să introducem Serviciul Stateful, să luăm în considerare următoarele scenarii comune de afaceri.
Te gândești să implementezi o funcție de coș de cumpărături pe site-ul tău. După autentificare, utilizatorii vor plasa unele produse în coșul lor de cumpărături.
Data viitoare când utilizatorul se autentifică, pagina de la recepție va chema serviciul de coșuri de cumpărături și va trebui să recitească datele salvate ale coșului de cumpărături de la acest serviciu și să le afișeze.
Dacă da, cum ați reuși acest lucru?
Dacă numărul de utilizatori nu este deosebit de mare, adăugăm un tabel cu coș de cumpărături în baza de date și îl asociem cu tabelul utilizatorilor. Tabelul cartușului va avea un câmp ID de utilizator și va înregistra o cantitate mare de date despre cartuș de utilizator.
Atunci asta va aduce și alte probleme suplimentare.
Dacă numărul utilizatorilor continuă să crească, performanța tabelelor bazei de date va continua să se degradeze.
Datele din tabelele bazei de date trebuie făcute backup regulat în caz de pierdere a datelor
Dacă există o problemă cu performanța bazei de date, tabelul trebuie demontat sau chiar partiționat
Sistemul de coșuri de cumpărături trebuie să gestioneze orice ajustări ale basei de date, iar chiar și acesta poate necesita un echilibru de încărcare
Rădăcina acestei probleme este că sistemul în sine nu este proiectat să fie scalabil de la bun început. În plus, bazele de date reprezintă un potențial blocaj și o amenințare la adresa performanței.
Serviciu cu statură
Să luăm în considerare o arhitectură complet nouă.
De la început, sistemul de coșuri de cumpărături are 36 de sub-servicii care gestionează toate cererile (36 deoarece inițialele ID-ului utilizatorului sunt 0-9 a-z, un total de 36).
Cererea utilizatorului este procesată conform hash-ului inițial al ID-ului utilizatorului către un anumit subserviciu.
Subserviciul stochează datele coșului de cumpărături intern printr-o bază de date ușoară și le păstrează pe propriul său dispozitiv de stocare.
Fiecare sub-serviciu are, de asemenea, 3 backup-uri, care sincronizează constant datele stocate, iar aceste backup-uri rulează întotdeauna pe noduri diferite.
În același timp, doar un backup este responsabil pentru procesarea cererilor ca stare de activare, iar când apare o problemă cu activarea backup-ului, celelalte două backup-uri activează unul conform algoritmului de programare.
Subsistemul de recuperare în caz de dezastru creează un nou backup pentru a se asigura că subserviciul are întotdeauna 3 backup-uri sănătoase.
Serviciul cu stare este o astfel de soluție.
Revenind la scenariul de mai sus, sistemul de coșuri de cumpărături este un serviciu cu starea.
Cele 36 de subsisteme sunt cele 36 de instanțe ale acestui serviciu cu stare, pe care îl numim Partiții.
Backup-ul sub fiecare subsistem este Replica, iar în partiție există 3 Replica.
Backup-ul activ în prezent este Active Replica, iar cele două backup-uri de rezervă inactive sunt Secondary Replica.
Fiecare replică a aceluiași Partiion trebuie să ruleze pe un nod diferit.
Codul Stateful Service folosește <T>interfețe precum IReliableCollection, IReliableDictionary< T1 și T2 >pentru a salva date și a se sincroniza intern.
În plus, Stateful Service poate implementa următoarele funcționalități:
Toate numerele de mai sus pot fi resetate și poți avea sute de partiții în sistemul de cărucior pentru a încărca mai mult stres. Poți avea chiar 5 sau mai multe replici pe partiție pentru a asigura o robustețe mai mare.
Sistemele externe nu țin cont de câte partiții are Serviciul Stateful, ele sunt numite prin cheia de partiție. Cheia de partiție și partiția corespunzătoare sunt rezolvate de Micro Service de bază al Service Fabric. De exemplu, în afacerea ta, poți avea câteva milioane de utilizatori, dar ai configurat doar 5 partiții. Când apelează serviciul Stateful al coșului de cumpărături, sistemul extern trebuie doar să informeze ID-ul utilizatorului (cheia de partiție) și datele salvate. Această cerere este mapată automat pe una dintre cele cinci partiții pe baza ID-ului utilizatorului și algoritmului de hash.
Operațiunile de date în Serviciile Stateful susțin tranzacțiile. Deci poți reveni în caz de eșec
Sper ca introducerea de mai sus să te ajute să înțelegi mai bine Serviciul Statal.
Vom acoperi exemple de cod pentru Stateful Service în secțiunile următoare. |
Postat pe 15.03.2018 10:03:44
|
|
|
|
