Scenariusze testowania usługi Service Fabric: Komunikacja z usługą
Mikrousługi i style architektury zorientowane na usługi są naturalnie powierzchnią w usłudze Azure Service Fabric. W tych typach architektur rozproszonych aplikacje mikrousług składają się zazwyczaj z wielu usług, które muszą komunikować się ze sobą. Nawet w najprostszych przypadkach masz co najmniej bezstanową usługę internetową i stanową usługę magazynu danych, która musi się komunikować.
Komunikacja między usługami jest krytycznym punktem integracji aplikacji, ponieważ każda usługa uwidacznia zdalny interfejs API innym usługom. Praca z zestawem granic interfejsu API, który obejmuje we/wy, zwykle wymaga pewnej staranności, przy dużej liczbie testów i walidacji.
Istnieje wiele kwestii, które należy wziąć pod uwagę, gdy te granice usług są połączone w systemie rozproszonym:
- Protokół transportowy. Czy będziesz używać protokołu HTTP do zwiększenia współdziałania, czy niestandardowego protokołu binarnego dla maksymalnej przepływności?
- Obsługa błędów. Jak będą obsługiwane trwałe i przejściowe błędy? Co się stanie, gdy usługa zostanie przeniesiona do innego węzła?
- Limity czasu i opóźnienia. W aplikacjach wielowarstwowych w jaki sposób każda warstwa usługi będzie obsługiwać opóźnienie za pośrednictwem stosu i użytkownika?
Niezależnie od tego, czy używasz jednego z wbudowanych składników komunikacji usług udostępnianych przez usługę Service Fabric, czy tworzysz własne, testowanie interakcji między usługami ma kluczowe znaczenie dla zapewnienia odporności w aplikacji.
Przygotowanie do przenoszenia usług
Wystąpienia usług mogą się poruszać w czasie. Jest to szczególnie istotne w przypadku skonfigurowania ich z metrykami obciążenia na potrzeby niestandardowego optymalnego równoważenia zasobów. Usługa Service Fabric przenosi wystąpienia usługi, aby zmaksymalizować ich dostępność nawet podczas uaktualniania, trybu failover, skalowania w poziomie i innych sytuacji, które występują w okresie istnienia systemu rozproszonego.
W miarę poruszania się usług w klastrze klienci i inne usługi powinni być przygotowani do obsługi dwóch scenariuszy podczas rozmowy z usługą:
- Wystąpienie usługi lub replika partycji zostały przeniesione od czasu ostatniej rozmowy z nim. Jest to normalna część cyklu życia usługi i powinna być oczekiwana w okresie istnienia aplikacji.
- Wystąpienie usługi lub replika partycji jest w trakcie przenoszenia. Mimo że tryb failover usługi z jednego węzła do drugiego występuje bardzo szybko w usłudze Service Fabric, może wystąpić opóźnienie dostępności, jeśli składnik komunikacji usługi jest powolny.
Obsługa tych scenariuszy z pewnością jest ważna dla bezproblemowego systemu. W tym celu należy pamiętać, że:
- Każda usługa, z którą można nawiązać połączenie, ma adres , na który nasłuchuje (na przykład HTTP lub WebSockets). Gdy wystąpienie usługi lub partycja zostanie przeniesione, jego punkt końcowy adresu zmieni się. (Przechodzi do innego węzła z innym adresem IP). Jeśli używasz wbudowanych składników komunikacji, będą one obsługiwać ponowne rozpoznawanie adresów usług.
- Może wystąpić tymczasowy wzrost opóźnienia usługi, ponieważ wystąpienie usługi ponownie uruchamia odbiornik. Zależy to od tego, jak szybko usługa otwiera odbiornik po przeniesieniu wystąpienia usługi.
- Wszystkie istniejące połączenia muszą zostać zamknięte i ponownie otwarte po otwarciu usługi w nowym węźle. Bezproblemowe zamykanie lub ponowne uruchamianie węzła umożliwia bezproblemowe zamknięcie istniejących połączeń.
Testowanie: przenoszenie wystąpień usługi
Korzystając z narzędzi do testowania usługi Service Fabric, możesz utworzyć scenariusz testowy, aby przetestować te sytuacje na różne sposoby:
Przenoszenie repliki podstawowej usługi stanowej.
Replika podstawowa partycji usługi stanowej może zostać przeniesiona z dowolnej liczby powodów. Służy do kierowania repliki podstawowej określonej partycji, aby zobaczyć, jak usługi reagują na ruch w bardzo kontrolowany sposób.
PS > Move-ServiceFabricPrimaryReplica -PartitionId 6faa4ffa-521a-44e9-8351-dfca0f7e0466 -ServiceName fabric:/MyApplication/MyServiceZatrzymaj węzeł.
Po zatrzymaniu węzła usługa Service Fabric przenosi wszystkie wystąpienia usługi lub partycje, które znajdowały się w tym węźle do jednego z pozostałych dostępnych węzłów w klastrze. Służy do testowania sytuacji, w której węzeł zostanie utracony z klastra, a wszystkie wystąpienia usługi i repliki w tym węźle muszą być przenoszone.
Węzeł można zatrzymać za pomocą polecenia cmdlet Stop-ServiceFabricNode programu PowerShell:
PS > Stop-ServiceFabricNode -NodeName Node_1
Obsługa dostępności usługi
Jako platforma usługa Service Fabric została zaprojektowana w celu zapewnienia wysokiej dostępności usług. Jednak w skrajnych przypadkach podstawowe problemy z infrastrukturą mogą nadal powodować niedostępność. Ważne jest również przetestowanie tych scenariuszy.
Usługi stanowe używają systemu opartego na kworum do replikowania stanu w celu zapewnienia wysokiej dostępności. Oznacza to, że kworum replik musi być dostępne do wykonywania operacji zapisu. W rzadkich przypadkach, takich jak powszechna awaria sprzętowa, kworum replik może być niedostępne. W takich przypadkach nie będzie można wykonywać operacji zapisu, ale nadal będzie można wykonywać operacje odczytu.
Przetestuj ją: niedostępność operacji zapisu
Korzystając z narzędzi do testowania w usłudze Service Fabric, można wstrzyknąć błąd, który powoduje utratę kworum jako test. Chociaż taki scenariusz jest rzadki, ważne jest, aby klienci i usługi, które zależą od usługi stanowej, były przygotowane do obsługi sytuacji, w których nie mogą wysyłać do niego żądań zapisu. Ważne jest również, aby sama usługa stanowa była świadoma tej możliwości i może bezpiecznie komunikować się z osobami wywołującymi.
Możesz wywołać utratę kworum za pomocą polecenia cmdlet Invoke-ServiceFabricPartitionQuorumLoss programu PowerShell:
PS > Invoke-ServiceFabricPartitionQuorumLoss -ServiceName fabric:/Myapplication/MyService -QuorumLossMode QuorumReplicas -QuorumLossDurationInSeconds 20
W tym przykładzie ustawiliśmy wartość QuorumLossModeQuorumReplicas , aby wskazać, że chcemy wywołać utratę kworum bez wyłączania wszystkich replik. W ten sposób operacje odczytu są nadal możliwe. Aby przetestować scenariusz, w którym cała partycja jest niedostępna, możesz ustawić ten przełącznik na AllReplicas.