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.
  • Sommige scenario's en voorbeelden van het gebruik van Reliable Services en hoe ze worden geschreven.

Reliable Services is een van de programmeermodellen die beschikbaar zijn op 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 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 rechtstreeks Service Fabric API's gebruiken. Hiermee 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 vele andere mogelijkheden, allemaal vanuit een eersteklas programmeermodel in verschillende programmeertalen.
  • Een eenvoudig model voor het uitvoeren van uw eigen code die lijkt op andere vertrouwde 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 vertrouwd zijn met iedereen die C#-verzamelingen heeft gebruikt. Traditioneel hadden services externe systemen nodig voor Reliable State Management. Met Reliable Collections kunt u uw status naast uw rekenproces opslaan met dezelfde hoge beschikbaarheid en betrouwbaarheid die u kunt verwachten van maximaal beschikbare externe winkels. Dit model verbetert ook de latentie omdat u de rekenkracht en de status die het nodig heeft om te functioneren, samen zoekt.

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 computers 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 de aanwezigheid van netwerkfouten of andere fouten.
  • Beschikbaarheid : uw service is bereikbaar en responsief. Service Fabric onderhoudt het gewenste aantal actieve exemplaren.
  • Schaalbaarheid : services worden losgekoppeld van specifieke hardware en ze kunnen naar behoefte groeien of verkleinen door het toevoegen of verwijderen van hardware of andere resources. Services zijn eenvoudig gepartitioneerd (met name in het stateful geval) om ervoor te zorgen dat de service gedeeltelijke fouten kan schalen en afhandelen. Services kunnen dynamisch worden gemaakt en verwijderd via code, zodat er zo nodig meer exemplaren kunnen worden gemaakt, bijvoorbeeld als reactie op klantaanvragen. Tot slot moedigt Service Fabric diensten aan om lichtgewicht te zijn. Service Fabric staat toe dat duizenden services binnen één proces worden ingericht, in plaats van volledige exemplaren of processen van het besturingssysteem te vereisen of toe te wijzen aan één exemplaar van een service.
  • Consistentie : alle 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.

Bekijk deze pagina voor een trainingsvideo voor meer informatie over het Service Fabric reliable services-programmeermodel en hoe uw toepassing met dit .NET-programmeermodel nauwer kan worden geïntegreerd met de Service Fabric runtime:

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. Als u een nieuwe service aan de slag wilt, 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 listening-eindpunt 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 : met deze methode wordt de bedrijfslogica van uw service uitgevoerd 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 deze 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 zowel stateless als 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 listening-eindpunt wordt gekoppeld 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 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 een front-end die de openbare API voor een webtoepassing beschikbaar maakt. De front-endservice praat vervolgens met stateful services om een gebruikersaanvraag te voltooien. In dit geval worden aanroepen van clients doorgestuurd naar een bekende poort, zoals 80, waar de staatloze service luistert. Deze staatloze service ontvangt de oproep en bepaalt of de oproep afkomstig is van een vertrouwde partij en voor welke service deze bestemd is. Vervolgens stuurt de stateless service de aanroep door naar de juiste partitie van de stateful service en wacht op een antwoord. Wanneer de staatloze 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), 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 het externe archief de betrouwbaarheid, beschikbaarheid, schaalbaarheid en consistentie voor die status biedt. 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. Hiervoor neemt de service een afbeelding en de reeks conversies in beslag die op die afbeelding moeten worden uitgevoerd. Deze service retourneert een communicatielistener (stel dat het een WebAPI is) waarmee een API wordt weergegeven, zoals ConvertImage(Image i, IList<Conversion> conversions). Wanneer 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 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, ze hun geconverteerde afbeeldingen 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 allemaal in één transactie opslaat. In dit geval wordt het bericht verwijderd uit de wachtrij 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 winkel. 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 is mislukt in het midden, blijft de aanvraag in de wachtrij wachten om te worden verwerkt.

Hoewel deze service lijkt op een typische .NET-service, is het verschil dat de gegevensstructuren die worden gebruikt (IReliableQueueen 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 eventueel 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 natuurlijk 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 transacted bewerkingen in een of meer betrouwbare verzamelingen beheren.
  • U wilt de communicatie beheren of het partitioneringsschema voor uw service beheren.
  • Uw code heeft een gratis runtime-omgeving nodig.
  • Uw toepassing moet in runtime betrouwbare woordenlijsten of wachtrijen of volledige services dynamisch maken of vernietigen.
  • U moet programmatisch bepalen Service Fabric functies voor back-up en herstel voor de status van uw service.
  • Uw toepassing moet de wijzigingsgeschiedenis voor de statuseenheden bijhouden.
  • U wilt externe, aangepaste statusproviders ontwikkelen of gebruiken.

Volgende stappen