I föregående avsnitt pratade vi om de två lägsta koncepten inom Service Fabric, det ena är Nodtyp och Nod på hårdvarunivå. Den andra är Applikation.
Nodtyp är en samling noder, som är konceptuella abstraktioner av distribuerande maskiner. För Service Fabric kan en nod vara en fysisk maskin, en virtuell maskin eller till och med den mest populära containern nu.
Kör på nodtyp är applikation. Det är en abstrakt förståelse på systemmjukvarunivå. Det finns flera mikrotjänster i en applikation. Även alla underliggande tjänster i Service Fabric, såsom FailoverManager Service och Naming Service, är mikrotjänster.
Alla distribuerade funktioner i Service Fabric motsvarar Micro Service-distributioner. Vi kan dynamiskt justera hur många instanser en mikrotjänst behöver köras på, hur många noder för att fördela belastningstrycket eller utföra katastrofåterställningsbackup. Varje instans lyssnar på en annan port, och lastbalanseringslagret distribuerar förfrågningar till olika instanser.
Faktiskt scenario
Stateful Service är en av mikrotjänsterna.
Innan vi börjar introducera Stateful Service, låt oss överväga följande vanliga affärsscenarier.
Du funderar på att implementera en kundvagnsfunktion på din webbplats. Efter inloggning lägger användarna några varor i sin kundvagn.
Nästa gång användaren loggar in kommer receptionssidan att ringa kundvagnstjänsten och behöva läsa om den sparade kundvagnsdatan från denna tjänst och visa den.
Om så är fallet, hur skulle du uppnå det?
Om antalet användare inte är särskilt stort lägger vi till en kundvagnstabell i databasen och kopplar den till användartabellen. Kundvagnstabellen kommer att ha ett användar-ID-fält och registrera en stor mängd användarkundvagnsdata.
Då kommer detta att medföra några uppföljningsproblem.
Om antalet användare fortsätter att öka kommer prestandan hos databastabellerna att fortsätta försämras.
Data i databastabeller måste säkerhetskopieras regelbundet vid dataförlust
Om det uppstår problem med databasens prestanda måste tabellen avfärdas eller till och med partitioneras
Kundvagnssystemet måste hantera alla justeringar i databasen, och även det kan behöva lastbalanseras
Roten till detta problem är att systemet i sig inte är designat för att vara skalbart från början. Dessutom är databaser en potentiell flaskhals och ett hot mot prestandan.
Statlig tjänst
Låt oss betrakta en helt ny arkitektur.
Från början har kundvagnssystemet 36 undertjänster som hanterar alla förfrågningar (36 eftersom initialerna i användar-ID är 0-9 a-z, totalt 36).
Användarens förfrågan behandlas enligt den initiala hashen av användar-ID:t till en specifik undertjänst.
Deltjänsten lagrar kundvagnsdata internt i en lättviktig databas och lagrar den på sin egen lagringsenhet.
Varje undertjänst har också 3 säkerhetskopior som ständigt synkroniserar den lagrade datan, och dessa säkerhetskopior körs alltid på olika noder.
Samtidigt är endast en backup ansvarig för att behandla förfrågningar som aktiveringstillstånd, och när det uppstår problem med att aktivera backupen aktiverar de andra två backuperna en enligt schemaläggningsalgoritmen.
Katastrofåterställningssubsystemet skapar en ny backup för att säkerställa att undertjänsten alltid har 3 friska backuper.
Stateful Service är en sådan lösning.
Tillbaka till ovanstående scenario, kundvagnssystemet är en stateful tjänst.
De 36 delsystemen är de 36 instanserna av denna Stateful Service, som vi kallar partitioner.
Backupen under varje delsystem är Replica, och det finns 3 Replicas i en partition.
Den för närvarande aktiva backupen är Active Replica, och de två inaktiva standby-backuperna är Secondary Replica.
Varje replika av samma Partiion måste köras på en annan nod.
Stateful Service-koden använder <T>gränssnitt som IReliableCollection, IReliableDictionary< T1 och T2 >för att spara data och synkronisera internt.
Dessutom kan Stateful Service implementera följande funktioner:
Alla ovanstående siffror kan återställas, och du kan ha hundratals partitioner i vagnsystemet för att lasta mer belastning. Du kan till och med ha 5 eller fler repliker per partition för att säkerställa ökad robusthet.
Externa system bryr sig inte om hur många partitioner Stateful Service har, de anropas med partitionsnyckel. Partitionsnyckeln och motsvarande partition löses av den underliggande Micro Service of Service Fabric. Till exempel kan du i ditt företag ha några miljoner användare, men bara sätta upp 5 partitioner. När kundvagnen anropas Stateful Service behöver det externa systemet bara informera användar-ID (partitionsnyckel) och sparad data. Denna förfrågan mappas automatiskt till en av de fem partitionerna baserat på användar-ID och hashalgoritm.
Dataoperationer i Stateful Services stödjer transaktioner. Så du kan rulla tillbaka vid misslyckande
Jag hoppas att ovanstående introduktion kan hjälpa dig att bättre förstå Stateful Service.
Vi kommer att gå igenom kodexempel för Stateful Service i följande avsnitt. |
Publicerad på 2018-03-15 10:03:44
|
|
|
|
