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 przypadku tych typów architektur rozproszonych aplikacje mikrousług składowych zwykle składają się z wielu usług, które muszą komunikować się ze sobą. Nawet w najprostszych przypadkach masz co najmniej bezstanową usługę internetową i usługę magazynu danych stanowych, która musi komunikować się.
Komunikacja między usługami to krytyczny punkt integracji aplikacji, ponieważ każda usługa uwidacznia zdalny interfejs API innym usługom. Praca z zestawem granic interfejsu API, które obejmują we/wy, zwykle wymaga pewnej ostrożności, przy dużej liczbie testów i walidacji.
Istnieje wiele kwestii, które należy wziąć pod uwagę, gdy te granice usługi są połączone w systemie rozproszonym:
- Protokół transportowy. Czy używasz protokołu HTTP do zwiększenia współdziałania, czy niestandardowego protokołu binarnego w celu uzyskania 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óźnienia za pośrednictwem stosu i dla 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 przeniesienia usług
Wystąpienia usługi 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 występujących w okresie istnienia systemu rozproszonego.
W miarę przemieszczania się usług w klastrze klienci i inne usługi powinny być przygotowane 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 będzie powolny.
Obsługa tych scenariuszy z pewnością jest ważna w przypadku 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 zamykanie 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:
Przenieś replikę podstawową usługi stanowej.
Replika podstawowa partycji usługi stanowej może zostać przeniesiona z dowolnej liczby powodów. Służy do określania lokalizacji docelowej 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. Użyj tej funkcji, aby przetestować sytuację, 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 wywołuje 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 przy użyciu polecenia cmdlet Invoke-ServiceFabricPartitionQuorumLoss programu PowerShell:
PS > Invoke-ServiceFabricPartitionQuorumLoss -ServiceName fabric:/Myapplication/MyService -QuorumLossMode QuorumReplicas -QuorumLossDurationInSeconds 20
W tym przykładzie ustawiliśmy wartość QuorumLossMode , aby QuorumReplicas 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.