Dela via


Testbarhetsscenarier för Service Fabric: Tjänstkommunikation

Mikrotjänster och tjänstorienterade arkitekturformat visas naturligt i Azure Service Fabric. I dessa typer av distribuerade arkitekturer består komponentbaserade mikrotjänstprogram vanligtvis av flera tjänster som behöver prata med varandra. Även i de enklaste fallen har du i allmänhet minst en tillståndslös webbtjänst och en tillståndskänslig datalagringstjänst som behöver kommunicera.

Tjänst-till-tjänst-kommunikation är en kritisk integreringspunkt för ett program, eftersom varje tjänst exponerar ett fjärranslutet API för andra tjänster. Att arbeta med en uppsättning API-gränser som omfattar I/O kräver vanligtvis viss försiktighet, med en stor mängd testning och validering.

Det finns många saker att tänka på när dessa tjänstgränser kopplas samman i ett distribuerat system:

  • Transportprotokoll. Kommer du att använda HTTP för ökad samverkan eller ett anpassat binärt protokoll för maximalt dataflöde?
  • Felhantering. Hur kommer permanenta och tillfälliga fel att hanteras? Vad händer när en tjänst flyttas till en annan nod?
  • Tidsgränser och svarstider. Hur hanterar varje tjänstlager svarstid genom stacken och användaren i program med flera nivåer?

Oavsett om du använder någon av de inbyggda tjänstkommunikationskomponenterna som tillhandahålls av Service Fabric eller om du skapar din egen, är det viktigt att testa interaktionerna mellan dina tjänster för att säkerställa återhämtning i ditt program.

Förbered för att tjänster ska flyttas

Tjänstinstanser kan flyttas runt över tid. Detta gäller särskilt när de konfigureras med belastningsmått för anpassad optimal resursbalansering. Service Fabric flyttar dina tjänstinstanser för att maximera tillgängligheten även under uppgraderingar, redundansväxlingar, utskalning och andra situationer som inträffar under livslängden för ett distribuerat system.

När tjänsterna flyttas runt i klustret bör dina klienter och andra tjänster vara beredda att hantera två scenarier när de pratar med en tjänst:

  • Tjänstinstansen eller partitionsrepliken har flyttats sedan du senast pratade med den. Detta är en normal del av en tjänstlivscykel och det bör förväntas ske under programmets livslängd.
  • Tjänstinstansen eller partitionsrepliken håller på att flyttas. Även om redundansväxling av en tjänst från en nod till en annan sker mycket snabbt i Service Fabric, kan det uppstå en fördröjning i tillgängligheten om kommunikationskomponenten i tjänsten är långsam att starta.

Att hantera dessa scenarier på ett smidigt sätt är viktigt för ett smidigt system. Det gör du genom att tänka på att:

  • Varje tjänst som kan anslutas till har en adress som den lyssnar på (till exempel HTTP eller WebSockets). När en tjänstinstans eller partition flyttas ändras dess adressslutpunkt. (Den flyttas till en annan nod med en annan IP-adress.) Om du använder de inbyggda kommunikationskomponenterna hanterar de återlösande tjänstadresser åt dig.
  • Det kan uppstå en tillfällig ökning av tjänstfördröjningen när tjänstinstansen startar lyssnaren igen. Detta beror på hur snabbt tjänsten öppnar lyssnaren när tjänstinstansen har flyttats.
  • Alla befintliga anslutningar måste stängas och öppnas igen när tjänsten öppnas på en ny nod. En graciös nodavstängning eller omstart gör att befintliga anslutningar kan stängas av på ett korrekt sätt.

Testa det: Flytta tjänstinstanser

Genom att använda Service Fabrics testverktyg kan du skapa ett testscenario för att testa dessa situationer på olika sätt:

  1. Flytta en tillståndskänslig tjänsts primära replik.

    Den primära repliken av en tillståndskänslig tjänstpartition kan flyttas av valfritt antal orsaker. Använd detta för att rikta in dig på den primära repliken av en specifik partition för att se hur dina tjänster reagerar på flytten på ett mycket kontrollerat sätt.

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

    När en nod stoppas flyttar Service Fabric alla tjänstinstanser eller partitioner som fanns på noden till en av de andra tillgängliga noderna i klustret. Använd detta för att testa en situation där en nod går förlorad från klustret och alla tjänstinstanser och repliker på noden måste flyttas.

    Du kan stoppa en nod med hjälp av cmdleten PowerShell Stop-ServiceFabricNode :

    
    PS > Stop-ServiceFabricNode -NodeName Node_1
    
    

Underhålla tjänstens tillgänglighet

Som plattform är Service Fabric utformat för att tillhandahålla hög tillgänglighet för dina tjänster. Men i extrema fall kan underliggande infrastrukturproblem fortfarande orsaka otillgänglighet. Det är också viktigt att testa för dessa scenarier.

Tillståndskänsliga tjänster använder ett kvorumbaserat system för att replikera tillstånd för hög tillgänglighet. Det innebär att ett kvorum med repliker måste vara tillgängligt för att kunna utföra skrivåtgärder. I sällsynta fall, till exempel ett omfattande maskinvarufel, kanske inte ett kvorum med repliker är tillgängligt. I dessa fall kommer du inte att kunna utföra skrivåtgärder, men du kommer fortfarande att kunna utföra läsåtgärder.

Testa det: Skrivåtgärden är otillgänglig

Genom att använda testverktygen i Service Fabric kan du mata in ett fel som leder till kvorumförlust som ett test. Även om ett sådant scenario är sällsynt är det viktigt att klienter och tjänster som är beroende av en tillståndskänslig tjänst är beredda att hantera situationer där de inte kan göra skrivbegäranden till den. Det är också viktigt att den tillståndskänsliga tjänsten själv är medveten om den här möjligheten och kan kommunicera den med uppringare på ett smidigt sätt.

Du kan orsaka kvorumförlust med hjälp av cmdleten PowerShell Invoke-ServiceFabricPartitionQuorumLoss :


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

I det här exemplet anger QuorumLossMode vi att QuorumReplicas vi vill inducera kvorumförlust utan att ta bort alla repliker. På så sätt är läsåtgärder fortfarande möjliga. Om du vill testa ett scenario där en hel partition inte är tillgänglig kan du ange den här växeln till AllReplicas.

Nästa steg

Läs mer om testbarhetsåtgärder

Läs mer om testbarhetsscenarier