Testbaarheidsscenario's van Service Fabric: Servicecommunicatie

Microservices en servicegeoriënteerde architectuurstijlen komen op natuurlijke wijze voor in Azure Service Fabric. In dit soort gedistribueerde architecturen bestaan microservicetoepassingen met onderdelen doorgaans uit meerdere services die met elkaar moeten communiceren. Zelfs in de eenvoudigste gevallen hebt u over het algemeen ten minste een staatloze webservice en een stateful gegevensopslagservice die moeten communiceren.

Service-naar-service-communicatie is een kritiek integratiepunt van een toepassing, omdat elke service een externe API beschikbaar maakt voor andere services. Het werken met een set API-grenzen waarbij I/O betrokken is, vereist over het algemeen enige zorg, met een goede hoeveelheid testen en validatie.

Er zijn talloze overwegingen die u moet maken wanneer deze servicegrenzen met elkaar zijn verbonden in een gedistribueerd systeem:

• Transportprotocol. Gebruikt u HTTP voor verbeterde interoperabiliteit of een aangepast binair protocol voor maximale doorvoer?
• Foutafhandeling. Hoe worden permanente en tijdelijke fouten verwerkt? Wat gebeurt er wanneer een service naar een ander knooppunt wordt verplaatst?
• Time-outs en latentie. Hoe verwerkt elke servicelaag latentie via de stack en naar de gebruiker in toepassingen met meerdere lagen?

Of u nu een van de ingebouwde servicecommunicatieonderdelen van Service Fabric gebruikt of uw eigen onderdelen bouwt, het testen van de interacties tussen uw services is essentieel om tolerantie in uw toepassing te garanderen.

Voorbereiden op het verplaatsen van services

Service-exemplaren kunnen in de loop van de tijd worden verplaatst. Dit geldt met name wanneer ze zijn geconfigureerd met metrische belastinggegevens voor aangepaste, op maat gemaakte optimale resourceverdeling. Service Fabric verplaatst uw service-exemplaren om hun beschikbaarheid te maximaliseren, zelfs tijdens upgrades, failovers, uitschalen en andere situaties die zich voordoen tijdens de levensduur van een gedistribueerd systeem.

Naarmate services in het cluster worden verplaatst, moeten uw clients en andere services zijn voorbereid op het afhandelen van twee scenario's wanneer ze met een service communiceren:

• Het service-exemplaar of de partitiereplica is verplaatst sinds u er de laatste keer mee hebt gepraat. Dit is een normaal onderdeel van een servicelevenscyclus en het moet gebeuren tijdens de levensduur van uw toepassing.
• Het service-exemplaar of de partitiereplica wordt verplaatst. Hoewel failover van een service van het ene knooppunt naar het andere zeer snel optreedt in Service Fabric, kan er een vertraging optreden in de beschikbaarheid als het communicatieonderdeel van uw service traag wordt gestart.

Het afhandelen van deze scenario's is belangrijk voor een soepel werkend systeem. Houd hiervoor rekening met het volgende:

• Elke service waarmee verbinding kan worden gemaakt, heeft een adres waarnaar wordt geluisterd (bijvoorbeeld HTTP of WebSockets). Wanneer een service-exemplaar of partitie wordt verplaatst, verandert het adreseindpunt. (Deze wordt verplaatst naar een ander knooppunt met een ander IP-adres.) Als u de ingebouwde communicatieonderdelen gebruikt, verwerken deze het opnieuw omzetten van serviceadressen voor u.
• Er kan een tijdelijke toename in servicelatentie optreden als de listener van het service-exemplaar opnieuw wordt gestart. Dit is afhankelijk van hoe snel de service de listener opent nadat het service-exemplaar is verplaatst.
• Bestaande verbindingen moeten worden gesloten en opnieuw worden geopend nadat de service op een nieuw knooppunt is geopend. Als het knooppunt probleemloos wordt afgesloten of opnieuw wordt opgestart, kunnen bestaande verbindingen correct worden afgesloten.

Test het: service-exemplaren verplaatsen

Met behulp van de hulpprogramma's voor testbaarheid van Service Fabric kunt u een testscenario maken om deze situaties op verschillende manieren te testen:

1. De primaire replica van een stateful service verplaatsen.

   De primaire replica van een stateful servicepartitie kan om verschillende redenen worden verplaatst. Gebruik dit om de primaire replica van een specifieke partitie te gebruiken om te zien hoe uw services op een zeer gecontroleerde manier op de verplaatsing reageren.

   
   PS > Move-ServiceFabricPrimaryReplica -PartitionId 6faa4ffa-521a-44e9-8351-dfca0f7e0466 -ServiceName fabric:/MyApplication/MyService
   
   

2. Een knooppunt stoppen.

   Wanneer een knooppunt wordt gestopt, verplaatst Service Fabric alle service-exemplaren of partities die zich op dat knooppunt bevinden naar een van de andere beschikbare knooppunten in het cluster. Gebruik dit om een situatie te testen waarin een knooppunt verloren gaat in uw cluster en alle service-exemplaren en replica's op dat knooppunt moeten worden verplaatst.

   U kunt een knooppunt stoppen met behulp van de PowerShell-cmdlet Stop-ServiceFabricNode :

   
   PS > Stop-ServiceFabricNode -NodeName Node_1
   
   

Beschikbaarheid van service behouden

Als platform is Service Fabric ontworpen om hoge beschikbaarheid van uw services te bieden. Maar in extreme gevallen kunnen onderliggende infrastructuurproblemen nog steeds leiden tot onbeschikbaarheid. Het is ook belangrijk om deze scenario's te testen.

Stateful services maken gebruik van een quorumsysteem om de status te repliceren voor hoge beschikbaarheid. Dit betekent dat er een quorum van replica's beschikbaar moet zijn om schrijfbewerkingen uit te voeren. In zeldzame gevallen, zoals een wijdverbreide hardwarestoring, is een quorum van replica's mogelijk niet beschikbaar. In dergelijke gevallen kunt u geen schrijfbewerkingen uitvoeren, maar wel leesbewerkingen uitvoeren.

Test het: schrijfbewerking is niet beschikbaar

Met behulp van de testbaarheidshulpprogramma's in Service Fabric kunt u een fout injecteren die quorumverlies veroorzaakt als een test. Hoewel een dergelijk scenario zeldzaam is, is het belangrijk dat clients en services die afhankelijk zijn van een stateful service, voorbereid zijn op situaties waarin ze geen schrijfaanvragen naar de service kunnen indienen. Het is ook belangrijk dat de stateful service zelf op de hoogte is van deze mogelijkheid en dit probleemloos kan doorgeven aan bellers.

U kunt quorumverlies veroorzaken met behulp van de PowerShell Invoke-ServiceFabricPartitionQuorumLoss-cmdlet :

PS > Invoke-ServiceFabricPartitionQuorumLoss -ServiceName fabric:/Myapplication/MyService -QuorumLossMode QuorumReplicas -QuorumLossDurationInSeconds 20

In dit voorbeeld stellen QuorumLossMode we in op QuorumReplicas om aan te geven dat we quorumverlies willen veroorzaken zonder alle replica's uit te schakelen. Op deze manier zijn leesbewerkingen nog steeds mogelijk. Als u een scenario wilt testen waarin een volledige partitie niet beschikbaar is, kunt u deze schakeloptie instellen op AllReplicas.

Volgende stappen

Meer informatie over testbaarheidsacties

Meer informatie over testbaarheidsscenario's