Scénáře testovatelnosti Service Fabric: Komunikace služby
Mikroslužby a styly architektury orientované na služby se přirozeně v Azure Service Fabric vyskytnou. V těchto typech distribuovaných architektur se komponentizované aplikace mikroslužeb obvykle skládají z několika služeb, které si navzájem potřebují promluvit. V nejjednodušších případech obvykle máte alespoň bezstavovou webovou službu a stavovou službu úložiště dat, která potřebuje komunikovat.
Komunikace mezi službami je kritickým bodem integrace aplikace, protože každá služba zveřejňuje vzdálené rozhraní API pro jiné služby. Práce se sadou hranic rozhraní API, která zahrnuje vstupně-výstupní operace, obecně vyžaduje určitou péči s dobrým množstvím testování a ověřování.
Při propojení těchto hranic služeb v distribuovaném systému je potřeba vzít v úvahu celou řadu aspektů:
- Přenosový protokol. Použijete protokol HTTP pro větší interoperabilitu nebo vlastní binární protokol pro maximální propustnost?
- Zpracování chyb Jak se budou zpracovávat trvalé a přechodné chyby? Co se stane, když se služba přesune na jiný uzel?
- Časové limity a latence Jak bude každá vrstva služby zpracovávat latenci prostřednictvím zásobníku a uživatele v aplikacích s více vrstvami?
Bez ohledu na to, jestli používáte některou z předdefinovaných komponent komunikace služeb poskytovaných Service Fabric nebo vytváříte vlastní, je testování interakcí mezi službami zásadní pro zajištění odolnosti ve vaší aplikaci.
Příprava na přesun služeb
Instance služby se můžou v průběhu času pohybovat. To platí zejména v případě, že jsou nakonfigurované s metrikami zatížení pro vlastní optimální vyrovnávání prostředků na míru. Service Fabric přesune instance služeb, aby se maximalizovala jejich dostupnost i během upgradů, převzetí služeb při selhání, horizontálního navýšení kapacity a dalších situací, ke kterým dochází v průběhu životnosti distribuovaného systému.
Když se služby pohybují v clusteru, měli by být vaši klienti a další služby připravení zpracovat dva scénáře při komunikaci se službou:
- Instance služby nebo replika oddílu se přesunula od poslední doby, kdy jste s ní mluvili. Jedná se o běžnou součást životního cyklu služby a mělo by se očekávat, že během životnosti aplikace dojde.
- Instance služby nebo replika oddílu se právě přesouvá. Přestože převzetí služeb při selhání služby z jednoho uzlu do druhého probíhá v Service Fabric velmi rychle, může dojít ke zpoždění dostupnosti, pokud je komunikační komponenta vaší služby pomalá.
Řádné zpracování těchto scénářů je důležité pro bezproblémový systém. Mějte na paměti, že:
- Každá služba, ke které je možné připojit, má adresu , na které naslouchá (například HTTP nebo WebSockets). Když se instance služby nebo oddíl přesunou, změní se koncový bod adresy. (Přesune se na jiný uzel s jinou IP adresou.) Pokud používáte předdefinované komunikační komponenty, budou za vás zpracovávat adresy služeb opětovného překladu.
- Může dojít k dočasnému zvýšení latence služby, protože instance služby znovu spustí naslouchací proces. To závisí na tom, jak rychle služba otevře naslouchací proces po přesunutí instance služby.
- Po otevření služby na novém uzlu je potřeba zavřít a znovu otevřít všechna existující připojení. Řádné vypnutí nebo restartování uzlu umožňuje řádné vypnutí stávajících připojení.
Test: Přesun instancí služby
Pomocí nástrojů pro testovatelnost Service Fabric můžete vytvořit testovací scénář, který tyto situace otestuje různými způsoby:
Přesunutí primární repliky stavové služby
Primární repliku oddílu stavové služby je možné přesunout z libovolného počtu důvodů. Pomocí tohoto postupu můžete cílit na primární repliku konkrétního oddílu, abyste viděli, jak vaše služby reagují na přesun velmi řízeným způsobem.
PS > Move-ServiceFabricPrimaryReplica -PartitionId 6faa4ffa-521a-44e9-8351-dfca0f7e0466 -ServiceName fabric:/MyApplication/MyServiceZastavte uzel.
Když je uzel zastavený, Service Fabric přesune všechny instance služby nebo oddíly, které byly na daném uzlu, do jednoho z dalších dostupných uzlů v clusteru. Použijte to k otestování situace, kdy dojde ke ztrátě uzlu z clusteru a všech instancí služby a replik na tomto uzlu, které se musí přesunout.
Uzel můžete zastavit pomocí rutiny PowerShell Stop-ServiceFabricNode :
PS > Stop-ServiceFabricNode -NodeName Node_1
Zachování dostupnosti služeb
Jako platforma je Service Fabric navržená tak, aby poskytovala vysokou dostupnost vašich služeb. V extrémních případech ale problémy se základní infrastrukturou můžou způsobit nedostupnost. Pro tyto scénáře je také důležité testovat.
Stavové služby používají systém založený na kvoru k replikaci stavu pro zajištění vysoké dostupnosti. To znamená, že kvorum replik musí být k dispozici pro provádění operací zápisu. Ve výjimečných případech, například při rozsáhlém selhání hardwaru, nemusí být kvorum replik k dispozici. V těchto případech nebudete moct provádět operace zápisu, ale přesto budete moct provádět operace čtení.
Otestovat: Nedostupnost operace zápisu
Pomocí nástrojů testovatelnosti v Service Fabric můžete vložit chybu, která vyvolá ztrátu kvora jako test. I když je takový scénář vzácný, je důležité, aby klienti a služby, které jsou závislé na stavové službě, připravily na zpracování situací, kdy nemůžou zapsat požadavky. Je také důležité, aby stavová služba sama o této možnosti věděla a může ji elegantně komunikovat s volajícími.
Ztrátu kvora můžete vyvolat pomocí rutiny PowerShell Invoke-ServiceFabricPartitionQuorumLoss :
PS > Invoke-ServiceFabricPartitionQuorumLoss -ServiceName fabric:/Myapplication/MyService -QuorumLossMode QuorumReplicas -QuorumLossDurationInSeconds 20
V tomto příkladu jsme nastavili QuorumLossMode QuorumReplicas , že chceme vyvolat ztrátu kvora, aniž bychom odebrali všechny repliky. Díky tomu jsou operace čtení stále možné. Pokud chcete otestovat scénář, ve kterém není k dispozici celý oddíl, můžete tento přepínač nastavit na AllReplicas.