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 stateless en stateful services.
- De keuzes die u moet maken bij het schrijven van een Reliable Service.
- Enkele scenario's en voorbeelden van het gebruik van Reliable Services en hoe deze worden geschreven.
Reliable Services is een van de programmeermodellen die beschikbaar zijn op Service Fabric. Een andere is het programmeermodel Reliable Actor , 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 tot 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 uitvoerbare gastbestanden, kunnen Reliable Services Service Fabric-API's rechtstreeks gebruiken. Hierdoor kunnen services het volgende doen:
- Een query uitvoeren op het systeem
- Rapportstatus over entiteiten in het cluster
- Meldingen ontvangen over configuratie- en codewijzigingen
- Andere services zoeken en ermee communiceren,
- De Betrouwbare verzamelingen gebruiken
- Toegang tot veel andere mogelijkheden, allemaal vanuit een eersteklas programmeermodel in verschillende programmeertalen.
- Een eenvoudig model voor het uitvoeren van uw eigen code dat aanvoelt als andere vertrouwde programmeermodellen. Uw code heeft een goed gedefinieerd toegangspunt en eenvoudig te beheren levenscyclus.
- Een pluggable communicatiemodel. Gebruik het transport van uw keuze, zoals HTTP met web-API, WebSockets, aangepaste TCP-protocollen of iets anders. Reliable Services biedt een aantal uitstekende out-of-the-box-opties die u kunt gebruiken, of u kunt uw eigen opties leveren.
- Voor stateful services kunt u met het programmeermodel Reliable Services uw status consistent en betrouwbaar binnen uw service opslaan met behulp van Reliable Collections. Reliable Collections is een eenvoudige set maximaal beschikbare en betrouwbare verzamelingsklassen die bekend zijn voor iedereen die C#-verzamelingen heeft gebruikt. Traditioneel hadden services externe systemen nodig voor betrouwbaar statusbeheer. Met Betrouwbare verzamelingen kunt u uw status naast uw rekenproces opslaan met dezelfde hoge beschikbaarheid en betrouwbaarheid die u gewend bent van zeer beschikbare externe winkels. Dit model verbetert ook de latentie, omdat u de rekenkracht en de status die nodig is om te functioneren, co-loceert.
Wat Reliable Services anders maakt
Reliable Services verschillen van services die u mogelijk eerder hebt geschreven, omdat Service Fabric het volgende biedt:
- Betrouwbaarheid : uw service blijft actief, zelfs in onbetrouwbare omgevingen waarin uw machines uitvallen 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 de aanwezigheid van netwerk- of andere storingen.
- 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 hardware of andere resources toe te dienen of te verwijderen. Services kunnen eenvoudig worden gepartitioneerd (met name in het stateful geval) om ervoor te zorgen dat de service kan schalen en gedeeltelijke fouten kan afhandelen. Services kunnen dynamisch worden gemaakt en verwijderd via code, zodat meer exemplaren indien nodig kunnen worden toegevoegd, bijvoorbeeld als reactie op aanvragen van klanten. Ten slotte moedigt Service Fabric aan dat services licht van gewicht zijn. Met Service Fabric kunnen duizenden services binnen één proces worden ingericht, in plaats van dat volledige instanties of processen van het besturingssysteem aan één exemplaar van een service moeten worden toegewezen.
- Consistentie : alle informatie die is opgeslagen in een Reliable Service kan gegarandeerd consistent zijn. Dit geldt zelfs voor meerdere Betrouwbare verzamelingen binnen een service. Wijzigingen in verzamelingen binnen een service kunnen op een transactioneel atomische manier worden aangebracht.
Levenscyclus van service
Of uw service nu stateful of stateless is, Reliable Services bieden een eenvoudige levenscyclus waarmee u snel uw code kunt aansluiten en aan de slag kunt gaan. Als u een nieuwe service wilt starten, 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, is wat het listening-eindpunt of de listening-eindpunten voor de service definieert (hoe clients de service bereiken). Het definieert ook hoe de berichten die worden weergegeven, communiceren met de rest van de servicecode.
- RunAsync : met deze methode wordt de bedrijfslogica van uw service uitgevoerd en worden achtergrondtaken 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 verwerken, is dit waar dat werk gebeurt.
Als u voor het eerst meer wilt weten over betrouwbare services, lees dan verder. Als u op zoek bent naar een gedetailleerd overzicht van de levenscyclus van betrouwbare services, raadpleegt u Het overzicht van de levenscyclus van Reliable Services.
Voorbeeldservices
Laten we eens kijken hoe het Reliable Services-model werkt met zowel stateless als stateful services.
Stateless Reliable Services
Een stateless service is een service waarbij er geen status wordt onderhouden binnen de service voor alle aanroepen. Elke status die aanwezig is, is volledig beschikbaar en vereist geen synchronisatie, replicatie, persistentie of hoge beschikbaarheid.
Denk bijvoorbeeld aan een rekenmachine die geen geheugen heeft en alle voorwaarden 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 hoeft uit te voeren. 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 wordt gekoppeld aan de verschillende berekeningsmethoden (bijvoorbeeld Add(n1, n2)) waarmee de openbare API van de rekenmachine wordt gedefinieerd.
Wanneer een aanroep wordt gedaan vanuit een client, 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 andere winkel. (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 stateless services worden gebruikt in Service Fabric is als een front-end die de openbare API beschikbaar maakt voor een webtoepassing. De front-endservice praat vervolgens met stateful services om een gebruikersaanvraag te voltooien. In dit geval worden aanroepen van clients omgeleid naar een bekende poort, zoals 80, waar de stateless service luistert. Deze stateless service ontvangt de aanroep en bepaalt of de aanroep afkomstig is van een vertrouwde partij en voor welke service deze is bestemd. Vervolgens stuurt de staatloze 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 Service Fabric Aan de slag-voorbeeld (C# / Java), naast andere Service Fabric-voorbeelden in die opslagplaats.
Stateful Reliable Services
Een stateful service is een service die een deel van de status consistent en aanwezig moet houden om de service te laten functioneren. Overweeg een service die voortdurend een voortschrijdend gemiddelde van een bepaalde waarde berekent op basis van updates die worden ontvangen. Hiervoor moet het de huidige set binnenkomende aanvragen hebben die moeten worden verwerkt en het huidige gemiddelde. Elke service die informatie ophaalt, verwerkt en opslaat in een externe opslag (zoals een Azure-blob of tabelarchief) is stateful. De status wordt alleen bewaard in het externe statusarchief.
De meeste services slaan hun status nu extern op, omdat de externe opslag zorgt voor betrouwbaarheid, beschikbaarheid, schaalbaarheid en consistentie voor die status. In Service Fabric hoeven services hun status niet 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. Om dit te doen, neemt de service een afbeelding en de reeks conversies op die afbeelding uit te voeren. Deze service retourneert een communicatielistener (stel dat het een WebAPI is) die een API beschikbaar maakt, zoals ConvertImage(Image i, IList<Conversion> conversions). Wanneer er een aanvraag wordt ontvangen, slaat de service deze op in een IReliableQueueen retourneert een id naar de client, zodat de aanvraag kan worden bijgehouden.
In deze service RunAsync() kan complexer zijn. De service heeft een lus binnen de service RunAsync() die aanvragen ophaalt IReliableQueue en de aangevraagde conversies uitvoert. De resultaten worden opgeslagen in een IReliableDictionary , zodat wanneer de client terugkomt, ze hun geconverteerde afbeeldingen kunnen ophalen. Om ervoor te zorgen dat zelfs als er iets mislukt, de installatiekopie niet verloren gaat, wordt deze Reliable Service uit de wachtrij gehaald, de conversies uitgevoerd en het resultaat in één transactie opgeslagen. 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 in beide gevallen iets is mislukt, blijft de aanvraag in de wachtrij staan om te worden verwerkt.
Hoewel deze service klinkt als 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 de status) 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 toepassing 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 runtime-omgeving met gratis threads nodig.
- Uw toepassing moet tijdens runtime dynamisch betrouwbare woordenlijsten of wachtrijen of volledige services maken of vernietigen.
- U moet programmatisch de door Service Fabric geleverde back-up- en herstelfuncties voor de status van uw service beheren.
- Uw toepassing moet de wijzigingsgeschiedenis voor de bijbehorende statuseenheden bijhouden.
- U wilt door derden ontwikkelde, aangepaste statusproviders ontwikkelen of gebruiken.