Overzicht van Reliable Services
Azure Service Fabric vereenvoudigt het schrijven en beheren van stateless en stateful services. In dit onderwerp komt het volgende aan de orde:
- Het Reliable Services-programmeermodel voor staatloze en stateful services.
- De keuzes die u moet maken bij het schrijven van een Reliable Service.
- Enkele scenario's en voorbeelden van wanneer u Reliable Services gebruikt en hoe ze worden geschreven.
Reliable Services is een van de programmeermodellen die beschikbaar zijn in Service Fabric. Een andere is het Reliable Actor-programmeermodel, dat een Virtual Actor-toepassingsframework biedt boven op het Reliable Services-model. Zie Inleiding tot Service Fabric Reliable Actors voor meer informatie over Reliable Actors.
Service Fabric beheert de levensduur van services, van inrichting en implementatie via upgrade en verwijdering, via Service Fabric-toepassingsbeheer.
Wat zijn Reliable Services?
Reliable Services biedt u een eenvoudig, krachtig programmeermodel op het hoogste niveau om u te helpen uit te drukken wat belangrijk is voor uw toepassing. Met het Reliable Services-programmeermodel krijgt u het volgende:
- Toegang tot Service Fabric-API's. In tegenstelling tot Service Fabric-services die zijn gemodelleerd als gast uitvoerbare bestanden, kunnen Reliable Services Service Fabric-API's rechtstreeks gebruiken. Hierdoor kunnen services het volgende doen:
- Een query uitvoeren op het systeem
- Status rapporteren over entiteiten in het cluster
- Meldingen ontvangen over configuratie- en codewijzigingen
- Zoeken en communiceren met andere services,
- Betrouwbare verzamelingen gebruiken
- Krijg toegang tot veel andere mogelijkheden, allemaal vanuit een eersteklas programmeermodel in verschillende programmeertalen.
- Een eenvoudig model voor het uitvoeren van uw eigen code die lijkt op andere bekende programmeermodellen. Uw code heeft een goed gedefinieerd toegangspunt en eenvoudig beheerde levenscyclus.
- Een pluggable communicatiemodel. Gebruik het transport van uw keuze, zoals HTTP met web-API, WebSockets, aangepaste TCP-protocollen of iets anders. Reliable Services bieden een aantal uitstekende out-of-the-box opties die u kunt gebruiken, of u kunt uw eigen opties bieden.
- Voor stateful services kunt u met het Reliable Services-programmeermodel uw status consistent en betrouwbaar opslaan in uw service met behulp van Reliable Collections. Betrouwbare verzamelingen zijn een eenvoudige set maximaal beschikbare en betrouwbare verzamelingsklassen die bekend zijn met iedereen die C#-verzamelingen heeft gebruikt. Normaal gesproken hebben services externe systemen nodig voor Betrouwbaar statusbeheer. Met Reliable Collections kunt u uw status naast uw berekening opslaan met dezelfde hoge beschikbaarheid en betrouwbaarheid die u van maximaal beschikbare externe winkels verwacht. Dit model verbetert ook de latentie omdat u de rekenkracht en de status die nodig is om te functioneren, co-loceert.
Waardoor Reliable Services anders is
Reliable Services verschillen van de services die u mogelijk eerder hebt geschreven, omdat Service Fabric het volgende biedt:
- Betrouwbaarheid : uw service blijft zelfs in onbetrouwbare omgevingen waar uw machines mislukken of netwerkproblemen ondervinden, of in gevallen waarin de services zelf fouten tegenkomen en vastlopen of mislukken. Voor stateful services blijft uw status behouden, zelfs in aanwezigheid van netwerk- of andere fouten.
- Beschikbaarheid : uw service is bereikbaar en reageert. Service Fabric onderhoudt het gewenste aantal actieve exemplaren.
- Schaalbaarheid: services worden losgekoppeld van specifieke hardware en ze kunnen zo nodig groeien of verkleinen door het toevoegen of verwijderen van hardware of andere resources. Services worden eenvoudig gepartitioneerd (met name in de stateful case) om ervoor te zorgen dat de service gedeeltelijke fouten kan schalen en afhandelen. Services kunnen dynamisch worden gemaakt en verwijderd via code, waardoor meer exemplaren zo nodig kunnen worden uitgebreid, bijvoorbeeld als reactie op klantaanvragen. Ten slotte moedigt Service Fabric services aan om lichtgewicht te zijn. Met Service Fabric kunnen duizenden services binnen één proces worden ingericht, in plaats van dat volledige exemplaren of processen van het besturingssysteem worden toegewezen aan één exemplaar van een service.
- Consistentie : informatie die is opgeslagen in een Reliable Service, kan gegarandeerd consistent zijn. Dit geldt zelfs voor meerdere Reliable Collections binnen een service. Wijzigingen in verzamelingen binnen een service kunnen op transactionele atomische wijze worden aangebracht.
Servicelevenscyclus
Of uw service nu stateful of stateless is, Reliable Services biedt een eenvoudige levenscyclus waarmee u snel uw code kunt aansluiten en aan de slag kunt gaan. Voor het ophalen van een nieuwe service moet u twee methoden implementeren:
- CreateServiceReplicaListeners/CreateServiceInstanceListeners : met deze methode definieert de service de communicatiestack(s) die deze wil gebruiken. De communicatiestack, zoals web-API, definieert het luistereindpunt of de eindpunten voor de service (hoe clients de service bereiken). Ook wordt gedefinieerd hoe de berichten die worden weergegeven, communiceren met de rest van de servicecode.
- RunAsync : deze methode is de plek waar uw service de bedrijfslogica uitvoert en waar alle achtergrondtaken worden gestart die voor de levensduur van de service moeten worden uitgevoerd. Het opgegeven annuleringstoken is een signaal voor wanneer dat werk moet stoppen. Als de service bijvoorbeeld berichten uit een betrouwbare wachtrij moet halen en ze moet verwerken, gebeurt dat werk.
Lees verder als u voor het eerst meer wilt weten over betrouwbare services. Als u op zoek bent naar een gedetailleerd overzicht van de levenscyclus van betrouwbare services, bekijkt u het overzicht van de levenscyclus van Reliable Services.
Voorbeeldservices
Laten we eens kijken hoe het Reliable Services-model werkt met staatloze en stateful services.
Stateless Reliable Services
Een staatloze service is een service waarbij er geen status wordt onderhouden binnen de service tussen aanroepen. Elke status die aanwezig is, is volledig wegwerpbaar en vereist geen synchronisatie, replicatie, persistentie of hoge beschikbaarheid.
Denk bijvoorbeeld aan een rekenmachine die geen geheugen heeft en alle termen en bewerkingen ontvangt die in één keer moeten worden uitgevoerd.
In dit geval kan de RunAsync() (C#) of runAsync() (Java) van de service leeg zijn, omdat er geen achtergrondtaakverwerking is die de service moet uitvoeren. Wanneer de rekenmachineservice wordt gemaakt, retourneert deze een ICommunicationListener (C#) of CommunicationListener (Java) (bijvoorbeeld Web-API) waarmee een luistereindpunt op een bepaalde poort wordt geopend. Dit luistereindpunt koppelt aan de verschillende berekeningsmethoden (bijvoorbeeld: 'Add(n1, n2)' waarmee de openbare API van de rekenmachine wordt gedefinieerd.
Wanneer een aanroep van een client wordt gedaan, wordt de juiste methode aangeroepen en voert de rekenmachineservice de bewerkingen uit op de opgegeven gegevens en retourneert het resultaat. Er wordt geen status opgeslagen.
Als u geen interne status opslaat, is deze voorbeeldcalculator eenvoudig. Maar de meeste services zijn niet echt staatloos. In plaats daarvan externaliseren ze hun status naar een ander archief. (Een web-app die afhankelijk is van het behouden van de sessiestatus in een back-uparchief of cache is bijvoorbeeld niet staatloos.)
Een veelvoorkomend voorbeeld van hoe staatloze services worden gebruikt in Service Fabric, is een front-end waarmee de openbare API voor een webtoepassing beschikbaar wordt gemaakt. De front-endservice praat vervolgens met stateful services om een gebruikersaanvraag te voltooien. In dit geval worden oproepen van clients omgeleid naar een bekende poort, zoals 80, waar de stateless service luistert. Deze staatloze service ontvangt de oproep en bepaalt of de oproep afkomstig is van een vertrouwde partij en voor welke service deze is bestemd. Vervolgens stuurt de stateless service de aanroep door naar de juiste partitie van de stateful service en wacht op een antwoord. Wanneer de stateless service een antwoord ontvangt, reageert deze op de oorspronkelijke client. Een voorbeeld van een dergelijke service is het Voorbeeld aan de slag met Service Fabric (C# / Java), onder andere Service Fabric-voorbeelden in die opslagplaats.
Stateful Reliable Services
Een stateful service is een service die een deel van de status consistent moet houden en aanwezig moet zijn om de service te laten functioneren. Overweeg een service die voortdurend een doorlopend gemiddelde van een bepaalde waarde berekent op basis van updates die worden ontvangen. Hiervoor moet deze beschikken over de huidige set binnenkomende aanvragen die moeten worden verwerkt en het huidige gemiddelde. Elke service die informatie ophaalt, verwerkt en opslaat in een extern archief (zoals een Azure-blob of tabelarchief vandaag) is stateful. Het houdt alleen de status in het externe statusarchief.
De meeste services slaan tegenwoordig hun status extern op, omdat de externe opslag zorgt voor betrouwbaarheid, beschikbaarheid, schaalbaarheid en consistentie voor die status. In Service Fabric zijn services niet vereist om hun status extern op te slaan. Service Fabric zorgt voor deze vereisten voor zowel de servicecode als de servicestatus.
Stel dat we een service willen schrijven waarmee afbeeldingen worden verwerkt. Hiervoor neemt de service een afbeelding en de reeks conversies op die afbeelding in beslag. Deze service retourneert een communicatielistener (stel dat het een WebAPI is) die een API beschikbaar maakt, zoals ConvertImage(Image i, IList<Conversion> conversions). Wanneer een aanvraag wordt ontvangen, slaat de service deze op in een IReliableQueueen retourneert de service een id naar de client, zodat de aanvraag kan worden bijgehouden.
In deze service RunAsync() kan het complexer zijn. De service heeft een lus binnen RunAsync() de service die aanvragen uithaalt IReliableQueue en de aangevraagde conversies uitvoert. De resultaten worden opgeslagen in een IReliableDictionary , zodat wanneer de client terugkomt, hun geconverteerde installatiekopieën kunnen ophalen. Om ervoor te zorgen dat zelfs als er iets mislukt de installatiekopie niet verloren gaat, deze Reliable Service uit de wachtrij haalt, de conversies uitvoert en het resultaat in één transactie opslaat. In dit geval wordt het bericht uit de wachtrij verwijderd en worden de resultaten alleen opgeslagen in de resultatenwoordenlijst wanneer de conversies zijn voltooid. De service kan de installatiekopie ook uit de wachtrij halen en deze onmiddellijk opslaan in een externe opslag. Dit vermindert de hoeveelheid status die de service moet beheren, maar verhoogt de complexiteit omdat de service de benodigde metagegevens moet behouden om het externe archief te beheren. Als er iets in het midden is mislukt, blijft de aanvraag in de wachtrij staan totdat deze wordt verwerkt.
Hoewel deze service lijkt op een typische .NET-service, is het verschil dat de gegevensstructuren die worden gebruikt (IReliableQueue en IReliableDictionary) worden geleverd door Service Fabric en zeer betrouwbaar, beschikbaar en consistent zijn.
Wanneer gebruikt u Reliable Services-API's?
Overweeg Reliable Services-API's als:
- U wilt dat de code van uw service (en optioneel) maximaal beschikbaar en betrouwbaar is.
- U hebt transactionele garanties nodig voor meerdere statuseenheden (bijvoorbeeld orders en orderregelitems).
- De status van uw toepassing kan op natuurlijke wijze worden gemodelleerd als betrouwbare woordenlijsten en wachtrijen.
- De code of status van uw toepassingen moet maximaal beschikbaar zijn met lees- en schrijfbewerkingen met lage latentie.
- Uw toepassing moet de gelijktijdigheid of granulariteit van transacties in een of meer betrouwbare verzamelingen beheren.
- U wilt de communicatie beheren of het partitioneringsschema voor uw service beheren.
- Uw code heeft een gratis threaded runtime-omgeving nodig.
- Uw toepassing moet tijdens runtime dynamisch betrouwbare woordenlijsten of wachtrijen of hele services maken of vernietigen.
- U moet programmatisch de door Service Fabric geleverde back-up- en herstelfuncties beheren voor de status van uw service.
- Uw toepassing moet de wijzigingsgeschiedenis voor de statuseenheden bijhouden.
- U wilt externe, aangepaste staatsproviders ontwikkelen of gebruiken.