Testbaarheidsscenario's voor Service Fabric: Servicecommunicatie
Microservices en servicegeoriënteerde architectuurstijlen komen natuurlijk voor in Azure Service Fabric. In deze typen gedistribueerde architecturen bestaan gecomponentiseerde microservicetoepassingen doorgaans uit meerdere services die met elkaar moeten communiceren. In zelfs de eenvoudigste gevallen hebt u over het algemeen ten minste een staatloze webservice en een stateful gegevensopslagservice die moet communiceren.
Service-naar-service-communicatie is een kritiek integratiepunt van een toepassing, omdat elke service een externe API beschikbaar maakt voor andere services. Voor het werken met een set API-grenzen waarbij I/O betrokken is, is over het algemeen enige zorg vereist, met een goede hoeveelheid testen en validatie.
Er zijn talloze overwegingen die u moet maken wanneer deze servicegrenzen samen in een gedistribueerd systeem worden bekabeld:
- Transportprotocol. Gebruikt u HTTP voor verbeterde interoperabiliteit of een aangepast binair protocol voor maximale doorvoer?
- Foutafhandeling. Hoe worden permanente en tijdelijke fouten afgehandeld? 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 de gebruiker in toepassingen met meerdere lagen?
Of u nu een van de ingebouwde servicecommunicatieonderdelen van Service Fabric gebruikt of zelf bouwt, het testen van de interacties tussen uw services is essentieel om tolerantie in uw toepassing te garanderen.
Voorbereiden op verplaatsen van services
Service-exemplaren kunnen zich in de loop van de tijd verplaatsen. Dit geldt met name wanneer ze zijn geconfigureerd met metrische gegevens over belasting voor 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 gedurende de levensduur van een gedistribueerd systeem.
Naarmate services zich in het cluster verplaatsen, moeten uw clients en andere services voorbereid zijn op het afhandelen van twee scenario's wanneer ze met een service praten:
- Het service-exemplaar of de partitiereplica is verplaatst sinds de laatste keer dat u met het exemplaar hebt gepraat. Dit is een normaal onderdeel van de levenscyclus van een service en dit moet worden verwacht tijdens de levensduur van uw toepassing.
- Het service-exemplaar of de partitiereplica wordt verplaatst. Hoewel een failover van een service van het ene knooppunt naar het andere zeer snel optreedt in Service Fabric, kan er een vertraging in de beschikbaarheid optreden als het communicatieonderdeel van uw service traag wordt gestart.
Het probleemloos verwerken van deze scenario's is belangrijk voor een soepel lopend systeem. Als u dit wilt doen, moet u rekening houden met het volgende:
- Elke service waarmee verbinding kan worden gemaakt, heeft een adres waarop wordt geluisterd (bijvoorbeeld HTTP of WebSockets). Wanneer een service-exemplaar of partitie wordt verplaatst, wordt het adreseindpunt gewijzigd. (Het wordt verplaatst naar een ander knooppunt met een ander IP-adres.) Als u de ingebouwde communicatieonderdelen gebruikt, verwerken ze het opnieuw omzetten van serviceadressen voor u.
- Er kan een tijdelijke toename van de servicelatentie optreden wanneer het service-exemplaar de listener opnieuw start. Dit is afhankelijk van hoe snel de service de listener opent nadat het service-exemplaar is verplaatst.
- Eventuele bestaande verbindingen moeten worden gesloten en opnieuw worden geopend nadat de service op een nieuw knooppunt is geopend. Door een probleemloos knooppunt af te sluiten of opnieuw op te starten, kunnen bestaande verbindingen probleemloos worden afgesloten.
Testen: Service-exemplaren verplaatsen
Met behulp van de testbaarheidshulpprogramma's van Service Fabric kunt u een testscenario maken om deze situaties op verschillende manieren te testen:
Verplaats de primaire replica van een stateful service.
De primaire replica van een stateful servicepartitie kan om verschillende redenen worden verplaatst. Gebruik dit om de primaire replica van een specifieke partitie te richten om te zien hoe uw services reageren op de verplaatsing op een zeer gecontroleerde manier.
PS > Move-ServiceFabricPrimaryReplica -PartitionId 6faa4ffa-521a-44e9-8351-dfca0f7e0466 -ServiceName fabric:/MyApplication/MyServiceStop een knooppunt.
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 deze optie om een situatie te testen waarin een knooppunt uit uw cluster verloren gaat en alle service-exemplaren en replica's op dat knooppunt moeten worden verplaatst.
U kunt een knooppunt stoppen met behulp van de PowerShell Stop-ServiceFabricNode-cmdlet :
PS > Stop-ServiceFabricNode -NodeName Node_1
De beschikbaarheid van de 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 onbeschikbaarheid veroorzaken. Het is ook belangrijk om te testen op deze scenario's.
Stateful services maken gebruik van een quorumsysteem om de status voor hoge beschikbaarheid te repliceren. Dit betekent dat een quorum van replica's beschikbaar moet zijn om schrijfbewerkingen uit te voeren. In zeldzame gevallen, zoals een wijdverspreide hardwarefout, is een quorum met replica's mogelijk niet beschikbaar. In deze gevallen kunt u geen schrijfbewerkingen uitvoeren, maar kunt u wel leesbewerkingen uitvoeren.
Testen: schrijfbewerking is niet beschikbaar
Met behulp van de testbaarheidshulpprogramma's in Service Fabric kunt u een fout invoeren die quorumverlies veroorzaakt als test. Hoewel een dergelijk scenario zeldzaam is, is het belangrijk dat clients en services die afhankelijk zijn van een stateful service, voorbereid zijn op het afhandelen van situaties waarin ze geen schrijfaanvragen kunnen indienen. Het is ook belangrijk dat de stateful service zelf op de hoogte is van deze mogelijkheid en deze correct kan communiceren met bellers.
U kunt quorumverlies veroorzaken met behulp van de cmdlet PowerShell Invoke-ServiceFabricPartitionQuorumLoss :
PS > Invoke-ServiceFabricPartitionQuorumLoss -ServiceName fabric:/Myapplication/MyService -QuorumLossMode QuorumReplicas -QuorumLossDurationInSeconds 20
In dit voorbeeld hebben we ingesteld QuorumLossMode om QuorumReplicas aan te geven dat we quorumverlies willen veroorzaken zonder alle replica's te verwijderen. Op deze manier zijn leesbewerkingen nog steeds mogelijk. Als u een scenario wilt testen waarin een volledige partitie niet beschikbaar is, kunt u deze switch instellen op AllReplicas.