|
|
Julkaistu 15.3.2018 10.03.44
|
|
|
|
Edellisessä osiossa käsittelimme Service Fabricin kahta alinta käsitettä, toinen on Node Type ja Node laitteistotasolla. Toinen on sovellus.
Solmutyyppi on kokoelma solmuja, jotka ovat käsitteellisiä abstraktioita käyttöönottokoneista. Service Fabricissa solmu voi olla fyysinen kone, virtuaalikone tai jopa nykyään suosituin kontti.
Solmutyypin käyttö on sovellus. Se on abstrakti ymmärrys järjestelmäohjelmiston tasolla. Sovelluksessa on useita mikropalveluita. Jopa kaikki Service Fabricin taustalla olevat palvelut, kuten FailoverManager Service ja Naming Service, ovat mikropalveluita.
Kaikki Service Fabricin hajautetut ominaisuudet vastaavat Micro Service -käyttöönottoja. Voimme dynaamisesti säätää, kuinka monta instanssia Micro Service tarvitsee toimia, kuinka monessa solmussa kuormituspaineen jakamiseksi tai katastrofipalautuksen varmuuskopioiksi. Jokainen instanssi kuuntelee eri porttia, ja kuormantasauskerros jakaa pyynnöt eri instansseille.
Todellinen tilanne
Stateful Service on yksi mikropalveluista.
Ennen kuin alamme esitellä Stateful Serviceä, tarkastellaan seuraavia yleisiä liiketoimintatilanteita.
Harkitset ostoskoritoiminnon käyttöönottoa verkkosivustollesi. Kirjautumisen jälkeen käyttäjät laittavat joitakin tuotteita ostoskoriinsa.
Seuraavalla kerralla, kun käyttäjä kirjautuu sisään, vastaanottosivu soittaa ostoskoripalveluun ja hänen täytyy lukea uudelleen tallennetut ostoskoritiedot tästä palvelusta ja näyttää ne.
Jos on, miten saavuttaisit sen?
Jos käyttäjämäärä ei ole erityisen suuri, lisäämme ostoskoritaulukon tietokantaan ja liitämme sen käyttäjätauluun. Kasettitaulussa on käyttäjätunnuskenttä, joka tallentaa suuren määrän käyttäjäkoridataa.
Sitten tämä tuo mukanaan jatkoongelmia.
Jos käyttäjämäärä jatkaa kasvuaan, tietokantataulujen suorituskyky heikkenee edelleen.
Tietokantataulun tiedot täytyy varmuuskopioida säännöllisesti mahdollisen tiedon menetyksen varalta
Jos tietokannan suorituskyvyssä on ongelmia, taulukko täytyy kumota tai jopa osioida
Ostoskorijärjestelmän täytyy hoitaa kaikki tietokannan säädöt, ja jopa se saattaa vaatia kuormantasapainotusta
Tämän ongelman juurisyy on se, että järjestelmä itsessään ei ole alun perinkään suunniteltu skaalautuviksi. Lisäksi tietokannat ovat mahdollinen pullonkaula ja uhka suorituskyvylle.
Valtiollinen palvelu
Tarkastellaanpa tällaista täysin uutta arkkitehtuuria.
Alusta alkaen ostoskorijärjestelmässä on 36 alipalvelua, jotka käsittelevät kaikki pyynnöt (36, koska käyttäjätunnuksen alkukirjaimet ovat 0–9 a-z, yhteensä 36).
Käyttäjän pyyntö käsitellään käyttäjätunnuksen alkuperäisen tiivisteen mukaisesti tiettyyn alipalveluun.
Alipalvelu tallentaa ostoskorin tiedot sisäisesti kevyen tietokannan kautta ja säilyttää ne omalla tallennuslaitteellaan.
Jokaisella alipalvelulla on myös 3 varmuuskopiota, jotka synkronoivat tallennettua dataa jatkuvasti, ja nämä varmuuskopiot toimivat aina eri solmuissa.
Samaan aikaan vain yksi varmuuskopio vastaa pyyntöjen käsittelystä aktivointitilana, ja kun varmuuskopion aktivoinnissa ilmenee ongelmia, kaksi muuta varmuuskopiota aktivoivat toisen ajastusalgoritmin mukaisesti.
Katastrofipalautusalijärjestelmä luo uuden varmuuskopion varmistaakseen, että alipalvelulla on aina kolme terveellistä varmuuskopiota.
Stateful Service on yksi tällainen ratkaisu.
Palatakseni yllä olevaan tilanteeseen, ostoskärryjärjestelmä on valtiollinen palvelu.
Nämä 36 alijärjestelmää ovat tämän tilallisen palvelun 36 instanssia, joita kutsumme osioiksi.
Jokaisen alijärjestelmän alla varmuuskopio on Replica, ja osiossa on 3 Replicaa.
Tällä hetkellä aktiivinen varmuuskopio on Aktiivinen Replika, ja kaksi passiivista varaa ovat Toissijainen Replika.
Jokaisen saman Partiionin replikan on toimittava eri solmulla.
Tilapalvelukoodi käyttää <T>rajapintoja kuten IReliableCollection, IReliableDictionary< T1 ja T2 >tietojen tallentamiseen ja sisäiseen synkronointiin.
Lisäksi tilapalvelu voi toteuttaa seuraavat ominaisuudet:
Kaikki yllä mainitut luvut voidaan nollata, ja voit laittaa satoja osioita kasettijärjestelmään kuormittamaan enemmän kuormitusta. Voit jopa käyttää 5 tai useampia replikoita per osio varmistaaksesi paremman kestävyyden.
Ulkoiset järjestelmät eivät välitä, kuinka monta osiota tilapalvelussa on, ne kutsutaan osion avaimella. Osion avain ja vastaava osio ratkaistaan taustalla olevalla Micro Service Fabricin avulla. Esimerkiksi yrityksessäsi voi olla muutama miljoona käyttäjää, mutta voit perustaa vain viisi osiota. Kun ostoskoria kutsutaan tilapalveluksi, ulkoisen järjestelmän tarvitsee ilmoittaa vain käyttäjätunnus (osioavain) ja tallennetut tiedot. Tämä pyyntö yhdistetään automaattisesti yhteen viidestä osiosta käyttäjätunnuksen ja hajautusalgoritmin perusteella.
Datatoiminnot tilapalveluissa tukevat tapahtumia. Joten voit peruuttaa epäonnistumisen seurauksena
Toivon, että yllä oleva johdanto auttaa sinua ymmärtämään paremmin valtiollista palvelua.
Seuraavissa osioissa käsittelemme Stateful Service -koodiesimerkkejä. |
Edellinen:Toivon, että voitte keskustella siitä keskenänneSeuraava:Neljäkymmentäseitsemän tapaa optimoida C#-ohjelma
|
