In de vorige sectie bespraken we de twee laagste concepten van Service Fabric: het ene is Node-type en Node op hardwareniveau. De andere is Applicatie.
Node Type is een verzameling van Nodes, die conceptuele abstracties zijn van het uitrollen van machines. Voor Service Fabric kan een node een fysieke machine, een virtuele machine of zelfs de populairste container van nu zijn.
Draaien op Node Type is Applicatie. Het is een abstract begrip op het niveau van systeemsoftware. Er zijn meerdere Microservices in een applicatie. Zelfs alle onderliggende diensten van Service Fabric, zoals FailoverManager Service en Naming Service, zijn Microservices.
Alle gedistribueerde functies van Service Fabric komen overeen met Micro Service-implementaties. We kunnen dynamisch aanpassen hoeveel instanties een Microservice moet draaien op hoeveel nodes om de belastingdruk te verdelen of disaster recovery-back-ups uit te voeren. Elke instantie luistert naar een andere poort, en de load balance-laag verdeelt verzoeken naar verschillende instanties.
Werkelijke situatie
Stateful Service is een van de Microservices.
Voordat we Stateful Service introduceren, laten we de volgende veelvoorkomende zakelijke scenario's bekijken.
Je denkt eraan om een winkelwagenfunctie op je website te implementeren. Na het inloggen plaatsen gebruikers enkele artikelen in hun winkelwagen.
De volgende keer dat de gebruiker inlogt, roept de receptiepagina de winkelwagenservice op en moet de opgeslagen winkelwagengegevens van deze dienst opnieuw lezen en weergeven.
Zo ja, hoe zou je dat bereiken?
Als het aantal gebruikers niet bijzonder groot is, voegen we een winkelwagentabel toe aan de database en koppelen deze aan de gebruikerstabel. De carttabel bevat een gebruikers-ID-veld en registreert een grote hoeveelheid gebruikerskaartgegevens.
Dan brengt dit wat vervolgproblemen met zich mee.
Als het aantal gebruikers blijft toenemen, zullen de prestaties van de databasetabellen blijven achteruitgaan.
Datagegevens van databasetabellen moeten regelmatig worden geback-upt in geval van dataverlies
Als er een probleem is met de databaseprestaties, moet de tabel worden ontkracht of zelfs gepartitioneerd
Het winkelwagensysteem zelf moet alle aanpassingen aan de database verwerken, en zelfs het kan nodig zijn om load balanced te worden
De kern van dit probleem is dat het systeem zelf in de eerste plaats niet ontworpen is om schaalbaar te zijn. Daarnaast vormen databases een potentiële bottleneck en bedreiging voor de prestaties.
Staatvolle Dienst
Laten we zo'n geheel nieuwe architectuur overwegen.
Vanaf het begin heeft het winkelwagensysteem 36 subservices die alle verzoeken afhandelen (36 omdat de initialen van de gebruikers-ID 0-9 a-z zijn, in totaal 36).
Het verzoek van de gebruiker wordt verwerkt op basis van de initiële hash van de gebruikers-ID aan een specifieke subservice.
De subservice slaat de gegevens van het winkelwagentje intern op via een lichtgewicht database en bewaart deze op zijn eigen opslagapparaat.
Elke subservice heeft ook 3 back-ups, die voortdurend de opgeslagen data synchroniseren, en deze back-ups draaien altijd op verschillende nodes.
Tegelijkertijd is slechts één back-up verantwoordelijk voor het verwerken van verzoeken als activatietoestand, en wanneer er een probleem is met het activeren van de back-up, activeren de andere twee back-ups er één volgens het planningsalgoritme.
Het disaster recovery-subsysteem maakt een nieuwe back-up aan om ervoor te zorgen dat de subservice altijd 3 gezonde back-ups heeft.
Stateful Service is zo'n oplossing.
Terug naar het bovenstaande scenario: het winkelwagensysteem is een stateful service.
De 36 subsystemen zijn de 36 instanties van deze Stateful Service, die wij Partitions noemen.
De back-up onder elk subsysteem is Replica, en er zijn 3 Replica's in een partitie.
De momenteel actieve back-up is Active Replica, en de twee inactieve standby-back-ups zijn Secondary Replica.
Elke replica van dezelfde Partiion moet op een andere node draaien.
De Stateful Service-code gebruikt <T>interfaces zoals IReliableCollection, IReliableDictionary< T1 en T2 >om gegevens op te slaan en intern te synchroniseren.
Daarnaast kan Stateful Service de volgende functies implementeren:
Al deze getallen kunnen worden gereset, en je kunt honderden partities in het cart-systeem hebben om meer stress te laden. Je kunt zelfs 5 of meer replica's per partitie hebben om robuuster te zijn.
Externe systemen maakt niet uit hoeveel partities de Stateful Service heeft, ze worden aangeroepen met partitiesleutel. De partitiesleutel en de bijbehorende partitie worden opgelost door de onderliggende Micro Service of Service Fabric. In jouw bedrijf heb je bijvoorbeeld misschien een paar miljoen gebruikers, maar stel je slechts 5 partities in. Bij het aanroepen van de winkelwagentje Stateful Service hoeft het externe systeem alleen de gebruikers-ID (partitiesleutel) en de opgeslagen gegevens te informeren. Dit verzoek wordt automatisch toegewezen aan een van de vijf partities op basis van de gebruikers-ID en het hash-algoritme.
Data-operaties in Stateful Services ondersteunen transacties. Dus je kunt terugrollen bij een mislukking
Ik hoop dat bovenstaande inleiding je kan helpen Stateful Service beter te begrijpen.
We behandelen codevoorbeelden voor Stateful Service in de volgende secties. |
Geplaatst op 15-03-2018 10:03:44
|
|
|
|
