Udostępnij za pośrednictwem

Konfigurowanie i używanie koligacji usługi w usłudze Service Fabric

  • Artykuł

Koligacja to mechanizm kontroli, który jest dostarczany głównie w celu ułatwienia przejścia większych aplikacji monolitycznych do świata chmury i mikrousług. Jest on również używany jako optymalizacja pod kątem poprawy wydajności usług, chociaż może to mieć skutki uboczne.

Załóżmy, że wprowadzasz większą aplikację lub aplikację, która po prostu nie została zaprojektowana z myślą o mikrousługach, do usługi Service Fabric (lub żadnego środowiska rozproszonego). Ten typ przejścia jest typowy. Zacznij od podniesienia całej aplikacji do środowiska, spakowania jej i upewnienia się, że działa płynnie. Następnie zaczniesz podzielić go na różne mniejsze usługi, które wszystkie komunikują się ze sobą.

W końcu może się okazać, że w aplikacji występują pewne problemy. Problemy zwykle należą do jednej z następujących kategorii:

  1. Niektóre składniki X w aplikacji monolitycznej miały nieudokumentowaną zależność od składnika Y i właśnie zamieniono te składniki w oddzielne usługi. Ponieważ te usługi są teraz uruchomione w różnych węzłach w klastrze, są one uszkodzone.
  2. Te składniki komunikują się za pośrednictwem (lokalne nazwane potoki | pamięć współdzielona | pliki na dysku) i naprawdę muszą być w stanie zapisywać w udostępnionym zasobie lokalnym ze względów wydajności w tej chwili. Ta twarda zależność zostanie usunięta później, być może.
  3. Wszystko jest w porządku, ale okazuje się, że te dwa składniki są rzeczywiście wrażliwe na rozmowy/wydajność. Po przeniesieniu ich do oddzielnych usług ogólna wydajność aplikacji wzrosła lub opóźnienie. W związku z tym ogólna aplikacja nie spełnia oczekiwań.

W takich przypadkach nie chcemy tracić naszej pracy refaktoryzacji i nie chcemy wracać do monolitu. Ostatni warunek może być nawet pożądany jako zwykła optymalizacja. Jednak dopóki nie będziemy mogli przeprojektować składników, aby działały naturalnie jako usługi (lub dopóki nie będziemy w stanie rozwiązać oczekiwań dotyczących wydajności w inny sposób), będziemy potrzebować pewnego poczucia lokalności.

Postępowanie Cóż, możesz spróbować włączyć koligację.

Jak skonfigurować koligację

Aby skonfigurować koligację, należy zdefiniować relację koligacji między dwoma różnymi usługami. Koligację można traktować jako "wskazując" jedną usługę w innej i mówiąc: "Ta usługa może działać tylko wtedy, gdy ta usługa jest uruchomiona". Czasami odnosimy się do koligacji jako relacji nadrzędnej/podrzędnej (gdzie wskazujesz element podrzędny w obiekcie nadrzędnym). Koligacja gwarantuje, że repliki lub wystąpienia jednej usługi są umieszczane w tych samych węzłach co ta z innej usługi.

ServiceCorrelationDescription affinityDescription = new ServiceCorrelationDescription();
affinityDescription.Scheme = ServiceCorrelationScheme.Affinity;
affinityDescription.ServiceName = new Uri("fabric:/otherApplication/parentService");
serviceDescription.Correlations.Add(affinityDescription);
await fabricClient.ServiceManager.CreateServiceAsync(serviceDescription);

Uwaga

Usługa podrzędna może uczestniczyć tylko w jednej relacji koligacji. Jeśli chcesz, aby dziecko było połączone z dwoma usługami nadrzędnymi jednocześnie, masz kilka opcji:

  • Cofnięć relacje (mają element parentService1 i element parentService2 w bieżącej usłudze podrzędnej) lub
  • Wyznaczyć jednego z rodziców jako centrum zgodnie z konwencją i mieć wszystkie punkty usług w tej usłudze.

Wynikowe zachowanie umieszczania w klastrze powinno być takie samo.

Różne opcje koligacji

Koligacja jest reprezentowana za pomocą jednego z kilku schematów korelacji i ma dwa różne tryby. Najczęstszym trybem koligacji jest to, co nazywamy nonAlignedAffinity. W przypadku wartości nonAlignedAffinity repliki lub wystąpienia różnych usług są umieszczane w tych samych węzłach. Drugi tryb to AlignedAffinity. Wyrównana koligacja jest przydatna tylko w przypadku usług stanowych. Skonfigurowanie dwóch usług stanowych w celu wyrównania koligacji gwarantuje, że prawybory tych usług są umieszczane w tych samych węzłach co nawzajem. Powoduje to również, że każda para secondaries dla tych usług ma zostać umieszczona w tych samych węzłach. Istnieje również możliwość (choć rzadziej) skonfigurowania funkcji NonAlignedAffinity dla usług stanowych. W przypadku wartości NonAlignedAffinity różne repliki dwóch usług stanowych będą działać w tych samych węzłach, ale ich prawybory mogą skończyć się na różnych węzłach.

Tryby koligacji i ich efekty

Żądany stan optymalnego nakładu pracy

Relacja koligacji jest najlepszym rozwiązaniem. Nie zapewnia tych samych gwarancji kolokacji lub niezawodności, które działają w tym samym procesie wykonywalny. Usługi w relacji koligacji są zasadniczo różnymi jednostkami, które mogą zakończyć się niepowodzeniem i mogą być przenoszone niezależnie. Relacja koligacji może również przerwać, choć te przerwy są tymczasowe. Na przykład ograniczenia pojemności mogą oznaczać, że tylko niektóre obiekty usługi w relacji koligacji mogą mieścić się w danym węźle. W takich przypadkach, mimo że istnieje relacja koligacji, nie można jej wymusić z powodu innych ograniczeń. Jeśli jest to możliwe, naruszenie zostanie automatycznie poprawione później.

Łańcuchy a gwiazdy

Obecnie menedżer zasobów klastra nie może modelować łańcuchów relacji koligacji. Oznacza to, że usługa, która jest elementem podrzędnym w jednej relacji koligacji, nie może być elementem nadrzędnym w innej relacji koligacji. Jeśli chcesz modelować ten typ relacji, musisz modelować ją jako gwiazdę, a nie łańcuch. Aby przenieść się z łańcucha do gwiazdy, zamiast tego do pierwszego dziecka zostanie nadrzędne dziecko. W zależności od układu usług może być konieczne wielokrotne wykonanie tej czynności. Jeśli nie ma naturalnej usługi nadrzędnej, może być konieczne utworzenie takiej usługi, która służy jako symbol zastępczy. W zależności od wymagań możesz również przyjrzeć się grupom aplikacji.

Łańcuchy a gwiazdy w kontekście relacji koligacji

Kolejną rzeczą, którą należy zwrócić uwagę na dzisiejsze relacje koligacji, jest to, że są one domyślnie kierunkowe. Oznacza to, że reguła koligacji wymusza tylko to, że element podrzędny umieszczony z elementem nadrzędnym. Nie gwarantuje, że element nadrzędny znajduje się z elementem podrzędnym. W związku z tym w przypadku naruszenia koligacji i skorygowania naruszenia z jakiegoś powodu nie jest możliwe przeniesienie elementu podrzędnego do węzła nadrzędnego, nawet jeśli przeniesienie elementu nadrzędnego do węzła podrzędnego poprawiłoby naruszenie — element nadrzędny nie zostanie przeniesiony do węzła podrzędnego. Ustawienie wartości true dla konfiguracji MoveParentToFixAffinityViolation spowoduje usunięcie kierunkowości. Należy również pamiętać, że relacja koligacji nie może być idealna ani natychmiast wymuszana, ponieważ różne usługi mają różne cykle życia i mogą ulec awarii i przenieść niezależnie. Załóżmy na przykład, że element nadrzędny nagle ulegnie awarii w innym węźle, ponieważ uległ awarii. Menedżer zasobów klastra i menedżer trybu failover najpierw obsługują tryb failover, ponieważ utrzymanie usług w górę, spójność i dostępność jest priorytetem. Po zakończeniu pracy w trybie failover relacja koligacji zostanie przerwana, ale menedżer zasobów klastra uważa, że wszystko jest w porządku, dopóki nie zauważy, że element podrzędny nie znajduje się z elementem nadrzędnym. Te rodzaje kontroli są wykonywane okresowo. Więcej informacji o tym, jak usługa Resource Manager klastra ocenia ograniczenia, jest dostępna w tym artykule. Ten artykuł zawiera więcej informacji na temat sposobu konfigurowania cykli oceny tych ograniczeń.

Obsługa partycjonowania

Ostatnią rzeczą, którą należy zauważyć na temat koligacji, jest to, że relacje koligacji nie są obsługiwane w przypadku partycjonowania elementu nadrzędnego. Partycjonowane usługi nadrzędne mogą być obsługiwane w końcu, ale obecnie nie są dozwolone.

Następne kroki